On Wed, Nov 5, 2014 at 2:54 PM, Eric Blake <[email protected]> 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 [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
