Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1200150

Summary: NFS mount to XENserver versions 6.2 and 6.5 fails. Incompatible NFS version. Gluster 3.6.2
Product: [Community] GlusterFS Reporter: Alexander Smirnov <asmirnov>
Component: nfsAssignee: bugs <bugs>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.6.2CC: asmirnov, bugs, jthottan, ndevos, sasundar
Target Milestone: ---Keywords: Regression, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-30 12:52:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Typical XenServer gui error
none
if you scan the SR in Xen server you can see the failed attempts did produce the virtual drive none

Description Alexander Smirnov 2015-03-09 20:42:49 UTC
Description of problem:


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


How reproducible:
Create/obtain an access to an instance of XenServer 6.2 or 6.5 (patch level not important)

Steps to Reproduce:
1. Create new volume on gluster.
2. Apply group 'virt' to the volume
3. Try to create new SR from the Xen Server
4. You will recieve the error, stating that the version of NFS is incompatible.

Actual results:
XenServer 6.2 or 6.5 fails to create new SR reporting the NFS version incompatability

Expected results:
New SR created.

Additional info:
Everything works fine with version 3.5 of GlusterFS.

Comment 1 Alexander Smirnov 2015-03-09 21:57:03 UTC
Correction to the problem:
Gluster version 3.6.1 works, 3.6.2 does not. I just assembled a little test environment. I will produce more info.

Comment 2 Alexander Smirnov 2015-03-09 21:58:53 UTC
Created attachment 999680 [details]
Typical XenServer gui error

Comment 3 Alexander Smirnov 2015-03-09 22:01:20 UTC
Created attachment 999681 [details]
if you scan the SR in Xen server you can see the failed attempts did produce the virtual drive

If you try to remount that drive - you will fail.

Comment 4 Alexander Smirnov 2015-03-09 22:03:37 UTC
It is strange as today I am getting a different error. The same XEN version 6.5 latest updates connecting to the same physical box, freshly installed this morning, which runs: CentOS 6.6 latest, Gluster 3.6.2-1.

Other servers which are in production are running 3.6.1 for the reason of comparability. We have this setup running for over 2 years now, but we can not update Gluster as we loose connectivity with Xen.

Comment 5 Alexander Smirnov 2015-03-09 22:04:14 UTC
Additional information - we can mount the volume via Gluster client without a problem.

Comment 6 Niels de Vos 2015-03-10 12:42:47 UTC
Could you please provide the following details, preferably on an environment that does not have anything else to do (a one-server Gluster env works fine for this).

0. create a one-brick volume for testing
1. enable more verbose logging for the NFS-server
    # gluster volume set $VOLUME diagnostics.client-log-level DEBUG
2. start a tcpdump to capture the NFS and GlusterFS traffic on the Gluster/NFS
   server
    # tcpdump -s 0 -i any -w /path/to/tcpdump.pcap tcp and not port 22
3. do whatever XEN-Server things are needed to make it fail
4. kill the tcpdump (CTRL+C or just 'pkill tcpdump')
5. gzip the /path/to/tcpdump.pcap
6. disable the logging
    # gluster volume reset $VOLUME diagnostics.client-log-level

Attach the /var/log/glusterfs/nfs.log and the gzipped .pcap file to this bg report.

It might be very helpful if you can also do this test with 3.6.1 where it should work. We can then compare the tcpdumps and check where things start to go wrong.

Comment 7 Alexander Smirnov 2015-03-10 13:35:46 UTC
Thank you for your response. The server I used last night have been rebuild and put back in production. I will have another node re-purposed next week. All our storage hardware is identical, so the test will be clean. Please expect a report around March 16th - 17th.

Regards,
Alexander V. Smirnov