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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 18/12/12 16:03, Alex Bligh wrote:
> --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.
So it sounds like in this case you're talking about moving the disk to a 
different storage device connected to the same host, leaving the VM 
running on the same host.
What I was talking about in this was migrating the VM and storage 
together to a new host.  People who want this typically have all VMs on 
local storage, so (if I'm understanding you right) the snapshot trick 
won't work, because host A (where it's running) can't directly access 
host B's disk (to which we want to migrate it).
Although I suppose one could always hack something together with sshfs 
or something. :-)
 -George

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