Itamar Heim wrote: >> From: libvir-list-bounces@xxxxxxxxxx [mailto:libvir-list- >> bounces@xxxxxxxxxx] On Behalf Of Chris Lalancette > ... >> 2) virsh on the controller connects to the src, and initiates the >> migration >> command. In turn, this causes the controller to also connect to the >> dst. Now, >> during the "Prepare" step on the dst, we setup a qemu container to >> listen to >> some port (call it 1234) on localhost. It also forks an external >> program (or a >> thread) to listen for an incoming gnutls connection. Next, the >> "Perform" step >> is call on the src machine. This forks an external program (or thread) >> to >> listen for incoming data from a localhost migration, do the gnutls >> handshake >> with the dst, and dump the data over the gnutls connection to the dst. > [IH] how is the connection secured? Do you assume both hosts share > Kerberos/certificates trust? Does the controller pass a shared encryption > key to both parties? > (I also like this approach better, since it keeps the existing qemu > migration, which is hard enough to stabilize) Yes, in this case, the controller is passing a shared encryption key, which both sides will use to do the encryption and "prove" that they are the intended recipients. Note that this requires the user to have secure channels to each of the remote libvirtd's (otherwise it would be trivial to sniff the encryption key as we pass it to them), but that's pretty much a requirement in any production situation anyway. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list