Re: [Xen-devel] Xen 4.3 development update, 15 Oct

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 18 December 2012 14:28:57 +0000 George Dunlap 
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> > > * Make storage migration possible
> > > Â owner: ?
> > > Â status: ?
> > > Â There needs to be a way, either via command-line or via some hooks,
> > > Â that someone can build a "storage migration" feature on top of libxl
> > > Â or xl.
> > We have this working with qemu-xen, qcow2 and snapshot rebase. At a libxl
> > level (but not an xl level), everything seems to be there.
> Can you describe in more detail how you implement this? Do you have a
> script or something?
We have a pile of C code :-)

A script would do something like:

1. Ask qemu to do a live snapshot using snapshot_blkdev putting the
snapshot in a new file on the new storage device. This ensures that all new
writes go to the new storage device.

2. Rebase the snapshot to a null backing file (I think that's qemu-img
rebase with -b '' though we had to submit a couple of lines of patch to
qemu to make it work) which fills the non-written blocks from the new
snapshot from the old base image and breaks the link to the the old base
image.

In our implementation we have a separate hierarchy database from the parent
links stored within the qcow2 files so we get proper usage counting etc.
but that's an 'implementation detail'.

> From memory (and at risk of crossing threads) using this device model and
external snapshots you can use qemu-img resize to resize drives live at
least under KVM. Obviously the information that the drive has been resized
needs to get to the guest somehow.

--
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel