tunnelled migration

[Dan Kenigsberg]

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.

Dan.