After alternate disk install cloning, improper hostname resolution may cause HMC RSCT errors

Abstract

A properly defined system hostname is critical for RSCT function. This TIP reminds you that cloning can cause hostname resolution problems.

Contents


Dynamic LPAR relies on Service Focal Point and RSCT. This means that TCP/IP, including the hostname on the HMC, must be configured. The /etc/hosts files in the HMC and all LPARs must have entries for all entities with the hostname appearing first in any list of aliases.

A problem with DLPAR can exist after using the altinst_rootvg cloning procedure to create the second LPAR. The file /etc/ct_node_id had the same contents on both LPARs so RSCT may detect only one LPAR to manage. Development is aware of this and is working on a circumvention and correction. In the meantime, a workaround is to run the following two commands after the first boot of the new LPAR:
/usr/sbin/rsct/install/bin/uncfgct -n
/usr/sbin/rsct/install/bin/cfgct

A subsequent reboot will cause the partitions to be synchronized from an RSCT perspective. The duplicate /etc/ct_node_id condition are likely to cause negative behaviors in a HACMP scenario between cloned LPARs. Cloning an LPAR with a mksysb tape/DVD will likely cause the same problem. NIM installs avoid this problem as a unique /etc/ct_node_id file is created.

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment. publib-b.boulder.ibm.com

Profile

Publish Date
12 February 2004


Rating: Not yet rated


Author(s)

IBM Form Number
TIPS0373