[openstack-dev] [cinder] [nova] How to provide additional options to NFS backend?
jsuchome at suse.cz
Wed Jun 7 15:15:44 UTC 2017
V Wed, 31 May 2017 11:34:20 -0400
Eric Harney <eharney at redhat.com> napsáno:
> On 05/25/2017 05:51 AM, Jiri Suchomel wrote:
> > Hi,
> > it seems to me that the way of adding extra NFS options to the
> > cinder backend is somewhat confusing.
> > 1. There is nfs_mount_options in cinder config file 
> > 2. Then I can put my options to the nfs_shares_config file - that
> > it could contain additional options mentiones  or the
> > commit message that adds the feature 
> > Now, when I put my options to both of these places, cinder-volume
> > actually uses them twice and executes the command like this
> > mount -t nfs -o nfsvers=3 -o nfsvers=3
> > 192.168.241.10:/srv/nfs/vi7/cinder /var/lib/cinder/mnt/f5689da9ea41a66eff2ce0ef89b37bce
> > BTW, the options coming from nfs_shares_config are called 'flags' by
> > cinder/volume/drivers/nfs ().
> > Now, to make it more fun, when I actually want to attach a volume to
> > running instance, nova uses different way of realizing which NFS
> > options to use:
> > - It reads them from _nova_ config option of
> > libvirt.nfs_mount_options 
> > - or it uses those it gets them from cinder when creating cinder
> > connection  But these are only the options defined in
> > nfs_shares_config file, NOT those nfs_mount_options specified in
> > cinder config file.
> > So. If I put my options to both places, nfs_shares_config file and
> > nfs_mount_options, it actually works how I want it to work, as
> > current mount does not complain that the option was provided twice.
> > But it looks ugly. And I'm wondering - am I doing it wrong, or
> > is there a problem with either cinder or nova (or both)?
> This has gotten a bit more confusing than in necessary in Cinder due
> to how the configuration for the NFS and related drivers has been
> tweaked over time.
> The method of putting a list of shares in the nfs_shares_config file
> is effectively deprecated, but still works for now.
> The preferred method now is to set the following options:
> nas_host: server address
> nas_share_path: export path
> nas_mount_options: options for mounting the export
> So whereas before the nfs_shares_config file would have:
> 127.0.0.1:/srv/nfs1 -o nfsvers=3
> This would now translate to:
> nas_mount_options = -o nfsvers=3
> I believe if you try configuring the driver this way, you will get the
> desired result.
Nope, this does not work.
If I provide nas_mount_options, mount command tries to use them twice.
os_brick.remotefs.remotefs, _do_mount gets them in the form of "flags"
as well as "options" :
- mount_flags are coming from the shares structure before
cinder.volume.nfs calls _remotefsclient.mount . They were written
there by cinder/volume/drivers/remotefs when the suggested nas_*
configuration options were found
- mount_options are created in the constructor of RemoteFsClient from
nfs_mount_options  which are passed from cinder.volume.drivers.nfs
So this means that the mount command gets the options twice.
But not only that! os-brick/remotefs.py's _do_mount adds an extra -o
option to the list of options (apparently because both
nas_mount_options and nfs_mount_options have different syntax!) which
makes the mount command fail for sure.
So, to summarize:
- nfs_mount_options in cinder conf is ignored when cinder connection
is passed to nova
- nas_mount_options seems to be broken with NFS backend (as described
- options provided in nfs_shares_config file are passed to mount
command twice, but this does not necessary hurt, so this solution
actually works (and has additional bonus of possibility to define
mount options per mount point)
SUSE LINUX, s.r.o.
18600 Praha 8
More information about the OpenStack-dev