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
+1 for gaining security quick with small effort.
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
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
