Bug 1263145 - Switch from NFS3 to AUTONEGOTIATE for NFS domains
Switch from NFS3 to AUTONEGOTIATE for NFS domains
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
3.6.0
Unspecified Unspecified
unspecified Severity low (vote)
: ovirt-4.1.0-beta
: ---
Assigned To: Tal Nisan
Raz Tamir
: EasyFix, FutureFeature, Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 04:22 EDT by Roman Mohr
Modified: 2017-01-31 13:09 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-31 13:09:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1?
gklein: testing_plan_complete-
rule-engine: planning_ack?
tnisan: devel_ack+
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Roman Mohr 2015-09-15 04:22:55 EDT
Description of problem:

When adding NFS storage, NFS3 is preselected in ovirt-engine and not even visible for the admin.

Version-Release number of selected component (if applicable):


How reproducible:
Add a NFS4 storage domain.

Steps to Reproduce:
1. Got to Storage tab and klick "New Domain"
2. Enter a domain name and the nfs4 storage path
3. Create the domain

Actual results:

So when mounting NFS4 storage as NFS3 storage the admin sees a waiting screen for several minutes until vdsm reports back a timeout, which is just displayed as a cryptic connection error in the gui.

Expected results:

 1) Properly report the timeout to the GUI
 2) Preselect AUTONEGOTIATE instead of NFS3
 3) Do not hide this field in "Custom Connection Parameters"

I think AUTONEGOTIATE would be a good choice because in more and more distros NFS4 is nowadays the standard.

Additional info:

Like the tool mount, when mounting with -o nfsvers=3, vdsm runs into a timeout:

  Thread-571::ERROR::2015-09-15 10:00:50,389::hsm::2454::Storage.HSM::
  (connectStorageServer) Could not connect to storageServer
  MountError: (32, ';mount.nfs: Connection timed out\n')
Comment 1 Yaniv Kaul 2015-09-16 01:55:36 EDT
You seem to have combined 3 issues into one:
1) Properly report the timeout to the GUI
2) Preselect AUTONEGOTIATE instead of NFS3
3) Do not hide this field in "Custom Connection Parameters"

Specifically, solving the 3rd one might be a better idea - I don't remember why, but there was a reason we preferred not to use auto-negotiation. Perhaps in the days where v4 wasn't that great (required some more user set up first).

I think there's also a bug on the 1st one - couldn't find it right now in a quick BZ search.
Comment 2 Allon Mureinik 2015-09-16 05:50:23 EDT
(In reply to Yaniv Kaul from comment #1)
> You seem to have combined 3 issues into one:
> 1) Properly report the timeout to the GUI
Should be solved. Roman - please open a separate BZ so we can track this properly.

> 2) Preselect AUTONEGOTIATE instead of NFS3
NFS3 has proven to a much stabler default, on numerous occasions. Perhaps it's time to re-evaluate that decision, but we need a lot more customer data.
Yaniv D - any input here?

> 3) Do not hide this field in "Custom Connection Parameters"
It just adds clatter to the domain. Most the user, most of the time, wouldn't want to mess with it. 
But again, we need a broader picture here. 
Yaniv D?
Comment 3 Roman Mohr 2015-09-16 06:18:50 EDT
(In reply to Allon Mureinik from comment #2)
> (In reply to Yaniv Kaul from comment #1)
> > You seem to have combined 3 issues into one:
> > 1) Properly report the timeout to the GUI
> Should be solved. Roman - please open a separate BZ so we can track this
> properly.

will do so.

> > 2) Preselect AUTONEGOTIATE instead of NFS3
> NFS3 has proven to a much stabler default, on numerous occasions. Perhaps
> it's time to re-evaluate that decision, but we need a lot more customer data.
> Yaniv D - any input here?

I guess all long time customers are aware of that but for instance on fedora nfs4 is the default when you set up a nfs server. So everyone who tries out oVirt on fedora the first time will run into this.

And the rhel documentation [1] says:
  Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.

So we already prefer nfs4 in RHEL as client and we seem to use auto negotiate there too.

> > 3) Do not hide this field in "Custom Connection Parameters"
> It just adds clatter to the domain. Most the user, most of the time,
> wouldn't want to mess with it. 
> But again, we need a broader picture here. 
> Yaniv D?

But why should it be clutter? Isn't it vital to correctly configure the protocol version, especially when we do not use auto negotiate ?

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-nfs.html
Comment 4 Yaniv Lavi 2015-09-22 06:02:02 EDT
There is user demand to move to NFS v4 on fc or RHEL.
There is also no proven advantages to moving to v4. 
I would not consider moving AUTONEGOTIATE unless the above changes.
Comment 5 Yaniv Lavi 2016-12-06 06:34:50 EST
I suggest closing and deferring to BZ #1162635. When NFS v5 is out I will not what this to auto switch to latest nfs protocol. We can make a choice to upgrade the default and that should be good enough. What do you think?
Comment 6 Yaniv Kaul 2016-12-06 06:39:29 EST
(In reply to Yaniv Dary from comment #5)
> I suggest closing and deferring to BZ #1162635. When NFS v5 is out I will
> not what this to auto switch to latest nfs protocol. We can make a choice to
> upgrade the default and that should be good enough. What do you think?

There is no NFSv5, and it's not even in the planning.
The whole idea about auto-negotiating is fallback. If you fail with v4, v3 should work. This also solves the other bug - there is no need for v4 if auto-negotiate is enabled.

BTW, see http://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/
Comment 7 Yaniv Lavi 2016-12-11 10:08:44 EST
(In reply to Yaniv Kaul from comment #6)
> (In reply to Yaniv Dary from comment #5)
> > I suggest closing and deferring to BZ #1162635. When NFS v5 is out I will
> > not what this to auto switch to latest nfs protocol. We can make a choice to
> > upgrade the default and that should be good enough. What do you think?
> 
> There is no NFSv5, and it's not even in the planning.
> The whole idea about auto-negotiating is fallback. If you fail with v4, v3
> should work. This also solves the other bug - there is no need for v4 if
> auto-negotiate is enabled.
> 
> BTW, see http://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/

I'm talking theoretically, I prefer we change the default to a tested version. Not switch automatically. I suggest closing as WONT FIX.
Comment 8 Yaniv Kaul 2016-12-19 08:44:33 EST
I prefer auto-negotiate still.
Comment 9 Red Hat Bugzilla Rules Engine 2017-01-31 08:19:01 EST
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Note You need to log in before you can comment on or make changes to this bug.