Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
 
Search the VMware Knowledge Base (KB)   View by Article ID
 

Definition of the advanced NFS options

Details

This articles provides insight on advanced NFS settings.
 
Warning: VMware does not recommend making changes to the default settings.

Solution

To access the NFS advanced options:
  1. Log into the VMware Infrastructure Client.
  2. Select the ESX host.
  3. Click the Configuration tab.
  4. Click Advanced Settings.
  5. Select NFS.
This is a list of each setting and a brief description of each one.
 
Note: If the NFS HeartBeat advanced option values are modified, a reboot of the ESX host is required.
  • NFS.IndirectSend 
    This is a debugging option. Do not use this for any other reason. It causes all NFS IOs to be queued to a helper world and decreases performance if enabled.
     
  • NFS.DiskFileLockUpdateFreq 
    The time between updates to the NFS lock file on the NFS server. Increasing this value increases the time it takes to recover stale NFS locks. (See     NFS Locking)
     
  • NFS.LockUpdateTimeout 
    The amount of time before a lock update request is aborted. (See     NFS Locking)
     
  • NFS.LockRenewMaxFailureNumber
    The number of lock update failures that must occur before the lock is marked as stale. (See     NFS Locking)
     
  • NFS.LockDisable
    This is a debugging option. This option can cause data corruption and should not be used without assistance from VMware Technical Support. This option has been removed from ESX 4.0.
     
  • NFS.HeartbeatFrequency
    This sets how often the NFS heartbeat world runs to see if any NFS volumes need a heartbeat request. (See     NFS Heartbeats)
     
  • NFS.HeartbeatTimeout 
    The amount of time before aborting a heartbeat request. (See     NFS Heartbeats)
     
  • NFS.HeartbeatDelta 
    The amount of time after a successful GETATTR request before the heartbeat world issues a heartbeat request for a volume. If an NFS volume is in an unavailable state, an update is sent every time the heartbeat world runs (NFS.HeartbeatFrequency seconds). (See     NFS Heartbeats)
     
  • NFS.HeartbeatMaxFailures 
    The number of consecutive heartbeat requests that must fail before the server is marked as unavailable. (See     NFS Heartbeats)
     
  • NFS.MaxVolumes 
    The maximum number of NFS volumes that can be mounted. The TCP/IP heap must be increased to accommodate the number of NFS volumes configured. (See     TCP/IP Heap Size).
     
  • NFS.SendBufferSize 
    The size of the send buffer for NFS sockets. This value was chosen based on internal performance testing. VMware does not recommend adjusting this value.
     
  • NFS.ReceiveBufferSize 
    This is the size of the receive buffer for NFS sockets. This value was chosen based on internal performance testing. VMware does not recommend adjusting this value.
     
  • NFS.VolumeRemountFrequency 
    This determines how often an NFS volume attempts to mount when it is initially unable to mount. After a volume is mounted it never needs to be remounted. The volume may be marked unavailable if it loses connectivity to the NFS server but it still remains mounted.
     
  • NFS.UDPRetransmitDelay 
    This option is not used, we do not currently support NFS over UDP.
 
NFS Locking
 
NFS locking on ESX does not use the NLM protocol. VMware has its own locking protocol. NFS locks are implemented by creating lock files on the NFS server. Lock files are named .lck-<fileid>, where <fileid> is the value of the fileid field returned from a GETATTR request for the file being locking. When a lock file is created an update is periodically (every NFS.DiskFileLockUpdateFreq seconds) sent to the lock file to let other ESX hosts know that the lock is still active. The lock file updates generate small (84 byte) WRITE requests to the NFS server. Changing any of the NFS locking parameters changes how long it takes to recover stale locks. This formula can be used to calculate how long it takes to recover a stale NFS lock:
 
(NFS.DiskFileLockUpdateFreq * NFS.LockRenewMaxFailureNumber) + NFS.LockUpdateTimeout

This example demonstrates the above equation using the default values in VMware ESX 3.5:
X is the length of time it takes to recover from a stale NFS lock.
X = (NFS.DiskFileLockUpdateFreq * NFS.LockRenewMaxFailureNumber) + NFS.LockUpdateTimeout
X = (10 * 3) + 5
X = 35 seconds
 
If any of these parameters are modified it is very important that all ESX hosts in the cluster use identical settings. Having inconsistent NFS lock settings across ESX hosts can result in data corruption.
 
NFS Heartbeats
 
NFS heartbeats are used to determine whether or not an NFS volume is still available. NFS heartbeats are actually GETATTR requests on the root file handle of the NFS Volume. There is a system world that runs every NFS.HeartbeatFrequency seconds to check if it needs to issue heartbeat requests for any of the NFS volumes. If a volume is marked available, it only issue a heartbeat if it has been NFS.HeartBeatDelta seconds since it issued a successful GETATTR (not necessarily a heartbeat GETATTR) for that volume. The NFS heartbeat world always issues heartbeats for NFS volumes which are marked unavailable. Here is the formula to calculate how long it can take ESX to mark an NFS volume as unavailable:
 
RoundUp(NFS.HeartbeatDelta, NFS.HeartbeatFrequency) + (NFS.HeartbeatFrequency * (NFS.HeartbeatMaxFailures - 1)) + NFS.HeartbeatTimeout
 
This example demonstrates the above equation using the default values in VMware ESX 3.5:
Y is the length of time it takes to mark a volume as not available.
Y = RoundUp( NFS.HeartbeatDelta, NFS.HeartbeatFrequency ) + (NFS.HeartbeatFrequency * (NFS.HeartbeatMaxFailures - 1)) + NFS.HeartbeatTimeout
Y = RoundUp( 5, 9 ) + ( 9 * ( 3 - 1 ) ) + 5 
Y = 5 + ( 9 * ( 3 - 1 ) ) + 5 
Y = 28 seconds

When a volume is back up, it can take NFS.HeartbeatFrequency seconds before ESX marks the volume as available.
 
Note: For more information about the roundup operation, see http://office.microsoft.com/en-us/excel/HP052092421033.aspx.  Note, the order in which the twp values may be reversed depending on the implementation of the RoundUp operation.
 
TCP/IP Heap Size
 
The tcpip stack in pre-ESX 4.0 versions of ESX does not handle mbuf allocation failures gracefully (purple diagnostic screens). Because of this, it is very important that the tcpip heap size is adjusted to accommodate usage by NFS. Unfortunately there are many consumers of the tcpip stack and it is difficult to get precise calculations for how big the tcpip needs to be. The safest way to calculate the tcpip heap size given the number of NFS volumes configured is to linearly scale the default values. For example the default number of NFS volumes is 8 and the default min/max sizes of the tcpip heap are respectively 6MB/30MB. This means the tcpip heap size for a host configured with 32 NFS volumes should have the min/max tcpip heap sizes set to 24MB/120MB.

Tags

NFS-advanced-options

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)
Actions
  • Bookmark Document
  • Email Document
  • Print Document
  • Subscribe to Document
  • Bookmark and Share