On 05/09/2011 06:23 PM, Anthony Liguori wrote:
On 05/09/2011 08:40 AM, Dor Laor wrote:
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 block copy is growing on me. It can actually be used (with an
intermediate network storage) to do live block migration.
I'm not sure that we can relay on such storage. While it looks that
anyway can get such temporal storage, it makes failure cases complex, it
will need additional locking, security permissions, etc.
That said, the main gap is the block copy protocol and using qemu as
iScsi target/initiator might be a good solution.
* 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 is unfortunately not really "live". It runs a lot of
operations synchronously which will cause the guest to incur downtime.
We really need to refactor it to truly be live.
Well live migration is not really live too.
It can be thought as implementation details and improved later on.
* 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).
I think the image format is really the best place to have this logic. Of
course, if we have live snapshot merge, we could use a temporary
QED/QCOW2 file and then merge afterwards.
* 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.
Does the dirty block bitmap need to exist outside of QEMU?
IOW, if it goes away after a guest shuts down, is that problematic?
I admit I didn't give it enough thought, I think that sharing the code
w/ qemu-img should be enough for us. If we have a live block operation
and suddenly the guest shuts down in the middle we need to finish the
block copy.
I think it potentially greatly simplifies the problem which makes it
appealing from my perspective.
Regards,
Anthony Liguori
