From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwUWm-0000NN-Vq for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:34:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwUWh-0005Xa-7s for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:34:01 -0400 Date: Tue, 18 Oct 2016 15:33:45 +0200 From: Kevin Wolf Message-ID: <20161018133345.GH4706@noname.str.redhat.com> References: <20161014154639.GF3482@stefanha-x1.localdomain> <98a190a0-007b-3a83-8b31-f24de6a95335@redhat.com> <61e334e1-bfe5-7907-cad1-a490ec10f8da@kamp.de> <20161018130429.GG4706@noname.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-block] block/nfs: Fine grained runtime options in nfs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ashijeet Acharya Cc: Peter Lieven , Eric Blake , Stefan Hajnoczi , qemu-block@nongnu.org, jcody@redhat.com, QEMU Developers , Max Reitz Am 18.10.2016 um 15:14 hat Ashijeet Acharya geschrieben: > On Tue, Oct 18, 2016 at 6:34 PM, Kevin Wolf wrote: > > Am 18.10.2016 um 14:46 hat Ashijeet Acharya geschrieben: > >> On Tue, Oct 18, 2016 at 4:11 PM, Peter Lieven wrote: > >> > Am 17.10.2016 um 21:34 schrieb Ashijeet Acharya: > >> >> > >> >> On Tue, Oct 18, 2016 at 12:59 AM, Eric Blake wrote: > >> >>> > >> >>> On 10/17/2016 01:00 PM, Ashijeet Acharya wrote: > >> >>> > >> >>>> One more relatively easy question though, will we include @port as an > >> >>>> option in runtime_opts while converting NFS to use several > >> >>>> runtime_opts? The reason I ask this because the uri syntax for NFS in > >> >>>> QEMU looks like this: > >> >>>> > >> >>>> > >> >>>> nfs:////[?param=value[¶m2=value2[&...]]] > >> >>> > >> >>> It's actually nfs://[:port]/... > >> >>> > >> >>> so the URI syntax already supports port. > >> >> > >> >> But the commit message which added support for NFS had the uri which I > >> >> mentioned above and the code for NFS does not make use of 'port' > >> >> anywhere either, which is why I am a bit confused. > >> > > >> > > >> > Hi Aschijeet, > >> > > >> > don't worry there is no port number when connecting to an NFS server. > >> > The portmapper always listens on port 111. So theoretically we could > >> > specifiy a port in the URL but it is ignored. > >> > >> So that means I will be including 'port' in runtime_opts and then just > >> ignoring any value that comes through it? > > > > No, if there is nothing to configure there, leave it out. Adding an > > option that doesn't do anything is not very useful. > > > Okay, understood. > > So this is what my runtime_opts look like now: > > static QemuOptsList runtime_opts = { > .name = "nfs", > .head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head), > .desc = { > { > .name = "host", > .type = QEMU_OPT_STRING, > .help = "Host to connect to", > }, > { > .name = "export", > .type = QEMU_OPT_STRING, > .help = "Name of the NFS export to open", > }, > { > .name = "path", > .type = QEMU_OPT_STRING, > .help = "Path of the image on the host", > }, Does libnfs actually have separate export and path? If I understand correctly, we currently split the URL at the last / in the string. So is export the part before that and path the part after it? If so, does this mean that you can't currently access an image file in a subdirectory of an NFS mount and adding the explicit options will fix this? > { > .name = "uid", > .type = QEMU_OPT_NUMBER, > .help = "UID value to use when talking to the server", > }, > { > .name = "gid", > .type = QEMU_OPT_NUMBER, > .help = "GID value to use when talking to the server", > }, > { > .name = "tcp-syncnt", > .type = QEMU_OPT_NUMBER, > .help = "Number of SYNs to send during the session establish", > }, > { > .name = "readahead", > .type = QEMU_OPT_NUMBER, > .help = "Set the readahead size in bytes", > }, > { > .name = "pagecache", > .type = QEMU_OPT_NUMBER, > .help = "Set the pagecache size in bytes", > }, > { > .name = "debug", > .type = QEMU_OPT_NUMBER, > .help = "Set the NFS debug level (max 2)", > }, > { /* end of list */ } > }, > }; > > Please check if I have missed out on anything. I don't see anything, but then I'm not an expert on NFS either. I hope Peter can take a look. Though maybe it's easier to see in the context of the full patch. > I have successfully converted NFS block driver to use this set of > runtime opts which I think is the required condition to add > blockdev-add compatibility later. Also, since I do not have 'port' as > a runtime option, I can directly add blockdev-add compatibility after > this through qapi/block-core.json and will not have to go through the > tricky method we are implementing for NBD and SSH as there will be no > use of InetSocketAddress. Right? Yes, InetSocketAddress is what makes things a bit tricky, and it doesn't seem to be useful with the API we get from libnfs, so just directly taking a host name should be okay. Then this one should be easier than SSH. Eric, do you agree, or do you think we should take into account that libnfs might be extended one day to work on any socket? Kevin