I will try to make all the requested traces, NFS3, NFS4.1 and if a VM is okay I will also set up a FreeBSD NFS server.
Not sure if I can do it on weekend, but Monday should work.
I can not to 100% say that there are no such errors on FreeBSD, as I don't have the old servers running anymore, but I had this running now for years and did not see any issues (beside the usual ESXi/browser ones) when importing/exporting VMs.
It is also not ESXi 7.2 specific, as I receive similar error on ESXi 6.7.
What I forgot to mention is that it sometimes, worked,, maybe 1 out of 30 try's. but no clue what is different and why.
I will try to trace also one of this cases.
I am afraid that VMware will not support here. They simply tell that a Linux Server is not supported. ????
If I could I would abode ESXi, but I am somehow forced to also use it beside other hypervisors.
I thought NFS4.1 should be NFS4.1, independent of the vendor.
On the other hand this setup using NFS server as datastore is really great. NFS3, works also without any issues, but NFS4.1 session trunking makes this also useable on hosts connected with several 1G NICs.
Best regards,
Andreas
Von: Chuck Lever III <[email protected]>
Gesendet: Freitag, 22. April 2022 16:29
An: Rick Macklem <[email protected]>
Cc: Bruce Fields <[email protected]>; [email protected] <[email protected]>; Linux NFS Mailing List <[email protected]>
Betreff: Re: Problems with NFS4.1 on ESXi
> On Apr 21, 2022, at 7:52 PM, Rick Macklem <[email protected]> wrote:
>
> J. Bruce Fields <[email protected]> wrote:
> [stuff snipped]
>> On Thu, Apr 21, 2022 at 12:40:49PM -0400, bfields wrote:
>>>
>>>
>>> Stale filehandles aren't normal, and suggest some bug or
>>> misconfiguration on the server side, either in NFS or the exported
>>> filesystem.
>>
>> Actually, I should take that back: if one client removes files while a
>> second client is using them, it'd be normal for applications on that
>> second client to see ESTALE.
> I took a look at crispyduck's packet trace and here's what I saw:
> Packet#
> 48 Lookup of test-ovf.vmx
> 49 NFS_OK FH is 0x7c9ce14b (the hash)
> ...
> 51 Open Claim_FH fo 0x7c9ce14b
> 52 NFS_OK Open Stateid 0x35be
> ...
> 138 Rename test-ovf.vmx~ to test-ovf.vmx
> 139 NFS_OK
> ...
> 141 Close with PutFH 0x7c9ce14b
> 142 NFS4ERR_STALE for the PutFH
>
> So, it seems that the Rename will delete the file (names another file to the
> same name "test-ovf.vmx". Then the subsequent Close's PutFH fails,
> because the file for the FH has been deleted.
So, Rick, Andreas: does this sequence of operations work without
error against a FreeBSD NFS server?
--
Chuck Lever
I