----- Original Message ----- > From: "Dan Kenigsberg" <[email protected]> > To: [email protected] > Cc: "Michal Skrivanek" <[email protected]> > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
