Known Issues and Workarounds

Bug 2257

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.

Bug 2408

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

Cause:

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.

Workaround:

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”.

Bug 2387

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.

gdisk /dev/sdb

Make a file system.

mkfs -t ext3 /dev/sdb1

Mount this file system (example using /mnt/oracle).

mkdir /mnt/oracle

mount /dev/sdb1 /mnt/oracle

Stop Oracle, Listener.

Copy Oracle to new file system.

cd /oracle

cp -a * /mnt/oracle

(Note: This step may take some time based on the amount of data)

Unmount the new file system.

umount /mnt/oracle

Mount the new file system over /oracle.

mount /dev/sdb1 /oracle

Start Listener and then Oracle.

Bug 2388

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:

• $LKROOT/lkadm/subsys/appsuite/sap/bin/create <primary sys> <tag> <SAP SID> <SAP Instance> <switchback type> <IP Tag> <Protection Level> <Recovery Level> <Additional SAP Dependents> 76

See Setting Up SAP from the Command Line for further command line information.