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