<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 2:54 PM, Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":d5m" class="" style="overflow:hidden">The monitor socket location is different for qemu:///system than for<br>
qemu:///session (or when going between two different users'<br>
qemu:///session).  But things like the VNC port do start to be an issue.<br>
<span class=""><br></span></div></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":d5m" class="" style="overflow:hidden"><span class="">
><br>
> Migration fundamentally requires that the two QEMU processes involved have<br>
> completely separate filesystem namespaces, which effectively means separate<br>
> hosts (or at least separate containers which is effectively the same thing)<br>
><br>
>> Except the obvious testing case, there are other use cases that could be<br>
>> interesting: moving a running VM from system to session libvirt, or the<br>
>> other way around, or to a different user.<br>
><br>
> Migrating from session to system libvirt or vica-verca isn't something<br>
> that is reasonable to support either because of the different privilege<br>
> levels. The session QEMU will require the disk images to be owned by<br>
> one user account, the system QEMU will require them to be owned by a<br>
> different user account. We can't chown the images to satisfy both the<br>
> system and session QEMU at the same time.<br>
<br>
</span>This, coupled with the fact that we don't allow connection to a remote<br>
qemu:///session instance (right now, the RPC code assumes that it will<br>
only connect to qemu:///system), means that it is not possible to do<br>
live migration in or out of a session instance, regardless of whether it<br>
is on the same machine, and regardless of whether it is between the<br>
session libvirtd of two different users.<br></div></blockquote><div><br></div><div>Well, I managed to migrate from system to session with a disk less VM, it was useful for testing.<br><br></div><div>All you have to do is to provide the unix socket path, ex: qemu+unix:///session?socket=/run/user/1000/libvirt/libvirt-sock<br><br></div><div>Although it would be nice to make this easier to lookup eventually<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":d5m" class="" style="overflow:hidden">
<br>
It might be possible to migrate to file (such as virsh save), then<br>
update permissions on the save file and other resources, then reload<br>
from that file; but it is not a live migration.</div></blockquote></div><br></div><div class="gmail_extra">Yes, that's what Boxes is doing afaik. I should have stated clearly I was talking about live migration<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">cheers<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">Marc-André Lureau</div>
</div></div>