Frequently asked questions about Db2 pureScale Feature host validation problems

The following sections provide possible solutions to problems you might encounter when attempting to validate remote hosts.

What if the user id specified is invalid?

The Db2 installer validates the existing user id specified. If the user id specified is invalid, ensure the user id exists on the installation-initiating host (IIH) and on each of the remote hosts. Ensure the user id has the exact same uid, gid, group name, and directory path. To create a user id, see the "Required users for a Db2 pureScale Feature installation" topic.

What if the ports specified are invalid?

Before instance creation, the Db2 installer validates the ports you specified. If the ports you specified are not available, review the TCP/IP ports that are already in use the IIH and on the remote hosts by opening the /etc/services file. After you have determined a range of free ports, enter the new ports into the applicable ports fields in the Advanced Settings Panel of the Add Host Panel and have them validated by the Db2 installer.

What if a host already belongs to another GPFS cluster?

A host cannot be a member of two GPFS clusters. If the IIH is not part of a GPFS cluster, then the remote host should not belong to a GPFS cluster. If the IIH is part of a GPFS cluster, then the remote host should either not belong to a GPFS cluster or belong to the same GPFS cluster. After you have resolved this, try adding the host to the host list again.

What if the global registry variable record on the host indicates a GPFS Cluster already exists?

In some cases, the clean up of the global registry might not have been complete, leaving behind a record (GPFS_CLUSTER) that indicates there is a GPFS cluster in use by Db2 on the host when in fact there is not one. Contact IBM Software Support.

What if the IIH cannot connect with the target host?

This error can occur as the Db2 installer tries to verifying ssh communication from the IIH to the target host. Ensure that the settings for ssh and scp are correctly setup. ssh and scp need to be setup without a password prompt between the hosts for the root user. For more information, see the "Installing and setting up OpenSSH on AIX®" topic.

If the problem occurs outside the Db2 installer, you can check a variety of items to determine the source of the problem. For example, this communication failure could result from a bad physical connection, a defective or unresponsive network adapter driver, or a misconfigured network.

What if the attempt to communicate with a target host times out?

If an attempt to validate a host did not finish within the time out period, it will time out. Check the connections to the host and try to add it again. You can also change the time out variable and re-run the installation command.

What if the Db2 installer detects an existing RSCT peer domain on a host?

During a Db2 installation, only one RSCT peer domain can be active at a time. The peer domain that was not created by the Db2 installer must be stopped or removed before creating a RSCT peer domain to be used by the IBM® Db2 pureScale Feature.

To stop the RSCT peer domain using the db2cluster command on the host db2host1, log on to a host that belongs to the same active RSCT peer domain, run the db2cluster -cm -stop -host db2host1 command. If the db2cluster command is not available, run the stoprpdomain <domain name> command. Run the lsrpdomain command to determine the domain name to specify.

If an attempt to validate host did not finish within the time out period, it will time out. Check the connections to the host and try to add it again. You can also change the time out variable and re-run the installation command.
To remove the RSCT peer domain:
  1. Remove the remote host from the host list.
  2. If the remote host "db2host1" belongs to a different Db2 pureScale instance, remove it from that Db2 pureScale instance using the "db2iupdt -drop" command.
To remove the host from a Db2 pureScale instance:
  1. Log on to a different host which belongs to the same Db2 pureScale instance
  2. Run 
    db2iupdt [-d] -add -m|cf <host_name>:<interconnect_name> -u <fenced_id> <instance_owner>
To remove a remote host that does not belong to a Db2 instance, run one of the following commands:
  • db2cluster -cm -remove -host <hostname>
  • rmrpnode <hostname>

What if there is a conflict between the DEFAULT_INSTPROF record and the instance shared directory specified?

The Db2 installer has detected a conflict between the DEFAULT_INSTPROF record and the instance shared directory specified. Do not specify the instance shared directory. The DEFAULT_INSTPROF record in the global registry indicates the instance shared file system has already been set up by Db2.
In this case, the following options or keywords are not needed.
  • For a response file installation: INSTANCE_SHARED_DEVICE_PATH and INSTANCE_SHARED_DIR.
  • For db2icrt or db2iupdt: instance_shared_dev and instance_shared_dir.
If the value for INSTANCE_SHARED_DIR / instance_shared_dir matches with the existing instance shared file system mount point, the Db2 installer will still allow to pass. However, if the value does not match, the installation will fail.

What if the PVID for the device path on the install-initiating host (IIH) does not exist on a target host?

Ensure that PVID is setup on the IIH and all the hosts. See the "Configuring PVIDs for a Db2 pureScale Feature instance" topic for more details.

What if the cluster interconnect netname specified is invalid?

This error occurs because the Db2 installer cannot identify the cluster interconnect netname. Try following methods to solve the problem:
  1. Check the command for a typo error.
  2. Check the machine's network configuration (for example check /etc/hosts).
  3. Use the ping and nslookup tools to confirm the cluster interconnect netname maps to the same IP address on all hosts. Check that IP address maps back to the same cluster interconnect netname on all hosts.

What if the cluster interconnect netname for a target host failed to ping the IIH?

When adding a new host, the Db2 installer checks to see if the new host can send a small data packet to the IIH and receive a reply. This send-reply test is commonly known as a ping - this message is the result of a failed ping. If there is a problem, you can verify the results by running this command line from the remote host's console: ping IIH address_or_name.

If this test fails, ensure that the ssh communication between the IIH and the remote hosts is set up correctly.

After it is verified that the problem occurs outside the Db2 installer, there are various things the you can check find the source of the problem, for example bad physical connections (for example, loose cable), a faulty network adapter driver, or an improperly setup network. Check the network adapter and cable, or choose a different one.

What if the cluster interconnect netname for a target host is not on the same subnet as the IIH?

You can reconfigure the network adapter or choose a different one. This error occurs when the cluster interconnect netname for a host is not on the same subnet as the installation-initiating host. All cluster interconnects for CF need to be on the same subnet for performance reasons (all hosts within the same subnet can usually be reached in one routing hop).

For example if the cluster interconnect network is configured with the network address 192.168.0.0/24, then all cluster interconnect netname addresses should start with 192.168.0 (for example, 192.168.0.1, 192.168.0.2, and so on).

Check the network card configuration on the new host (for example, run the ifconfig -a command) and check /etc/hosts if a name was used instead of an address.