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

On 03/01/2017 10:33 AM, Jiri Denemark wrote: 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-... Tks for any feedback - John