On 01/10/2013 04:46 PM, Omer Frenkel wrote: > > > ----- 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
from the api PoV, it's pretty simple: 1. boolean at cluster to represent the policy. 2. boolean at vm.migrate action parameters 3. if vdsm will report that host supports 'tunnelled migration', r/o boolean in host. (doesn't have strong opinion for naming) > >>> >>> 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 -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
