qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] Selective block migration (still on 0.13)
Date: Thu, 13 Sep 2012 11:11:26 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]