Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On 02/04/2015 07:02 AM, Daniel P. Berrange wrote:

>>
>> I think fixing this for migration might simplify stuff for users a lot as well;
>> the choice of whether libvirt does tunneling or not and what it means
>> for how block migration happens etc can get very confusing.
> 
> Yes, and not helped by the fact that no single current impl offers all
> desired features - they are all partially overlapping sets :-(

>> Some things to keep in mind:
>>   1) The current patch from Liang Li doing multi threaded compression
>>      It just strikes me as an exmaple of another type of filter in the migration
>>      stream.
> 
> Yes, that does make sense in that way,
> 
>>   2) Postcopy and fault tolerance need a bidirectional channel; and that back
>>      channel tends to be small messages.
> 
> TLS will require bidirectional channels too in order to perform the
> handshake. SASL will require bidirectional channels too. So this
> seems rather inevitable.
> 
>>   3) I'd considered making a separate socket/fd for passing page data
>>      in the hope of maybe making that page take data via splice; but am not
>>      sure yet.

Another thing to think about - should migration to file be something
that can be encrypted?  There, you don't have the luxury of a
bidirectional channel, but securing the machine state so that only an
authenticated user can decrypt to reload the state later sounds like
another benefit that might be possible.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]