On Wed, Nov 5, 2014 at 2:54 PM, Eric Blake <eblake@xxxxxxxxxx> 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: qemu+unix:///session?socket=/run/user/1000/libvirt/libvirt-sock
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
cheers
--
Marc-André Lureau
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list