[Qemu-devel] [PATCH 0/3 v3] Live migration without shared storage

[Qemu-devel] [PATCH 0/3 v3] Live migration without shared storage

[lirans]

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 -b tcp:0:4444 # for live migration with complete storage copy
(qemu) migrate -d -i tcp:0:4444 # for live migration with incremental storage copy, storage is cow based.

The patches are against qemu.git tree

 Makefile          |    1 +
 block-migration.c |   43 ++++++++++++-----------------------------
 block-migration.h |    2 +-
 block.c           |   27 ++++++++++++++++++++++++++
 block.h           |    6 ++++-
 block_int.h       |    1 +
 buffered_file.c   |   10 ++++++++-
 hw/hw.h           |    9 ++++++-
 migration-exec.c  |    9 ++++++-
 migration-fd.c    |    7 +++++-
 migration-tcp.c   |    7 +++++-
 migration-unix.c  |    7 +++++-
 migration.c       |   20 +++++++++++++-----
 migration.h       |   20 ++++++++++++++----
 monitor.c         |   38 +++++++++++++++++++++++++++++-------
 qemu-monitor.hx   |    6 +++-
 savevm.c          |   54 +++++++++++++++++++++++++++++++++++++---------------
 sysemu.h          |    2 +-
 vl.c              |    6 ++++-
 19 files changed, 196 insertions(+), 79 deletions(-)

[Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared storage

[Jan Kiszka]

lirans@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).

For my understanding: Does it require the use of qcow[2] or does it also
work with raw images?

> 
> Live migration will work as follows:
> (qemu) migrate -d tcp:0:4444 # for ordinary live migration
> (qemu) migrate -d -b tcp:0:4444 # for live migration with complete storage copy
> (qemu) migrate -d -i tcp:0:4444 # for live migration with incremental storage copy, storage is cow based.
> 
> The patches are against qemu.git tree

...but without signed-off. Are they RFC for now or do you propose them
for merge?

Jan

PS: I think there are some style issues remaining like tabs or long lines.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared storage

[Liran Schour]

Jan Kiszka <jan.kiszka@siemens.com> wrote on 17/09/2009 17:03:04:

> lirans@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).
>
> For my understanding: Does it require the use of qcow[2] or does it also
> work with raw images?

If you call migrate -b it will do a full copy of the disk,
if you call migrate -i it will do incremental copy means that if you have
qcow disk it will copy only the allocated data. The base image should be
identical
in both source and destination.

> >
> > Live migration will work as follows:
> > (qemu) migrate -d tcp:0:4444 # for ordinary live migration
> > (qemu) migrate -d -b tcp:0:4444 # for live migration with complete
> storage copy
> > (qemu) migrate -d -i tcp:0:4444 # for live migration with
> incremental storage copy, storage is cow based.
> >
> > The patches are against qemu.git tree
>
> ...but without signed-off. Are they RFC for now or do you propose them
> for merge?

I think that RFC is good for now.

> Jan
>
> PS: I think there are some style issues remaining like tabs or long
lines.

Thanks I will fix that.

- Liran

[Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared storage

[Jan Kiszka]

Liran Schour wrote:
> Jan Kiszka <jan.kiszka@siemens.com> wrote on 17/09/2009 17:03:04:
> 
>> lirans@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).
>> For my understanding: Does it require the use of qcow[2] or does it also
>> work with raw images?
> 
> If you call migrate -b it will do a full copy of the disk,
> if you call migrate -i it will do incremental copy means that if you have
> qcow disk it will copy only the allocated data. The base image should be
> identical
> in both source and destination.

Ah, ok. So this doesn't affect the feasibility, "just" the effort needed
for the replication.

> 
>>> Live migration will work as follows:
>>> (qemu) migrate -d tcp:0:4444 # for ordinary live migration
>>> (qemu) migrate -d -b tcp:0:4444 # for live migration with complete
>> storage copy
>>> (qemu) migrate -d -i tcp:0:4444 # for live migration with
>> incremental storage copy, storage is cow based.
>>> The patches are against qemu.git tree
>> ...but without signed-off. Are they RFC for now or do you propose them
>> for merge?
> 
> I think that RFC is good for now.

[RFC][PATCH ...] :)

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared storage

[Kevin Wolf]

Am 17.09.2009 16:03, schrieb Jan Kiszka:
> lirans@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).
> 
> For my understanding: Does it require the use of qcow[2] or does it also
> work with raw images?

This leads me to the question what the block migration is doing with
qcow2 images (or better: images in any format but raw). What happens
with non-standard image options (like cluster size)? Are snapshots
copied over or won't they be available any more on the destination host?

Kevin

Re: [Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared storage

[Liran Schour]

Kevin Wolf <kwolf@redhat.com> wrote on 17/09/2009 18:38:59:

> Am 17.09.2009 16:03, schrieb Jan Kiszka:
> > lirans@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
ofallocated
> >>     data (user responsibility to verify that the same backend file
reside
> >>     on src and destination).
> >
> > For my understanding: Does it require the use of qcow[2] or does it
also
> > work with raw images?
>
> This leads me to the question what the block migration is doing with
> qcow2 images (or better: images in any format but raw). What happens
> with non-standard image options (like cluster size)? Are snapshots
> copied over or won't they be available any more on the destination host?
>

For now the block migration will only copy data. 2 ways for replicating the
data:
-b means copy all data to the destination, image on the destination can be
in a
different format from source but all blocks will be written.
-i means copy only allocated data, only the data that is allocated and
valid will
be copied (I use bdrv_is_allocated() to figure out what to copy). Base
image should
be identical on source and target. No snapshot or any kind of metadata will
be copied,
snapshots will be lost on this case.
It is possible to replicate snapshots data also but I did not implement
that for now.

- Liran