From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.3 development update, 15 Oct Date: Tue, 18 Dec 2012 16:40:07 +0000 Message-ID: <50D09C67.1010703@eu.citrix.com> References: <39A8C47B5D7DD22A52A3DA51@Ximines.local> <008ECD032A8603F73C448ABD@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <008ECD032A8603F73C448ABD@Ximines.local> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Alex Bligh Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 18/12/12 16:03, Alex Bligh wrote: > > > --On 18 December 2012 14:28:57 +0000 George Dunlap > 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