tunnelled migration

[Michael Pasternak]

On 01/10/2013 04:46 PM, Omer Frenkel wrote:
> 
> 
> ----- 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

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
>>> 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
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D