[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels
Date: Wed, 04 Feb 2015 11:34:08 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]