<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 29, 2018 at 4:55 AM, Daniel P. Berrangé <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@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"><span class="gmail-">On Tue, Aug 28, 2018 at 05:07:18PM -0400, David Vossel wrote:<br>
> Hey,<br>
> <br>
> Over in KubeVirt we're investigating a use case where we'd like to perform<br>
> a live migration within a network namespace that does not provide libvirtd<br>
> with network access. In this scenario we would like to perform a live<br>
> migration by proxying the migration through a unix socket to a process in<br>
> another network namespace that does have network access.  That external<br>
> process would live on every node in the cluster and know how to correctly<br>
> route connections between libvirtds.<br>
> <br>
> virsh example of an attempted migration via unix socket.<br>
> <br>
> virsh migrate --copy-storage-all --p2p --live --xml domain.xml my-vm<br>
> qemu+unix:///system?socket=<wbr>destination-host-proxy-sock<br>
> <br>
> In this example, the src libvirtd is able to establish a connection to the<br>
> destination libvirtd via the unix socket proxy. However, the migration-uri<br>
> appears to require either tcp or rdma network connection.  If I force the<br>
> migration-uri to be a unix socket, I receive an error [1] indicating that<br>
> qemu+unix is not a valid transport.<br>
<br>
</span>qemu+unix is a syntax for libvirt's URI format.  The URI scheme for<br>
migration is not the same, so you can't simply plug in qemu+unix here.<br>
<span class="gmail-"><br>
> <br>
> Technically with qemu+kvm I believe what we're attempting should be<br>
> possible (even though it is inefficient). Please correct me if I'm wrong.<br>
> <br>
> Is there a way to achieve this migration via unix socket functionality this<br>
> using Libvirt? Also, is there a reason why the migration uri is limited to<br>
> tcp/rdma<br>
<br>
</span>Internally libvirt does exactly this when using its TUNNELLED live migration<br>
mode. In this QEMU is passed an anonymous UNIX socket and the data is all<br>
copied over the libvirtd <-> libvirtd connection and then copied again back<br></blockquote><div><br></div><div>Sorry for the delayed response here, I've only just picked this task back up again recently.</div><div><br></div><div>With the TUNNELLED and PEER2PEER migration flags set, Libvirt won't allow the libvirtd <-> libvirtd connection over a unix socket. </div><div><br></div><div>Libvirt returns this error "Attempt to migrate guest to the same host". The virDomainMigrateCheckNotLocal() function ensures that a peer2peer migration won't occur when the destination is a unix socket.</div><div><br></div><div>Is there anyway around this? We'd like to tunnel the destination connection through a unix socket. The other side of the unix socket is a network proxy in a different network namespace which properly performs the remote connection.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
to QEMU on another UNIX socket. This was done because QEMU has long had no<br>
ability to encrypt live migration, so tunnelling over libvirtd's own TLS<br>
secured connection was only secure mechanism. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We've done work in QEMU to natively support TLS now so that we can get rid<br>
of this tunnelling, as this architecture decreased performance and consumed<br>
precious CPU memory bandwidth, which is particularly bad when libvirtd and<br>
QEMU were on different NUMA nodes. It is already a challenge to get live<br>
migration to successfully complete even with a direct network connection.<br>
Although QEMU can do it at the low level, we've never exposed anything<br>
other than direct network transports at the API level. <br>
<br>
Regards,<br>
Daniel<br>
<span class="gmail-HOEnZb"><font color="#888888">-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a>      -o-    <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/<wbr>dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a>         -o-            <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a>    -o-    <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/<wbr>dberrange</a> :|<br>
</font></span></blockquote></div><br></div></div></div></div>