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')
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.
(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?
(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
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.
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?
(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/
(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.
I prefer auto-negotiate still.
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 ?.