Re: [Qemu-devel] [PATCH v3] block/vxhs: Add Veritas HyperScale VxHS block device support

From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: ashish mittal <ashmit602@gmail.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Jeff Cody <jcody@redhat.com>,
	famz@redhat.com, Ashish Mittal <ashish.mittal@veritas.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Rakesh Ranjan <Rakesh.Ranjan@veritas.com>,
	Buddhi.Madhav@veritas.com, Ketan.Nilangekar@veritas.com,
	Abhijit.Dey@veritas.com, Venkatesha.Mg@veritas.com
Subject: Re: [Qemu-devel] [PATCH v3] block/vxhs: Add Veritas HyperScale VxHS block device support
Date: Wed, 2 Nov 2016 16:02:07 +0100	[thread overview]
Message-ID: <20161102150207.GI6182@noname.redhat.com> (raw)
In-Reply-To: <1be58a5d-3690-a9b2-d395-01c72ba64e78@redhat.com>

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

Am 02.11.2016 um 15:13 hat Eric Blake geschrieben:
> On 11/02/2016 04:57 AM, Kevin Wolf wrote:
> >>> IMHO it should allow use of UNIX sockets, as its possible to have
> >>> SSH setup a tunnel to a IP server, and expose the endpoint via a
> >>> UNIX socket. So even if your reference server only supports IPv4,
> >>> users can conceivably connect with any sockets protocol.
> >>>
> >>
> >> This is not a use-case that we have in mind right now, but a very fair
> >> point! Kind of like accessing the audio/video streams remotely from my
> >> Raspberry Pi over ssh. Is it OK if we target this in a future patch
> >> after proper review/testing?
> > 
> > No, going from InetSocketAddress to SocketAddress changes the API in an
> > incompatible way (previously working blockdev-add commands would stop
> > working), so we must decide now before the API is introduced.
> 
> Going from InetSocketAddress to SocketAddress is a pain because
> SocketAddress is a 'simple union' (which really means extra nesting on
> the wire).  I'd really rather that blockdev-add move towards the
> GlusterServer style of a 'flat union', which CAN be done in a
> backwards-compatible manner.

However, the actual networking functions in qemu take a SocketAddress or
InetSocketAddress pointer, not whatever else we would invent for the
block layer API, so we would have to add conversion functions. The whole
point of using these types was to have a consistent API with other
subsystems. :-/

gluster and NFS can use something different only because they don't use
the qemu networking functions, but whatever limited set of options their
external library supports.

> [side note: Uggh - why did we let gluster go into 2.7 with 'tcp' instead
> of 'inet' :( I'm wondering if we want gluster in 2.8 to recognize 'inet'
> as a synonym for 'tcp'; I could propose a patch if we think it is
> worthwhile]

Fine with me. Remove 'tcp' from the schema then as long as blockdev-add
is still experimental. We only need to keep it working on the command
line.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]