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

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: