Known Issues and Restrictions

File system labels should not be used in large configurations

The use of file system labels can cause performance problems during boot-up with large clusters.  The problems are generally the result of the requirement that to use labels all devices connected to a system must be scanned.  For systems connected to a SAN, especially those with LifeKeeper where accessing a device is blocked, this scanning can be very slow. 

To avoid this performance problem on Red Hat systems, edit /etc/fstab and replace the labels with the path names. 

lkscsid will halt system when it should issue a sendevent

When lkscsid detects a disk failure, it should, by default, issue a sendevent to LifeKeeper to recover from the failure.  The sendevent will first try to recover the failure locally and if that fails, will try to recover the failure by switching the hierarchy with the disk to another server. On some versions of Linux (RHEL 5 and SLES11), lkscsid will not be able to issue the sendevent but instead will immediately halt the system. This only affects hierarchies using the SCSI device nodes such as /dev/sda.

DataKeeper Create Resource fails

When using DataKeeper in certain environments (e.g., virtualized environments with IDE disk emulation, or servers with HP CCISS storage), an error may occur when a mirror is created:

ERROR 104052: Cannot get the hardware ID of the device "dev/hda3"

This is because LifeKeeper does not recognize the disk in question and cannot get a unique ID to associate with the device.  

Workaround:  Add a pattern for our disk(s) to the DEVNAME device_pattern file, e.g.:

# cat /opt/LifeKeeper/subsys/scsi/resources/DEVNAME/device_pattern

/dev/hda*

Specifying hostnames for API access 

The key name used to store LifeKeeper server credentials must match exactly the hostname of the other LifeKeeper server (as displayed by the hostname command on that server). If the hostname is an FQDN, then the credential key must also be the FQDN. If the hostname is a short name, then the key must also be the short name.

Workaround: Make sure that the hostname(s) stored by credstore match the hostname exactly.

See section on Logging With syslog for further information.

Restore of an lkbackup after a resource has been created may leave broken equivalencies

The configuration files for created resources are saved during an lkbackup. If a resource is created for the first time after an lkbackup has been taken, that resource may not be properly accounted for when restoring from this previous backup.

Solution: Restore from lkbackup prior to adding a new resource for the first time. If a new resource has been added after an lkbackup, it should either be deleted prior to performing the restore, or delete an instance of the resource hierarchy, then re-extend the hierarchy after the restore. Note: It is recommended that an lkbackup be run when a resource of a particular type is created for the first time.

Resources removed in the wrong order during failover

In cases where a hierarchy shares a common resource instance with another root hierarchy, resources are sometimes removed in the wrong order during a cascading failover or resource failover.

Solution: Creating a common root will ensure that resource removals in the hierarchy occur from the top down.

1. Create a gen/app that always succeeds on restore and remove.

2. Make all current roots children of this new gen/app.

Note: Using /bin/true for the restore and remove script would accomplish this.

LifeKeeper syslog EMERG severity messages do not display to a SLES11 host's console which has AppArmor enabled

LifeKeeper is accessing /var/run/utmp which is disallowed by the SLES11 AppArmor syslog-ng configuration.

Solution: To allow LifeKeeper syslog EMERG severity messages to appear on a SLES11 console with AppArmor enabled, add the following entry to /etc/apparmor.d/sbin.syslog-ng:

/var/run/utmp kr

If added to sbin.syslog-ng, you can replace the existing AppArmor definition (without rebooting) and update with:

apparmor_parser -r /etc/apparmor.d/sbin.syslog-ng

Verify that the AppArmor update was successful by sending an EMERG syslog entry via:

logger -p local6.emerg "This is a syslog/lk/apparmor test."

RHEL 6.0 is NOT Recommended

SIOS strongly discourages the use of RHEL 6.0. If RHEL 6.0 is used, please understand that an OS update may be required to fix certain issues including, but not limited to:

• DMMP fails to recover from cable pull with EMC CLARiiON (fixed in RHEL 6.1)
• md recovery process hangs (fixed in the first update kernel of RHEL 6.1)

Note: In DataKeeper configurations, if the operating system is updated, a reinstall/upgrade of SIOS Protection Suite for Linux is required.

Delete of nested file system hierarchy generates "Object does not exist" message

Solution: This message can be disregarded as it does not create any issues.

filesyshier returns the wrong tag on a nested mount create

When a database has nested file system resources, the file system kit will create the file system for both the parent and the nested child. However, filesyshier returns only the child tag. This causes the application to create a dependency on the child but not the parent.

Solution: When multiple file systems are nested within a single mount point, it may be necessary to manually create the additional dependencies to the parent application tag using dep_create or via the UI Create Dependency.

DataKeeper: Nested file system create will fail with DataKeeper

When creating a DataKeeper mirror for replicating an existing File System, if a file system is nested within this structure, you must unmount it first before creating the File System resource.

Workaround: Manually unmount the nested file systems and remount / create each nested mount.

lkstart on SLES 11 SP2 generates insserv message

When lkstart is run on SLES 11 SP2, the following insserv message is generated:

insserv: Service syslog is missed in the runlevel 4 to use service steeleye-runit

LifeKeeper and steeleye-runit scripts are configured by default to start in run level 4 where dependent init script syslog is not. If system run level is changed to 4, syslog will be terminated and LifeKeeper will be unable to log.

Solution: Make sure system run level is NOT changed to run level 4.

Changing the mount point of the device protected by Filesystem resource may lead data corruption

The mount point of the device protected by LifeKeeper via the File System resource (filesys) must not be changed. Doing so may lead to the device being mounted on multiple nodes and if a switchover is done and this could lead to data corruption.

XFS file system usage may cause quickCheck to fail.

In the case CHECK_FS_QUOTAS setting is enabled for LifeKeeper installed on Red Hat Enterprise Linux 7 / Oracle Linux 7 / CentOS 7, quickCheck fails if uquota, gquota option is set to the XFS file system resource, which is to be protected. Solution: Use usrquota, grpquota instead of uquota, gquota for mount options of XFS file system, or, disable CHECK_FS_QUOTAS setting.

Btrfs is not supported

Btrfs cannot be used for LifeKeeper files (/opt/LifeKeeper), bitmap files if they are not in /opt/LifeKeeper, lkbackupfiles, or any other LifeKeeper related files. In addition, LifeKeeper does not support protecting Btrfs within a resource hierarchy.

SLES12 SP1 or later on AWS

The following restrictions apply with SLES12 SP1 or later on AWS:

• Cannot set static routing configuration
  Automatic IP address configuration via DHCP does not work if a static routing configuration is set in /etc/sysconfig/network/routes. This causes the network not to start correctly.
  Solution: Update the routing information in the configuration file by modifying the "ROUTE" parameter in /etc/sysconfig/network/ifroute-ethX
• Hostname is changed even if the "Change Hostname via DHCP" setting is disabled.
  The LK service does not work properly if the hostname is rewritten. In SLES12 SP1 or later on AWS, the hostname is changed even after the "Change Hostname via DHCP" setting is disabled.
  Solution:
  • Update /etc/cloud/cloud.cfg to comment out the "update_hostname" parameter
  • Update /etc/cloud/cloud.cfg to set the preserve_hostname parameter to "true"
  • Update /etc/sysconfig/network/dhcp to set the DHCLIENT_SET_HOSTNAME parameter to "no"

Shutdown Strategy set to "Switchover Resources" may fail when using Quorum/Witness Kit in Witness mode

Hierarchy switchover during LifeKeeper shutdown may fail to occur when using the Quorum/Witness Kit in Witness mode.
Workaround: Manually switchover resource hierarchies before shutdown.

Edit /etc/service

If the following entry in /etc/service is deleted, LifeKeeper cannot start up.

lcm_server 7365/tcp

Any storage unit which returns a string including a space for the SCSI ID cannot be protected by LifeKeeper.

SIOS has migrated to the use of the ip command and away from the ifconfig command. Because of this change, customers with external scripts are advised to make a similar change. Instead of issuing the ifconfig command and parsing the output looking for a specific interface, scripts should instead use "ip -o addr show" and parse the output looking for lines that contain the words "inet" and "secondary".

# ip -o addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     \    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1: lo    inet 127.0.0.1/8 scope host lo
1: lo    inet6 ::1/128 scope host
     \       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
     \    link/ether d2:05:de:4f:a2:e6 brd ff:ff:ff:ff:ff:ff
2: eth0    inet 172.17.100.77/22 brd 172.17.103.255 scope global eth0
2: eth0    inet 172.17.100.79/22 scope global secondary eth0
2: eth0    inet 172.17.100.80/22 scope global secondary eth0
2: eth0    inet6 2001:5c0:110e:3364::1:2/64 scope global
     \       valid_lft forever preferred_lft forever
2: eth0    inet6 2001:5c0:110e:3300:d005:deff:fe4f:a2e6/64 scope global dynamic
     \       valid_lft 86393sec preferred_lft 14393sec
2: eth0    inet6 fe80::d005:deff:fe4f:a2e6/64 scope link
     \       valid_lft forever preferred_lft forever

So for the above output from the ip command, the following lines contain virtual IP addresses for the eth0 interface:

2: eth0    inet 172.17.100.79/22 scope global secondary eth0
2: eth0    inet 172.17.100.80/22 scope global secondary eth0

'IPV6_AUTOCONF = No' for /etc/sysconfig/network-scripts/ifcfg-<nicName> is not being honored on reboot or boot

On boot, a stateless, auto-configured IPv6 address is assigned to the network interface. If a comm path is created with a stateless IPv6 address of an interface that has IPV6_AUTOCONF=No set, the address will be removed if any system resources manage the interface, e.g. ifdown <nicName>;ifup <nicName>.

Comm path using auto-configured IPv6 addresses did not recover and remained dead after rebooting primary server because IPV6_AUTOCONF was set to No.

Solution: Use Static IPv6 addresses only. The use of auto-configured IPv6 addresses could cause a comm loss after a reboot, change NIC, etc.

While IPv6 auto-configured addresses may be used for comm path creation, it is incumbent upon the system administrator to be aware of the following conditions:

• IPv6 auto-configured/stateless addresses are dependent on the network interface (NIC) MAC address. If a comm path was created and the associated NIC is later replaced, the auto-configured IPv6 address will be different and LifeKeeper will correctly show the comm path is dead. The comm path will need to be recreated.

• At least with RHEL 5.6, implementing the intended behavior for assuring consistent IPv6 auto-configuration during all phases of host operation requires specific domain knowledge for accurately and precisely setting the individual interface config files AS WELL AS the sysctl.conf, net.ipv6.* directives (i.e. explicity setting IPV6_AUTOCONF in the ifcfg-<nic> which is referenced by the 'if/ip' utilities AND setting directives in /etc/sysctl.conf which impact NIC control when the system is booting and switching init levels). 

IP: Modify Source Address Setting for IPv6 doesn't set source address

When attempting to set the source address for an IPv6 IP resource, it will report success when nothing was changed.

Workaround: Currently no workaround is available. This will be addressed in a future release.

IP: Invalid IPv6 addressing allowed in IP resource creation

Entering IPv6 addresses of the format 2001:5c0:110e:3368:000000:000000001:61:14 is accepted when the octets contain more than four characters.

Workaround: Enter correctly formatted IPv6 addresses.

Can't connect to host via IPv6 addressing

lkGUIapp will fail connecting to a host via IPv6 hex addressing, either via resolvable host name or IP address. lkGUIapp requires an IPv4 configured node for connection. IPv6 comm paths are fully supported.

The "include" directive is not supported

The "include" directive is not supported. All the setup configuration information must be described in a single my.cnf file.

User Name/Password Issues:

• If the default user name is password-protected, the create UI does not detect this until after all validation is complete

