On Tue, Oct 18, 2016 at 9:43 PM, Ashijeet Acharya <ashijeetacha...@gmail.com> wrote: > On Tue, Oct 18, 2016 at 7:03 PM, Kevin Wolf <kw...@redhat.com> wrote: >> Am 18.10.2016 um 15:14 hat Ashijeet Acharya geschrieben: >>> On Tue, Oct 18, 2016 at 6:34 PM, Kevin Wolf <kw...@redhat.com> wrote: >>> > Am 18.10.2016 um 14:46 hat Ashijeet Acharya geschrieben: >>> >> On Tue, Oct 18, 2016 at 4:11 PM, Peter Lieven <p...@kamp.de> wrote: >>> >> > Am 17.10.2016 um 21:34 schrieb Ashijeet Acharya: >>> >> >> >>> >> >> On Tue, Oct 18, 2016 at 12:59 AM, Eric Blake <ebl...@redhat.com> >>> >> >> 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://<host>/<export>/<filename>[?param=value[¶m2=value2[&...]]] >>> >> >>> >>> >> >>> It's actually nfs://<host>[: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? > > At the moment, I don't see any piece of code in NFS BLOCK DRIVER which > does that to extract export from the URL. We actually do this at the > moment: > > strp = strrchr(uri->path, '/'); > > which I think is just to extract the name of the file from the URL and > has nothing to do with export. > Although NBD and gluster seem to extract export from the URL like this: > > p += strspn(p, "/"); > > which actually splits the URL at the first appearance of "/", doesn't > it? And then does after checking for p[0]: > > qdict_put(options, "export", qstring_from_str(p)); > > which puts the value of key export in qdict as the part of the URL > which occurs after the first appearance of "/", right? > >> >> 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? > > I am not sure of that :-/ > But either way I think I will have to drop export and was a silly mistake to include it, since it is extracted from path one way or another.
Ashijeet