Known Problems and Workarounds

File locks are not maintained when an NFS server package moves to an adoptive server. Any applications that use file locking must reclaim their locks after an NFS server package fails over. An application that loses its file lock as a result of an NFS package failover will not be notified. If the server is also an NFS client, any file locks it holds will be lost.

An NFS/TCP client operation receives "NFS server not responding still trying" message while attempting to access the server although the server is up. In this situation, users can increase the default kernel parameter max_thread_proc by using SAM on HA servers.

Performance degradation may occur if manual switching between primary server and adoptive server is done immediately after a failover recovery. After manually moving the NFS package between the primary server and adoptive server, wait at least 10 minutes after the recovery while TCP connections clean, otherwise the client applications hang or take a long time to finish.

NFS package exported file systems on HA servers are not exported if you restart NFS clients or NFS servers. Manually switch the NFS package to a different HA server before stopping and restarting NFS clients and servers with nfs.client stop/start or nfs.server stop/start.

HP recommends not enabling AutoFS on the HA server. Enabling AutoFS on the HA server creates a conflict between AutoFS's design and the HA solution. Halting NFS packages may fail if actions to stop and restart NFS clients and servers are taken before halting NFS packages. This failure can also occur when restarting the AutoFS daemon on the HA server. If you must enable AutoFS on the HA server, manually switch the NFS package to a different HA server before restarting the AutoFS daemon or before performing any stopping or restarting actions on NFS clients and servers.