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] Is XVD live resize possible?

To: Andy Smith <andy@xxxxxxxxxxxxxx>
Subject: Re: [Xen-users] Is XVD live resize possible?
From: Ferenc Wagner <wferi@xxxxxxx>
Date: Sun, 06 Apr 2008 15:55:15 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 06 Apr 2008 06:55:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080406132315.GY28226@xxxxxxxxxxx> (Andy Smith's message of "Sun, 6 Apr 2008 13:23:15 +0000")
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/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <87d4p3pala.fsf@xxxxxxxxxxxxxxxxx> <47F8AF71.40908@xxxxxxxxx> <20080406132315.GY28226@xxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Andy Smith <andy@xxxxxxxxxxxxxx> writes:

> Ferenc Wagner wrote:
>> Now I can lvresize xenimages/stan in dom0, but the domU stays ignorant
>> of this change.  How could I propagate the resize to the domU without
>> rebooting or temporarily breaking its connection to /dev/xvda?  Sort
>> of a SCSI rescan, perhaps?
> A technique I have used for customers that required to add and
> remove disk space without any loss of service is to give them their
> / on one block device and then supply them with multiple other block
> devices which they use as LVM PVs.  These can be added and removed
> with LVM inside the domU, with the data shifting off/on the
> different devices as needed.

Huh, good idea, if not particularly nice... :)

> Obvious downsides to this approach are the added complexity, small
> performance loss from LVM-on-xvd*-on-LVM, and lack of easy access to
> the data from dom0.

Well, if the domU has to do lots of pvmoves, that kills preformance
much worse than the LVM layers...  Actually, looks like one could do
with two exported block devices: move data off one, detach/resize/
attach it again, move data onto the new device.  Meanwhile / can
reside on an LV without noticing anything at all...

Idea: maybe multipathing could solve this issue without ever needing
to physically move any data...  If the multipath layer can copy with
devices changing size underneath, which I don't know.

> Or there is always NFS..  I don't know how or even if iSCSI, AoE or
> NBD cope with changing sizes of block devices but that is perhaps
> something to explore.

Well, the kernel SCSI disk layer knows how to rescan a device, which
may have changed its size (SAN devices routinely change exported LUN
sizes, much like outsourced LVM): see /sys/block/sd*/device/rescan.
My gut feeling is that the same mechanism wouldn't be too hard to
employ for xvd devices, too.  Unfortunately, it's not there yet.

Xen-users mailing list