This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] SAN + XEN + FC + LVM question(s)

To: Pasi Kärkkäinen <pasik@xxxxxx>
Subject: Re: [Xen-users] SAN + XEN + FC + LVM question(s)
From: Ferenc Wagner <wferi@xxxxxxx>
Date: Thu, 18 Sep 2008 10:54:54 +0200
Cc: Wendell Dingus <wendell@xxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx, Javier Guerra <javier@xxxxxxxxxxx>
Delivery-date: Thu, 18 Sep 2008 01:55:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080916113637.GM13941@xxxxxxxxxxxxxxx> (Pasi Kärkkäinen's message of "Tue, 16 Sep 2008 14:36:37 +0300")
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <1053235014.99411221494497785.JavaMail.root@xxxxxxxxxxxxxxxxxx> <799907552.99431221494539052.JavaMail.root@xxxxxxxxxxxxxxxxxx> <90eb1dc70809150916w141f2f82lddba9ffd1f0bced0@xxxxxxxxxxxxxx> <873ak0790o.fsf@xxxxxxxxxxxxx> <20080916113637.GM13941@xxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Pasi Kärkkäinen <pasik@xxxxxx> writes:

> On Tue, Sep 16, 2008 at 11:08:39AM +0200, Ferenc Wagner wrote:
>> "Javier Guerra" <javier@xxxxxxxxxxx> writes:
>>> On Mon, Sep 15, 2008 at 11:02 AM, Wendell Dingus <wendell@xxxxxxxxxxxxx> 
>>> wrote:
>>>> Are there pitfalls or limitations I've not thought of here though? Is this
>>>> approach a "best practices" or is some other method considered "better"?
>>> AFAICS, you're right and ready to go.
>>> the only thing i don't like too much is using LVM inside DomU's.  in
>>> theory some scanning tools could confuse the LVM metadata inside those
>>> volumes with the 'outer' LVM metadata and wreck the whole thing.  i
>>> don't think it really happens in practice...
>> You can easily sidestep this by setting up appropriate "filter" rules
>> in lvm.conf in you dom0s.  That way pvscan won't look into your LVs
>> thus it won't discover the embedded guest LVs.  Still, if you shut
>> down a guest and want to access its LVs from dom0, you are perfectly
>> able to: just modify your filters, pvscan, and there you go.  Just
>> don't forget to undo that before starting up the guest again.
>> One thing I contemplated over was using "multipath" in the guest.
>> That may give you a chance to propagate the resize into the guest
>> without rebooting it or permanently introducing another PV in it.
>> Like this: resize the LV in the dom0, pass it to the guest as another
>> block device, replace the LVM mappings so that they point to the new
>> device, then detach the original device, pvextend etc.  I'm not sure
>> multipath-tools would work in this setup, but dmsetup surely would.
>> I never tried it, though.
> Yes, dm-multipath should allow that.
> Check https://www.redhat.com/archives/dm-devel/2008-August/msg00033.html

Well, yes...  Once you are into such business, dm-multipath doesn't
buy you that much at all.  One could replace the backing device in the
LVM tables as well. -- Hmm, maybe using dm-multipath would remove the
possibility of deadlock when pausing the root and swap devices.  And
is also easier to manage.  But then you have to carry it all the time.
Its overhead is probably negligible, though.  This is interesting...

Xen-users mailing list