[libvirt] [PATCH 0/4] Display thin lv's from a logical vg

[John Ferlan]

On 02/05/2016 06:33 AM, Daniel P. Berrange wrote:
> On Fri, Feb 05, 2016 at 12:07:40PM +0100, Peter Krempa wrote:
>> On Thu, Feb 04, 2016 at 20:40:46 -0500, John Ferlan wrote:
>>> While I know not the preferred mechanism for Jan, these patches
>>> provide a means to display thin lv data from a volume group including
>>> the source thin-pool name and thin-pool capacity. Since a thin-pool
>>> and a thin lv are just members of the vg, it just feels natural to
>>> display whatever is in the volume group because a logical pool
>>> comprises all the volumes within the vg.
>>
>> You could do a similar claim for volume groups or even directories
>> belonging to a 'disk' type pool since they reside on the partition
>> managed by such pool.
>>
>>>
>>> Even if not accepted, some concepts can be used as a bases for a
>>> single thin-pool to libvirt pool relationship.
>>
>> The thin volumes and pools have to be manualy manipulated into the
>> volume group that is used as backing for the libvirt 'logical' storage
>> pool since the API does not support building a thin pool backing volume.
>>
>> From this point looking at libvirt APIs it's more natural to have the
>> LVM thin pool as a regular libvirt storage pool as you implicitly get
>> the APIs for building the pool, for getting sizes and other things.
>>
>>
>>> There are no changes to virsh vol-list --details or virsh vol-info
>>> to display the thin-pool capacity. If one self adds all the capacity
>>
>> Obviously as it fits better into 'virsh pool-list --details'.
>>
>>> values in the vol-list --details display, they will determine that the
>>> sum is larger than the virsh pool-info output for the volume group.
>>> Although that's even true prior to these patches since the thin data
>>> is not displayed in the vol-list output, but is accounted for in the
>>> pool-info output, thus the sum of the vol-list capacity details are less.
>>
>> As stated above. The pool was manipulated outside of libvirt with
>> features that are not (yet) supported. I don't see a reason to cram this
>> stuff into the existing logical pool support.
> 
> Agreed, our goal is only really to report on stuff that libvirt was
> capable of creating in the first place, otherwise the problemspace
> becomes unmanagably huge IMHO. Also we need to be wary of cramming
> in too many highly LVM specific features - we need to try and represent
> them in a platform/technology agnostic manner whereever possible.
> 

libvirt cannot create mirror, stripe, raid* lvm segtypes, but we can
report on those lv's in the pool because each displays data in the
'devices' output. The only reason we don't report on thin lv's is
because they have no listed devices.

If the last patch had just noted to display lv devices regardless of
whether they had a device listed and not mentioning specifically that
these were lv thin devices, I wonder now if that would have not raised
any questions ;-)...

John

FWIW: While poking around - I found there are examples of using a
/dev/$vgname/$lvthindevice directly rather than using them from a pool.