----- Original Message ----- > From: "Andrew Cathrow" <[email protected]> > To: "Dan Kenigsberg" <[email protected]> > Cc: [email protected], "Michal Skrivanek" <[email protected]> > Sent: Thursday, January 10, 2013 4:06:35 PM > Subject: Re: tunnelled migration > > > > ----- 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. >
Agree, this really sound like an easy enhancement (and important), we can have this flag on the cluster as you say (default - false) and save for each vm the "migration tunnel policy" (?) if it's: cluster default, tunnelled or not tunnelled and pass it on migration. need to decide how it will look (named) in api and ui > > > > 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 > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
