Description
Top level NFS resource hierarchy uses the switchback type of the hanfs resource

The switchback type, which dictates whether the NFS resource hierarchy will automatically switch back to the primary server when it comes back into service after a failure, is defined by the hanfs resource.
IPv6 cannot be configured

IP v6 address cannot be used.


Solution: Do not use an IPv6 virtual IP resource when creating a resource.
NFS v4: Unable to re-extend hierarchy after unextend

Extend fails because export point is already exported on the target server. A re-extend to server A of a resource hierarchy will fail if a resource hierarchy is created on server A and extended to server B, brought in service on server B and then un-extended from server A.


Solution: On server A run the command “exportfs -ra“ to clean up the extra export information left behind.
File Lock switchover fails

Switchover file locks during resources switchover/failover does not work. The result is the same when mounting with both NFS v3 or v4. Do not use file lock from client applications.
Unable to be used for Oracle Recovery Kit shared storage

Unable to be used for Oracle shared database storage because an export point which is protected by LifeKeeper can not use file lock.
Resource creation process will hang when gssproxy is not running

If the gssproxy daemon is not running, LifeKeeper starts it when a resource is created. However, the resource creation process is not completed since the gssproxy does not work as LifeKeeper expected. This issue can occur in both lkGUIapp and lkcli. If the gssproxy is not installed and rpc.svcgssd is installed, this issue does not occur because the rpc.svcgssd is used.

Solution: Start gssproxy daemon. Enable the auto-start to keep it running all the time.The following are examples of RHEL 7.

systemctl start gssproxy.service
systemctl enable gssproxy.service
If rpc.idmapd and rpc.svcgssd are not running in the LifeKeeper Single Server Protection environment, the restore function will fail

In LifeKeeper Single Server Protection, the directory to mount rpc_pipefs is not created. Mounting rpc_pipefs is tried before starting rpc. idmapd and rpc.svcgssd daemons, but it fails because the directory is missing.

Soulution: Start rpc.idmapd and rpc.svcgssd daemons. Enable the auto-start to keep it running all the time.The following are examples of SLES15. If the gssproxy is installed, it is not necessary to have the rpc.svcgssd daemon running.

systemctl start nfs-idmapd.service
systemctl enable nfs-idmapd.service
systemctl start rpc-svcgssd.service
systemctl enable rpc-svcgssd.service

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment