Re: [Qemu-devel] [PATCH v9 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Feb 20, 2017 at 09:25:25AM -0500, Jeff Cody wrote:
> On Feb 20, 2017 8:49 AM, "Paolo Bonzini" <pbonzini@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/ :|