Support NFSv4+ only storage repositories

[jcharaoui]

On servers where NFSv3 is disabled and NFSv4+ is enabled and working, rpcbind and showmount commands do not work, causing the nfs.py helper functions to falsely conclude that the server is unreachable.

When activating an SR configured for NFSv4+, check_server_tcp() and check_server_service() should probably be skipped, or maybe execute a simple check that 2049/tcp is open on the remote.

As discussed in xcp-ng/xcp#135

[olivierlambert]

@edwintorok is there anything we can do to assist on this?

[MarkSymsCtx]

There needs to be some check of connectivity viability otherwise incorrect details given to a probe operation will take a full TCP session timeout to fail (~75 seconds) and that's terrible user experience. Using util.testHost to hit 2049/tcp is probably a reasonable start for that. The showmount call I think can be replaced by connecting to the server with no share name and running an ls on it but whether this is universal or just something that the Linux nfs-server-common does I'm not sure.

[olivierlambert]

TCP session timeout to fail (~75 seconds) and that's terrible user experience

I agree. So it's a 2 stages check:

1. TCP 2049 port check with util.testHost
2. Checking if we can actually mount it and browse it (I'm just no sure exactly what's the best way to do it, we might check what nfs-server-common is doing in the first place, as you suggested.

@marcungeschikts we need to get that in our backlog

[emanzx]

I have been waiting for this issue to be fix for almost a year. I dont know how to help. But from what @MarkSymsCtx suggested I think that is ok. and I am not sure if this correct. I just try asking chatGPT about how mount verify the validity of the shared NFS and it gave me this answer..

The mount command verifies the validity of a shared NFS file system in several ways. First, it performs a network-based check to see if the NFS server is reachable and if the specified NFS share is available on the server. The mount command uses the Remote Procedure Call (RPC) protocol to communicate with the NFS server and verify the availability of the share. The mount command can also check the validity of the NFS share by checking the file system type, and verifying that the NFS version and transport protocol are supported. Once the mount command has verified the validity of the NFS share, it will mount the share to the specified local mount point. If the NFS share is not available or if there is an error in the configuration, the mount command will return an error and the file system will not be mounted.

but when I asked NSFv4 above does not have RPC available and how mount verifies it.. I get this answer.

In NFS version 4.0 and later, the mount command verifies the validity of the shared file system without using the traditional RPC call. Instead, it uses the Network Lock Manager (NLM) protocol, which provides file locking and recovery services. When a client mounts an NFS file system, it establishes a connection to the NFS server and then sends a request to lock a specific file on the file system. If the lock is granted, it means that the file system is available, and the client can proceed to access the file system. If the lock is not granted, it means that the file system is not available, and the client should retry the request later. This way, the mount command can verify the validity of the shared file system without relying on the traditional RPC call.

not sure if this documented elsewhere.. but doing ls would be enough I think. but using NLM will surely verify the NFS is only for NFSv4 above.

[olivierlambert]

We'll try to move forward and to make a PoC here if we can. If it works (we have a test server in NFSv4 only), we can create a PR against this repo to fix it 👍