"Javier Guerra" <javier@xxxxxxxxxxx> writes:
> On Mon, Sep 15, 2008 at 11:02 AM, Wendell Dingus <wendell@xxxxxxxxxxxxx>
>> 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.
Xen-users mailing list