Re: [Qemu-devel] Selective block migration (still on 0.13)

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

On 09/13/2012 08:58 AM, Christian Theune wrote:

> I saw that 0.13 does have block migration available. However, looking at
> the code, it's an "either or" situation: migrate all block devices or none.

Migrating disks during live migration has proven to be hard to get
right; the current code is moving towards a means of migrating disks
independently from live migration, and using something like an NBD
server to transfer the remaining portions that changed in between the
disk migration and the actual live migration.  But it's still a work in
progress, so please give feedback to make sure that what we provide for
qemu 1.3 is the correct approach.

> 
> In our case we have the root disks on iSCSI (through virtio-blk) and two
> additional local disks (for /tmp and swp).
> 
> Now, the iSCSI shouldn't be migrated but the local disks should.

Should be possible with Paolo's patches for adding 'drive-mirror', where
you use drive-mirror to migrate the disks you care about prior to the
live migration.  Mirror the overlay of the disks to shared storage, copy
the backing file in the background, then do the migration with
everything seeing shared overlays and consistent local backing files,
then once the migration is complete, you can use block-stream or Jeff's
proposed 'block-commit' to get the backing chain collapsed back down to
something manageable.

> Reading up in the current code, it doesn't look like this would be
> feasable. Can someone prove me wrong? Please? :)

Correct - this is still an area of active development, and qemu 1.2
isn't much better than 0.13.

> 
> Even the earlier discussion regarding live block copy which included a
> reference to using libvirt sounds like it would have a problem
> instrumenting the live migration correctly: how do you get the migration
> atomic if you need to copy the block devices independent of the VM
> migration? Maybe, I'm missing something.

I'm still trying to figure out the best way to have libvirt support disk
migration in parallel with live migration in light of the interfaces
being added to qemu 1.3.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]