Itamar Heim wrote:
From: libvir-list-bounces@redhat.com [mailto:libvir-list- bounces@redhat.com] 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