On 23 nov. 2009, at 19:47, Jan Kiszka wrote: > Avi Kivity wrote: >> On 11/03/2009 11:40 AM, Liran Schour wrote: >>> - Liran >>> >>> Avi Kivity<a...@redhat.com> wrote on 02/11/2009 20:47:34: >>> >>>> On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote: >>>> >>>>> This series adds support for live migration without shared storage, >>>>> >>> means >>> >>>>> copy the storage while migrating. It was tested with KVM. Supports 2 >>>>> >>> ways >>> >>>>> to replicate the storage during migration: >>>>> 1. Complete copy of storage to destination >>>>> 2. Assuming the storage is cow based, copy only the allocated >>>>> data, time of the migration will be linear with the amount of allocated >>>>> data (user responsibility to verify that the same backend file reside >>>>> on src and destination). >>>>> >>>>> Live migration will work as follows: >>>>> (qemu) migrate -d tcp:0:4444 # for ordinary live migration >>>>> (qemu) migrate -d blk tcp:0:4444 # for live migration with >>>>> >>>> complete storage copy >>>> >>>>> (qemu) migrate -d blk inc tcp:0:4444 # for live migration with >>>>> >>>> incremental storage copy, storage is cow based. >>>> >>>>> >>>> I'd like to see the syntax generalized. For one, the guest may have >>>> several disks; an install image cdrom might be available as an nfs image >>>> but the main storage is local. Secondly, there can be several levels of >>>> cow and we want to control which one we copy. >>>> >>>> I'll leave the exact details to the qpeople, but if we can specify a >>>> copy depth for each device, where 0=copy nothing, n=copy everything, >>>> 1=copy the last level (equivalent to -d blk inc) I think we'll have >>>> covered everything. >>>> >>> I propose the following syntax: >>> migrate [-d] [-b [<device:copy_level> ...<device:copy_level>]] >>> tcp:<host>:<port> >>> Where device will be the name of the device: ide0-hd0. And copy_level >>> will >>> be integer or n, 0=flat copy of the device, 1=copy the last level ... >>> n=copy all levels. >>> All HD devices that will not appear in the command will be treated as >>> copy_level=0. All devices != BDRV_TYPE_HD will be ignored. >>> >>> >> >> Looks good. >> > > Do I get this correctly: this series is now "only" blocked by the > required rework of its user interface? Is there a schedule for this, a > v6 roll out? Will it be in time for qemu-0.12? > > Jan
It was committed to the master branch a week ago. -- Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
