[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC] live snapshot, live merge, live block migration
From: |
Dor Laor |
Subject: |
[Qemu-devel] [RFC] live snapshot, live merge, live block migration |
Date: |
Mon, 09 May 2011 16:40:00 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 ThunderBrowse/3.3.5 |
No patch here (sorry) but collection of thoughts about these features
and their potential building blocks. Please review (also on
http://wiki.qemu.org/Features/LiveBlockMigration)
Future qemu is expected to support these features (some already
implemented):
* Live block copy
Ability to copy 1+ virtual disk from the source backing file/block
device to a new target that is accessible by the host. The copy
supposed to be executed while the VM runs in a transparent way.
Status: code exists (by Marcelo) today in qemu but needs refactoring
due to a race condition at the end of the copy operation. We agreed
that a re-implementation of the copy operation should take place
that makes sure the image is completely mirrored until management
decides what copy to keep.
* Live snapshots and live snapshot merge
Live snapshot is already incorporated (by Jes) in qemu (still need
qemu-agent work to freeze the guest FS).
Live snapshot merge is required in order of reducing the overhead
caused by the additional snapshots (sometimes over raw device).
Currently not implemented for a live running guest
Possibility: enhance live copy to be used for live snapshot merge.
It is almost the same mechanism.
* Copy on read (image streaming)
Ability to start guest execution while the parent image reside
remotely and each block access is replicated to a local copy (image
format snapshot)
It should be nice to have a general mechanism that will be used for
all image formats. What about the protocol to access these blocks
over the net? We can reuse existing ones (nbd/iscsi).
Such functionality can be hooked together with live block migration
instead of the 'post copy' method.
* Live block migration (pre/post)
Beyond live block copy we'll sometimes need to move both the storage
and the guest. There are two main approached here:
- pre copy
First live copy the image and only then live migration the VM.
It is simple but if the purpose of the whole live block migration
was to balance the cpu load, it won't be practical to use since
copying an image of 100GB will take too long.
- post copy
First live migrate the VM, then live copy it's blocks.
It's better approach for HA/load balancing but it might make
management complex (need to keep the source VM alive, what happens
on failures?)
Using copy on read might simplify it -
post copy = live snapshot + copy on read.
In addition there are two cases for the storage access:
1. The source block device is shared and can be easily accessed by
the destination qemu-kvm process.
That's the easy case, no special protocol needed for the block
devices copying.
2. There is no shared storage at all.
This means we should implement a block access protocol over the
live migration fd :(
We need to chose whether to implement a new one, or re-use NBD or
iScsi (target&initiator)
* Using external dirty block bitmap
FVD has an option to use external dirty block bitmap file in
addition to the regular mapping/data files.
We can consider using it for live block migration and live merge too.
It can also allow additional usages of 3rd party tools to calculate
diffs between the snapshots.
There is a big down side thought since it will make management
complicated and there is the risky of the image and its bitmap file
get out of sync. It's much better choice to have qemu-img tool to be
the single interface to the dirty block bitmap data.
Summary:
* We need Marcelo's new (to come) block copy implementation
* should work in parallel to migration and hotplug
* General copy on read is desirable
* Live snapshot merge to be implemented using block copy
* Need to utilize a remote block access protocol (iscsi/nbd/other)
Which one is the best?
* Keep qemu-img the single interface for dirty block mappings.
* Live block migration pre copy == live copy + block access protocol
+ live migration
* Live block migration post copy == live migration + block access
protocol/copy on read.
Comments?
Regards,
Dor
- [Qemu-devel] [RFC] live snapshot, live merge, live block migration,
Dor Laor <=
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Anthony Liguori, 2011/05/09
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Dor Laor, 2011/05/09
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Marcelo Tosatti, 2011/05/12
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Jes Sorensen, 2011/05/12
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Marcelo Tosatti, 2011/05/10
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Jes Sorensen, 2011/05/12
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Jagane Sundar, 2011/05/12
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Dor Laor, 2011/05/15
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Jagane Sundar, 2011/05/15
- Re: [Qemu-devel] [RFC] live snapshot, live merge, live block migration, Dor Laor, 2011/05/16