tunnelled migration

[Omer Frenkel]

----- Original Message -----
> From: "Andrew Cathrow" <acathrow at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: arch at ovirt.org, "Michal Skrivanek" <mskrivan at redhat.com>
> Sent: Thursday, January 10, 2013 4:06:35 PM
> Subject: Re: tunnelled migration
> 
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: arch at ovirt.org
> > Cc: "Michal Skrivanek" <mskrivan at redhat.com>
> > 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
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>