[libvirt] [RFC] live migration of VMs with internal snapshots

Daniel P. Berrange berrange at redhat.com
Tue Apr 26 08:19:44 UTC 2016


On Tue, Apr 26, 2016 at 06:26:59AM +0300, Maxim Nestratov wrote:
> Hi,
> 
> As far as I understand, currently there is no way to live migrate qemu VMs
> that
> have internal snapshots, because live migration works via qemu drive
> mirroring,
> which in turns mirrors only shallow block layer, effectively losing existing
> embedded
> snapshots. The problem could be fixed if we created an external delta for
> all disks with
> internal snapshots, live migrate such VMs and then auto merge them back into
> original images. That said, I would like to know very much your opinion on
> the matter
> and would also like to know if this approach is affordable. If so, I or one
> of my colleagues
> will send a pathset to fix this, otherwise what solution for this problem
> you will
> recommend?

With modern QEMU we do the storage migration using an NBD server that
is built-in to QEMU. Now this only knows about disks that are currently
attached to the VM. I wonder though if we could simply add all the
snapshots to the running VM, but not connect them to any guest device.

ie, we'd do  blockdev_add, but would *not* do the corresponding device_add.
The built-in NBD server would then be able to export them in the same way
as the other disks.

The other idea would be to just run a standalone qemu-nbd process to
export them, but I think that's a bit more messy because it means we'd
have to manage a bunch more external processes and allocate extra net
connections.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list