In many smaller PowerVM environments there are exactly two HMCs. All managed systems are then connected to these two HMCs. In this case, it makes a lot of sense to use data replication to automatically replicate configuration and user data between the two HMCs. Configuration changes then do not have to be made manually on both HMCs. Since both HMCs usually have equal rights, a peer-to-peer configuration for data replication is recommended. Replication can take place in both directions.

As a concrete example, the peer-to-peer configuration of the two HMCs hmc01 and hmc02 is shown below.

First you should check whether data replication is already active:

$ hmc lsdatarep -l hmc01
IS_ENABLED  CURR_WARNING_DATA_TYPES  AVAIL_WARNING_DATA_TYPES
0           -                        pwdpolicy,user,kerberos,customer,outbound,ldap,mfa
$ hmc lsdatarep -l hmc02
IS_ENABLED  CURR_WARNING_DATA_TYPES  AVAIL_WARNING_DATA_TYPES
0           -                        pwdpolicy,user,kerberos,customer,outbound,ldap,mfa
$

This is not the case on the two HMCs (IS_ENABLED=0). Therefore, we enable data replication on both HMCs:

$ hmc enabledatarep hmc01
$ hmc enabledatarep hmc02
$

If both HMCs are already configured equally, then the order of the subsequent steps does not matter. However, if one of the two HMCs has already been extensively configured, then you would of course want to transfer this configuration to the second HMC. In our case, some users have already been created on the HMC hmc01:

$ hmc lshmcusr hmc01
NAME      DESCRIPTION           TASKROLE       RESOURCEROLE
root      root                  hmcsuperadmin  ALL:
hscroot   HMC Super User        hmcsuperadmin  ALL:
hscpe     HSCPE                 hmcpe          ALL:
ibm       new user from Wizard  hmcsuperadmin  ALL:
tsuser    Technischer User SLS  viewrole       ALL:
pctest    HMC User              tsrole         ALL:
nimadm    NIM                   hmcsuperadmin  ALL:
$

In addition to the standard users, the users ibm, tsuser, pctest and nimadm were created. These should be taken over using data replication to the second HMC.

The configuration of data replication is done on the slave HMC by configuring a data source (master) for one or more data types. No explicit configuration takes place on the data source (master), besides enabling data replication.

In order to keep the existing users, the HMC hmc01 must first be configured as a source on the HMC hmc02. For each source, it must/can be specified which data types should be replicated from this source (master). For our example, we replicate password policies (pwdpolicy), user accounts (user) and customer information (customer) from hmc01:

$ hmc adddatarep hmc02 hmc01 data_types=pwdpolicy,user,customer
$

The status of the replication can then be displayed using “hmc lsdatarep”:

$ hmc lsdatarep hmc02
DATA_TYPE  LEVEL  UPDATED_SINCE_START  UPDATED_TIME         SOURCE_HMC_NAME  NOT_IN_SYNC_SLAVES
pwdpolicy  0      1                    05/27/2023 10:05:23  hmc01            -
user       0      1                    05/27/2023 10:05:23  hmc01            -
kerberos   0      0                    -                    -                -
customer   0      1                    05/27/2023 10:05:35  hmc01            -
outbound   0      0                    -                    -                -
ldap       0      0                    -                    -                -
mfa        0      0                    -                    -                -
[ize0h29@login11 src]$

Replication is usually instantaneous, but can sometimes take a minute or two.

The UPDATED_SINCE_START column indicates with the value 1 that the data has been replicated. The UPDATED_TIME column shows the time of the last replication and the SOURCE_HMC_NAME column indicates which source (master) the data comes from. In the above case, the data was replicated from hmc01.

So far, replication only takes place in one direction: from hmc01 to hmc02. When data is changed on hmc02, this change is replicated to hmc01. For replication in the other direction, the second HMC (hmc02) must be configured on hmc01 as a source for the same data types:

$ hmc adddatarep hmc01 hmc02 data_types=pwdpolicy,user,customer
$

Now both HMCs have equal rights; changes on one of the two HMCs are automatically replicated to the other HMC.

The configured sources (master) on the two HMCs can be displayed using the “-m” (master) option of “hmc lsdatarep”:

$ hmc lsdatarep -m hmc01
HMC_NAME  IS_COMMUNICATING  CURR_DATA_TYPES          AVAIL_DATA_TYPES
hmc02     1                 pwdpolicy,user,customer  pwdpolicy,user,kerberos,customer,outbound,ldap,mfa
$ hmc lsdatarep -m hmc02
HMC_NAME  IS_COMMUNICATING  CURR_DATA_TYPES          AVAIL_DATA_TYPES
hmc01     1                 pwdpolicy,user,customer  pwdpolicy,user,kerberos,customer,outbound,ldap,mfa
$

The data types to be replicated can be changed at any time. For example, if customer information is no longer to be replicated, it can be removed from the list of data types to be replicated:

$ hmc chdatarep hmc01 hmc02 data_types-=customer
$ hmc chdatarep hmc02 hmc01 data_types-=customer
$

(Similarly, data types can also be added with “+=”..)