Re: [Qemu-devel] [PATCH v18 3/4] block/gluster: using new qapi schema

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

On 07/14/2016 04:52 AM, Markus Armbruster wrote:

>>>> +
>>>> +##
>>>> +# @BlockdevOptionsGluster
>>>> +#
>>>> +# Driver specific block device options for Gluster
>>>> +#
>>>> +# @volume:      name of gluster volume where VM image resides
>>>> +#
>>>> +# @path:        absolute path to image file in gluster volume
>>>> +#
>>>> +# @server:      gluster server description
>>>> +#
>>>> +# @debug_level: #libgfapi log level (default '4' which is Error)
>>>> +#
>>>> +# Since: 2.7
>>>> +##
>>>> +{ 'struct': 'BlockdevOptionsGluster',
>>>> +  'data': { 'volume': 'str',
>>>> +            'path': 'str',
>>>> +            'server': 'GlusterServer',
>>>> +            '*debug_level': 'int' } }
>>>

GlusterServer is very similar to the existing SocketAddress; the
questions at hand are whether it should be a flat union instead of a
simple union, and whether 'port' on the 'inet' branch should accept
integers instead of (or in addition to) strings.  Also, if you're going
to immediately convert it to an array of servers in the next patch, it
may be better to do that up front; I guess it boils down to how much
churn there is in converting the rest of the code.  If it is
intentionally different from the final version, at least explicitly call
that out in the commit message.

>>> Are @volume and @path interpreted in any way in QEMU, or are they merely
>>> sent to the Gluster server?
>>
>> have a look at libglfsapi (IMO which is poorly designed)
>> glfs_set_volfile_server (struct glfs *fs, const char *transport, const
>> char *host, int port)
>>
>> So the @volume and @path are parsed from the command line args and
>> filled in 'struct glfs' object
> 
> After discussing this on IRC, I understand that:
> 
> * @server specifies a Gluster server
> 
> * @volume is effectively the name of a file name space on that server
> 
> * @path is a name in that name space
> 
> * Together, they specify an image file stored on Gluster.
> 
> If that's correct, the design makes sense for QMP.
> 
> Is the legacy syntax involving a gluster URI accessible via QMP?

As far as I know, 'blockdev-add' doesn't yet support gluster, so the
only way to hotplug a gluster volume at the moment via QMP is to resort
to HMP command passthrough.  At least libvirt is still using HMP
passthrough for all block device hotplugs, for two reasons: 1.
blockdev-add is incomplete, 2. libvirt hasn't been taught to use node
names everywhere

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]