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.
Peter