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. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
