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

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

[Christian Theune]

Hi,

we're currently still on 0.13, looking forward to a large update soon. :)

We haven't been using live migration up until now, but are 
investigating it to multiple downtimes (restarting updated hosts and 
restarting updated guests) when doing system updates. So, we're trying 
to find out whether we can get this into a usable shape while still 
running 0.13.

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.

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.

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

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.

Cheers,
Christian

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

[Eric Blake]

[-- 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 --]

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

[Kevin Wolf]

Am 13.09.2012 16:58, schrieb Christian Theune:
> Hi,
> 
> we're currently still on 0.13, looking forward to a large update soon. :)
> 
> We haven't been using live migration up until now, but are 
> investigating it to multiple downtimes (restarting updated hosts and 
> restarting updated guests) when doing system updates. So, we're trying 
> to find out whether we can get this into a usable shape while still 
> running 0.13.
> 
> 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.

And I advise you to choose "none" with 0.13. While the 1.2 block
migration code doesn't add new options over 0.13 and is deprecated, it's
expected to kind of work. However, I'm pretty sure that we fixed some
data corruptions issues after 0.13 and so I'd expect that 0.13 eats your
data when using block migration.

Kevin