[libvirt] [PATCH v2 00/14] Add TLS support for migration

[John Ferlan]

On 03/01/2017 10:33 AM, Jiri Denemark wrote:
> On Wed, Mar 01, 2017 at 10:14:10 -0500, John Ferlan wrote:
>> On 03/01/2017 06:57 AM, Jiri Denemark wrote:
>> That jiggled a memory strand... It really wasn't clear from reading
>> QEMU's qapi-schema.json description that the Get would return anything
>> for tls-{creds,hostname}.
>>
>> So for determining whether the option exists or not I'm left to other
>> options it seems. Even if code is added (in 2.9) to provide something
>> like an empty string - that'd have to be backported to 2.8 and 2.7 and
>> we'd have to somehow ensure/hope that was applied so that the right
>> answer could be returned from Get...
> 
> Well, unless we have a way to reset the parameters we can't really use
> TLS migration anyway.
> 

Based on the qemu patch I see - the only way we'll know is by knowing
which version the patch has been applied.

We could set NULL or "", but that would seem to cause errors in versions
between 2.7 and wherever the fix ends up. <sigh>

While I'm thinking about these types of things... I started down the NBD
path too.  The server side would seem to be fairly trivial adding the
tls-creds to the command line; however, the client side is a bit more
tricky.

Currently (if I read the code right), NBD would use 'drive-mirror'
passing along the "*file" parameter as "nbd:%s:%d:exportname=%s", where
the first %s is the hostname, the %d is the port, and the exportname is
the diskAlias (see nbd_dest in qemuMigrationDriveMirror).

If I look at the qemu end of that - it will parse that nbd: prefixed
string, but the parsing code doesn't accept a tls-creds type parameter.

So more research leads me to a qemu-devel conversation :

http://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg07721.html

which in the long run I think implies libvirt should be using
blockdev-mirror instead. Of course that gets bogged down in a discussion
about blockdev-add, but let's say blockdev-mirror was usable.  How then
would the tls-creds be passed?  I see them added to the
@BlockdevOptionsNbd in QEMU's block-core.json, but it's not very clear
how they'd be provided. I assume some sort of json buffer magic, but
that's purely a guess. It's certainly not as simple as providing it
using the "-drive driver=nbd,host..." from as described on Daniel's TLS
blog post:

https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/

Tks for any feedback -

John