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/ :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
