Included below are the restrictions and/or known issues open against LifeKeeper Single Server Protection.
Access to LifeKeeper Single Server Protection and LifeKeeper for Linux nodes via
credstore requires proper credstore key
Solution: When storing credentials for a LifeKeeper Single Server Protection or LifeKeeper for Linux node using credstore, you must use the proper form of the hostname for the credstore credentials key (i.e. credstore -k ):
For the LifeKeeper Single Server Protection plugin, credstore should be run using the hostname of the system as reported in the Hostname: field of the LifeKeeper Single Server Protection plugin display.
For LifeKeeper Single Server Protection, the hostname used to store credentials must be the same as the one you plan to use in the command line tool’s (e.g., lkpolicy) -d argument. For example, if you want to run lkpolicy -d mynode1, then you must store credentials using credstore -k mynode1. You cannot store credentials using the FQDN in this case. If you do, you must run lkpolicy -d FQDN.
Workaround: If you’ve stored a default credential set (i.e., credstore -k default) that works for all your LifeKeeper Single Server Protection and/or LifeKeeper for Linux nodes, then you will not be affected by this issue.
HA hearbeat incorrectly enabled
lkvmhad incorrectly enables the HA hearbeat after second resource failure
Workaround: Set LKCHECKINTERVAL in /etc/default/LifeKeeper greater than the VMware HA, VM Monitoring Failure Interval. Note: The LKCHECKINTERVAL default is 120 seconds. This is also the default ‘low’ monitoring sensitivity for VMware HA, VM Monitoring.
Taking a resource out of service and later stopping and restarting LifeKeeper will result in that resource being brought back in service
During LifeKeeper Single Server Protection startup, a resource that has been taken out of service prior to stopping LifeKeeper will result in that resource being brought back in service.
Refresh problem with LifeKeeper Single Server Protection GUI
The GUI may occasionally scramble the resource tree (i.e., resource dependencies may not be shown correctly).
Workaround: Perform a refresh of the GUI.
Apache resource creation fails
Example of Error message:
Error: valid_http_root: Since “/usr/sbin/httpd” is shareable on “/usr”, “/etc/httpd” must be also
Due to a defect, files in mount point “/”(root) cannot be detected appropriately.
For example, if “/etc/httpd” is in a same filesystem as the mount point “/”, a resource creation will fail.
Mount one of the below workarounds to avoid this issue.
(a) Transfer such as “/etc/httpd” under the other mount point.
(b) Mount “ /etc” to such as” /dev/sdb1”.
Cannot create an Oracle hierarchy on root file system in LifeKeeper Single Server Protection environment
Workaround: Using the following procedure, copy Oracle to a new file system.
Create a new disk large enough for Oracle data (e.g. /dev/sdb). (Note: You can size up /oracle directory to get an idea how big this should be; multiply by at least 50% to allow for logs)
Using gdisk, create a new partition on that disk.
Make a file system.
mkfs -t ext3 /dev/sdb1
Mount this file system (example using /mnt/oracle).
mount /dev/sdb1 /mnt/oracle
Stop Oracle, Listener.
Copy Oracle to new file system.
cp -a * /mnt/oracle
(Note: This step may take some time based on the amount of data)
Unmount the new file system.
Mount the new file system over /oracle.
mount /dev/sdb1 /oracle
Start Listener and then Oracle.
For SAP, hierarchies cannot be created using the GUI
Workaround: Use the command line option to create hierarchies. However, at the end of the command line, specify the number 76 as follows:
See Setting Up SAP from the Command Line for further command line information.
Also, refer to Known Issues and Restrictions.