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

[Daniel P. Berrange]

On Wed, Mar 01, 2017 at 12:47:18PM -0500, John Ferlan wrote:
> 
> 
> 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.

Yep, we can't use the legacy URI syntax - we need the block dev property
syntax.

> 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

IIRC, the conclusion was that its possible use blockdev-mirror, without
using blockdev-add

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

> 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:

The 'tls-creds' parameter in @BlockdevOptionsNbd just refers to the ID
of the TLS credentials object previously created with object-add. In
fact we should use the same TLS credentials for both the migration
server/client and the associated NBD server/client.

IIRC, in  JSon, @BlockdevOptionsNbd ends up looking something like


 {
   'driver': 'nbd',
   'data': {
     'server': {
       'inet': {
         'host': 'foobar'
	 'port': '9000'
       }
     },
     'tls-creds': 'tls0'
   }

(Not entirely sure if i need another level of nesting in between the
'server' and 'inet' bit or not ).

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|