When creating the Sybase resource, you are prompted to enter the user name. The help to front displays a message that if no user is specified, the default of 'sa' will be used. However, no password validation is done for the default account at this time. When SIOS Protection Suite attempts to create the Sybase resource, the resource creation fails because the password has not been validated or entered. The password validation occurs on the user/password dialog, but only when a valid user is actually entered on the user prompt. Even if using the default user name, it must be specified during the create action.

• Password prompt skipped if no user name specified

User/password dialog skips the password prompt if you do not enter a user name. When updating the user/password via the UI option, if you do not enter the Sybase user name, the default of ‘sa’ will be used and no password validation is done for the account. This causes the monitoring of the database to fail with invalid credential errors. Even if using the default user name, it must be specified during the update action. To fix this failure, perform the following steps:

1. Verify that the required Sybase data files are currently accessible from the intended server. In most instances, this will be the backup server due to the monitoring and local recovery failure on the primary.
2. Start the Sybase database instance from the command line on this server (see the Sybase product documentation for information on starting the database manually).
3. From the command line, change directory (cd) to the LKROOT/bin directory (/opt/LifeKeeper/bin on most installations).
4. Once in the bin directory, execute the following:

./ins_setstate –t <SYBASE_TAG> -S ISP

where <SYBASE_TAG> is the tag name of the Sybase resource

5. When the command completes, immediately execute the Update User/Password Wizard from the UI and enter a valid user name, even if planning to use the Sybase default of ‘sa’. Note: The Update User/Password Wizard can be accessed by right-clicking on the Sybase resource instance and selecting Change Username/Password.
6. When the hierarchy has been updated on the local server, verify that the resource can be brought in service on all nodes.

• Protecting backup server fails when Sybase local user name >= eight characters

The Sybase user name must consist of less than eight characters. If the Sybase local user name is greater than eight characters, the process and user identification checks used for resource creation and monitoring will fail. This will also prevent the protection of a valid Sybase Backup Server instance from being selected for protection. This problem is caused by the operating system translation of user names that are >= eight characters from the name to the UID in various commands (for example, ps). You must use a user name that is less than eight characters long.

Resource Create Issue:

• Default Sybase install prompt is based on ASE 16.0 SP02 (/opt/sybase). During the SIOS Protection Suite resource creation, the default prompt for the location of the Sybase installation shows up relative to Sybase Version 16.0 SP02 (/opt/sybase). You must manually enter or browse to the correct Sybase install location during the resource create prompt.

Extend Issues:

• The Sybase tag prompt on extend is editable but should not be changed. The Sybase tag can be changed during extend, but this is not recommended. Using different tags on each server can lead to issues with remote administration via the command line.

Properties Page Issues:

• Image appears missing for the Properties pane update user/password. Instead of the proper image, a small square appears on the toolbar. Selecting this square will launch the User/Password Update Wizard.

Sybase Monitor server is not supported in 15.7 or later with SIOS Protection Suite. If the Sybase Monitor server process is configured in Sybase 15.7 or later, you must use a Generic Application (gen/app) resource to protect this server process.

Remove command not recognized by Sybase on SLES 11

If bringing Sybase in service on the backup server, it must first be taken out of service on the primary server. In order for Sybase to recognize this command, you must add a line in "locales/locales.dat" for the SIOS Protection Suite remotely executed Sybase command using "POSIX" as "vendor_locale".

Example:

locale = POSIX, us_english, utf8

Error when lksupport command is executed:

The following error can be output when lksupport command is executed in the case MQ queue manager protected by MQ RK is set on the disk shared by NFS.

cat: <PATH>/mqm/qmgrs/tkqmgr/qm.ini: Operation not permitted

This happens because the root access to NFS area is prohibited. This error output doesn't cause any problem.

Quickcheck fails if queue has long messages if a message is in the test queue of size > 101 characters the put/get fails and the queue fills up

Install fails if the only installed MQ is a relocated install (non-standard and not likely)

Package install fails if the MQ package does not have the default name

Compile samples fails if the software is not installed under /opt/mqm