[openstack-dev] [nova] live migration in Mitaka

Daniel P. Berrange berrange at redhat.com
Wed Oct 7 09:14:49 UTC 2015

On Tue, Oct 06, 2015 at 11:43:52AM -0600, Chris Friesen wrote:
> On 10/06/2015 11:27 AM, Paul Carlton wrote:
> >
> >
> >On 06/10/15 17:30, Chris Friesen wrote:
> >>On 10/06/2015 08:11 AM, Daniel P. Berrange wrote:
> >>>On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote:
> >>>>https://review.openstack.org/#/c/85048/ was raised to address the
> >>>>migration of instances that are not running but people did not warm to
> >>>>the idea of bringing a stopped/suspended instance to a paused state to
> >>>>migrate it.  Is there any work in progress to get libvirt enhanced to
> >>>>perform the migration of non active virtual machines?
> >>>
> >>>Libvirt can "migrate" the configuration of an inactive VM, but does
> >>>not plan todo anything related to storage migration. OpenStack could
> >>>already solve this itself by using libvirt storage pool APIs to
> >>>copy storage volumes across, but the storage pool worked in Nova
> >>>is stalled
> >>>
> >>>https://review.openstack.org/#/q/status:abandoned+project:openstack/nova+branch:master+topic:bp/use-libvirt-storage-pools,n,z
> >>>
> >>
> >>What is the libvirt API to migrate a paused/suspended VM? Currently nova uses
> >>dom.managedSave(), so it doesn't know what file libvirt used to save the
> >>state.  Can libvirt migrate that file transparently?
> >>
> >>I had thought we might switch to virDomainSave() and then use the cold
> >>migration framework, but that requires passwordless ssh.  If there's a way to
> >>get libvirt to handle it internally via the storage pool API then that would
> >>be better.
> >So my reading of this is the issue could be addressed in Mitaka by
> >implementing
> >http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-libvirt-storage-pools.html
> >
> >and
> >https://review.openstack.org/#/c/126979/4/specs/kilo/approved/migrate-libvirt-volumes.rst
> >
> >
> >is there any prospect of this being progressed?
> Paul, that would avoid the need for cold migrations to use passwordless ssh
> between nodes.  However, I think there may be additional work to handle
> migrating paused/suspended instances--still waiting for Daniel to address
> that bit.

Migrating paused VMs should "just work" - certainly at the libvirt/QEMU
level there's no distinction between a paused & running VM wrt migration.
I know that historically Nova has blocked migration if the VM is paused
and I recall patches to remove that pointless restriction. I can't
remember if they ever merged.

For suspended instances, the scenario is really the same as with completely
offline instances. The only extra step is that you need to migrate the saved
image state file, as well as the disk images. This is trivial once you have
done the code for migrating disk images offline, since its "just one more file"
to care about.  Officially apps aren't supposed to know where libvirt keeps
the managed save files, but I think it is fine for Nova to peek behind the
scenes to get them. Alternatively I'd be happy to see an API added to libvirt
to allow the managed save files to be uploaded & downloaded via a libvirt
virStreamPtr object, in the same way we provide APIs to  upload & download
disk volumes. This would avoid the need to know explicitly about the file
location for the managed save image.

|: 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 OpenStack-dev mailing list