Re: [libvirt] [PATCH v3 4/4] logical: Display thin lv's found in a libvirt managed volume group

On 02/04/2016 04:53 AM, Ján Tomko wrote: True we don't follow any subdir for an 'fs' pool (or 'dir' pool); however, a 'thin-pool' and 'thin' lv are both in a VG. The hierarchy is managed by LVM. If you looked at the on disk structure you'd only find the 'thin' subdir, but there is no 'thin-pool' subdir. Sure I understand the goal - a 1-to-1 relationship between a thin-pool in a volume group and the libvirt pool. Then a 1-to-n relationship between the pool and it's thin lv's. If a VG had two thin-pools, then each would have to be it's own libvirt pool. Configuring the libvirt specific pool is an extra step or two. The libvirt pool would list the thin-pool size as capacity and the allocation could be based on the data_percent. Perhaps the one benefit I can see from this model. I do see a lot of extra code, documentation, and configuration steps. True - not in the same manner as a thin-pool and thin lv have an overt relationship. However, thin lv's and thin-pool's are listed within a VG not on top of a VG. The thin-pool is just the mechanism used to define the physical storage extents from which the virtual 'thin' extents can be drawn from. If the thin-pool runs out of extents, the admin must come along and extend it. That is - libvirt is not involved. No different than if a VG (without a thin-pool) ran out of space. The admin would need to extend it via some LVM command. Again libvirt is hands off. I see creating a separate pool as a needless hierarchical step for the primary benefit of being able to display the capacity of the thin-pool. I think it's easier to describe that a logical pool that contains thin lv's can appear to be over-subscribed. Management of the thin-pool's from which those thin lv's draw from is left to LVM similar to whatever configuration steps are required to create a device path for an 'fs' pool to use. John