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
signature.asc
Description: OpenPGP digital signature