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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

Jan

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]