tunnelled migration

[Andrew Cathrow]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: arch at ovirt.org
> Cc: "Michal Skrivanek" <mskrivan at redhat.com>
> Sent: Thursday, January 10, 2013 8:38:34 AM
> Subject: tunnelled migration
> 
> For a long long time, libvirt supports a VIR_MIGRATE_TUNNELLED
> migration
> mode. In it, the qemu-to-qemu communication carrying private guest
> data,
> is tunnelled within libvirt-to-libvirt connection.
> 
> libvirt-to-libvirt communication is (usually) well-encrypted and uses
> a
> known firewall hole. On the downside, multiplexing qemu migration
> traffic and encrypting it carries a heavy burdain on libvirtds and
> the
> hosts' cpu.
> 
> Choosing tunnelled migration is thus a matter of policy. I would like
> to
> suggest a new cluster-level configurable in Engine, that controls
> whether
> migrations in this cluster are tunnelled. The configurable must be
> available only in new cluster levels where hosts support it.
> 
> The cluster-level configurable should be overridable by a VM-level
> one.
> An admin may have a critical VM whose data should not migrate around
> in
> the plaintext.
> 
> When Engine decides (or asked) to perform migration, it would pass a
> new
> "tunnlled" boolean value to the "migrate" verb. Vdsm patch in these
> lines is posted to http://gerrit.ovirt.org/2551
> 
> I believe it's pretty easy to do it in Engine, too, and that it would
> enhance the security of our users.

It should be disabled by default given the significant overhead.

> 
> Dan.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>