From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNieD-0002Gy-T8 for qemu-devel@nongnu.org; Thu, 14 Jul 2016 11:33:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNie8-0004Ne-SX for qemu-devel@nongnu.org; Thu, 14 Jul 2016 11:33:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNie8-0004N8-Kq for qemu-devel@nongnu.org; Thu, 14 Jul 2016 11:33:52 -0400 References: <1468418269-13490-1-git-send-email-prasanna.kalever@redhat.com> <1468418269-13490-4-git-send-email-prasanna.kalever@redhat.com> <87twfsy7ub.fsf@dusky.pond.sub.org> <87lh14v6dg.fsf@dusky.pond.sub.org> From: Eric Blake Message-ID: <5787B0DE.9010507@redhat.com> Date: Thu, 14 Jul 2016 09:33:50 -0600 MIME-Version: 1.0 In-Reply-To: <87lh14v6dg.fsf@dusky.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Tu4staxJclNndXD3mOaPLgM8R79In2w2w" Subject: Re: [Qemu-devel] [PATCH v18 3/4] block/gluster: using new qapi schema List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Prasanna Kalever Cc: Kevin Wolf , Peter Krempa , Prasanna Kumar Kalever , Jeffrey Cody , qemu-devel@nongnu.org, deepakcs@redhat.com, bharata@linux.vnet.ibm.com, Raghavendra Talur This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tu4staxJclNndXD3mOaPLgM8R79In2w2w From: Eric Blake To: Markus Armbruster , Prasanna Kalever Cc: Kevin Wolf , Peter Krempa , Prasanna Kumar Kalever , Jeffrey Cody , qemu-devel@nongnu.org, deepakcs@redhat.com, bharata@linux.vnet.ibm.com, Raghavendra Talur Message-ID: <5787B0DE.9010507@redhat.com> Subject: Re: [Qemu-devel] [PATCH v18 3/4] block/gluster: using new qapi schema References: <1468418269-13490-1-git-send-email-prasanna.kalever@redhat.com> <1468418269-13490-4-git-send-email-prasanna.kalever@redhat.com> <87twfsy7ub.fsf@dusky.pond.sub.org> <87lh14v6dg.fsf@dusky.pond.sub.org> In-Reply-To: <87lh14v6dg.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 mer= ely >>> 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 >=20 > After discussing this on IRC, I understand that: >=20 > * @server specifies a Gluster server >=20 > * @volume is effectively the name of a file name space on that server >=20 > * @path is a name in that name space >=20 > * Together, they specify an image file stored on Gluster. >=20 > If that's correct, the design makes sense for QMP. >=20 > 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 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Tu4staxJclNndXD3mOaPLgM8R79In2w2w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXh7DeAAoJEKeha0olJ0NqopYH/Re6JPEdqONoc0nfN66n9r4w 7ohCmO5adIhIlKJjRdKk2s5A6ZVp5JtmwZKaeoInOEP/29PzzU9kXWApAdeA6ywc ogQiCvqvxVoIoeR47iScsShToZ0Uxr+APu8UR8786hUvuVLRC2azjC8tmDSXNMiA n9XD/F+gvDpmIfGfscgV1bNswJa4nNpOXJVfib4JSKUN0XGspvMQwxm8FxRlYtuT jBvULUXKvt3Sq8thKUK3ZVhs8FTIxLrMME7oBeUUFHON6NJtijWn6TQTXJv4mZEu Eob3NXZ38MBT4ChOBf43Y46v/Ee1nunwcAFuMxa4zFgr5yVFDWquXQ49AOSr63o= =CteF -----END PGP SIGNATURE----- --Tu4staxJclNndXD3mOaPLgM8R79In2w2w--