[libvirt] Local qemu migration

Marc-André Lureau marcandre.lureau at gmail.com
Wed Nov 5 14:28:18 UTC 2014

On Wed, Nov 5, 2014 at 2:54 PM, Eric Blake <eblake at redhat.com> wrote:

> The monitor socket location is different for qemu:///system than for
> qemu:///session (or when going between two different users'
> qemu:///session).  But things like the VNC port do start to be an issue.
Not if the port is allocated, or the unix path is namespaced. But I
understand better where the problems may come from. Still, I would imagine
that libvirt would simply fail to migrate and no bad things would happen in
those cases.

> > Migration fundamentally requires that the two QEMU processes involved
> have
> > completely separate filesystem namespaces, which effectively means
> separate
> > hosts (or at least separate containers which is effectively the same
> thing)
> >
> >> Except the obvious testing case, there are other use cases that could be
> >> interesting: moving a running VM from system to session libvirt, or the
> >> other way around, or to a different user.
> >
> > Migrating from session to system libvirt or vica-verca isn't something
> > that is reasonable to support either because of the different privilege
> > levels. The session QEMU will require the disk images to be owned by
> > one user account, the system QEMU will require them to be owned by a
> > different user account. We can't chown the images to satisfy both the
> > system and session QEMU at the same time.
> This, coupled with the fact that we don't allow connection to a remote
> qemu:///session instance (right now, the RPC code assumes that it will
> only connect to qemu:///system), means that it is not possible to do
> live migration in or out of a session instance, regardless of whether it
> is on the same machine, and regardless of whether it is between the
> session libvirtd of two different users.

Well, I managed to migrate from system to session with a disk less VM, it
was useful for testing.

All you have to do is to provide the unix socket path, ex:

Although it would be nice to make this easier to lookup eventually

> It might be possible to migrate to file (such as virsh save), then
> update permissions on the save file and other resources, then reload
> from that file; but it is not a live migration.

Yes, that's what Boxes is doing afaik. I should have stated clearly I was
talking about live migration


Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141105/e3553f20/attachment-0001.htm>

More information about the libvir-list mailing list