On 02/04/2016 04:53 AM, Ján Tomko wrote:
> On Wed, Feb 03, 2016 at 03:51:30PM -0500, John Ferlan wrote:
>>
>>
>> On 02/03/2016 03:23 AM, Ján Tomko wrote:
>>> On Tue, Feb 02, 2016 at 11:14:01AM -0500, John Ferlan wrote:
>>>>
>>>>
>>>> On 02/02/2016 08:30 AM, Pavel Hrdina wrote:
>>>>> On Tue, Feb 02, 2016 at 09:11:51AM +0100, Ján Tomko wrote:
>>>>>> A thin pool is another layer on top of some of the LVs in the VG.
>>>>>> I think it deserves a separate pool type.
>>>>>
>>>>> I must agree with Jan, and also already wrote the same for v2 patch. The thin
>>>>> pool and thin LV shouldn't be mixed with normal logical pool even they share the
>>>>> same VG.
>>>>>
>>>>
>>>> If LVM allows it, then who are we to say it cannot or shouldn't work or
>>>> how it should be configured?
>>>
>>> Even if they are mixed in the same VG, we could show the "thick" LVs
>>> in the type='logical' pool and the thin ones in type='thin'.
>>>
>>
>> We could if our logic to create/build the pool was overhauled or perhaps
>> support was added to have two volume groups use the same source device.
>>
>> Since it's possible to place a thin_pool in the same vg as a snapshot
>> and a "thick" lv, should we be in the business of splitting hairs and
>> trying to define how things should be viewed?
>>
>
> We already are. E.g. in the 'fs' pool, we ignore fifos and subdirectories.
>
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.
>> I don't see the benefit behind requiring the user to decide whether to
>> have a libvirt pool view either thin lv's or non-thin lv's of their vg
>> or requiring their vg to essentially be one thin-pool in order to
>> support thin lv's, when we could support whatever configuration they've
>> already developed.
>>
>
> The thin pool would view the thin volumes in a specific thin pool, not
> all thin pools in that VG.
>
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.
>> If more work is done in LV pools - are we going to create new pool types
>> for other lvm segtypes ("mirror", "stripe", "raid", etc.)? In order to
>> display/fetch interesting or specific things about them?
>>
>
> AFAIK none of these create another pool on top of the VG.
>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list