On Mon, Feb 20, 2017 at 09:25:25AM -0500, Jeff Cody wrote:
> On Feb 20, 2017 8:49 AM, "Paolo Bonzini" <pbonz...@redhat.com> wrote:
>
>
>
> On 20/02/2017 11:07, Daniel P. Berrange wrote:
> >> + if (qemu_uuid_is_null(&qemu_uuid)) {
> > This is the wrong check - QEMU provides a 'qemu_uuid_set' boolean
> > to determine if 'qemu_uuid' is set or not. If it is not set, then
> > the code should return an error, not use a hardcoded uuid.
>
> Or otherwise that hardcoded uuid should be all zeroes (UUID_NONE).
>
>
>
> (Replying from phone, sorry for formatting issues)
>
> I think the issue is that boolean is not defined when linking qemu-img, so
> if it is used in vxhs.c there will be a linking error. I can't test that
> hypothesis right now, though, as I am traveling.
>
> This also ties into the TLS certs, I believe. The uuid is being used by
> libqnio to determine the cert path, to allow/disallow certain operations
> based on if it is being called by qemu-img/io or qemu, etc.
That just illustrates further why using the UUID to decide TLS cert path
is a bad idea. We need to be able to choose the right certs when using
qemu-img/qemu-nbd, just like we need that when running QEMU - falling
back to a hardcoded UUID would mean you can't ever run two concurrent
instances of qemu-img with different certs.
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/ :|
