Effective migration of VM Host systems depends
on proper configuration of the networks and storage used by the source
and destination hosts. The hpvmmigrate command
verifies that the source and destination hosts provide the guest with
symmetric accessibility to network and storage resources. If you set
up the configuration properly on both hosts before you migrate the
guest, the migration task is much easier and faster.
Network Configuration Considerations |
 |
The source and destination hosts should be on
the same subnet. The hpvmmigrate command preserves
the MAC address of the guest being migrated. Thus, having the hosts
on the same subnet prevents problems that can occur from changing
the guest’s host name or IP address. With both hosts on the
same subnet, the guest boots properly on the destination host.
In addition, ensure that all pNICs are symmetrically
configured on both the source and destination hosts. For example,
if lan0 on HostA is connected to
subnet A, and lan1 is connected to
subnet B, make sure that, on HostB, lan0 is connected to subnet A and lan1 is connected to subnet B.
Storage Configuration Considerations |
 |
Both the source and destination hosts must share
access to symmetrically configured storage devices. The same storage
devices must be visible to both the source host and destination hosts.
The hpvmmigrate command uses the Fibre Channel
worldwide identifier (WWID) to determine whether the storage allocated
to a guest on the soure host is also reachable on the destination
host. The new hpvmmigrate -t device
translation option performs automatic mapping of device names when
used with the -m option.
The hpvmmigrate command assumes
that guests use storage area network (SAN) resources specified as
whole-disk backing stores (for example, /dev/rdisk/disk2). File backing stores can also be used, but whole-disk LUN backing
stores achieve significantly better run-time performance. Also, you
can create virtual machines with direct attached storage (DAS), but
guests that use DAS cannot be migrated.
To prevent migrating guests that are using the
same resources at the same time on multiple VM Hosts, guests are disabled
on the source VM Host when they are migrated to a destination VM Host.
To avoid other accidental misuse of disk devices, mark as restricted
all the disk devices that are used for guest storage on all hosts,
except the disk that contains the guest. To mark a disk as restricted,
use the hpvmdevmgmt command. For example:
# hpvmdevmgmt –a rdev:entry_name |
The –a option accepts
the name of the device to be restricted. For example:
# hpvmdevmgmt –a rdev:/dev/rdisk/disk0 |
For more information about the hpvmdevmgmt command, see Chapter 7.
Security Considerations |
 |
The hpvmmigrate command requires
HP-UX Secure Shell (SSH) to be set up on both the source and destination
host systems. SSH provides a secure communication path between hosts
and is installed on HP-UX 11.23 systems by default. To enable secure
communication between the source and destination hosts, you must generate
SSH keys on both systems.
The hpvmmigrate command uses
SSH public-key based authentication between the source and destination
hosts. Password-based and host-based authentication are not supported.
You need root privileges to generate and set up
the SSH keys required for guest migration.
To set up the SSH keys on the source and destination
hosts, HP recommends that you use the HP-UX Distributed Systems Administration
Utilities (DSAU) tools which are installed by default on HP-UX 11.23
(0512 release). The bundle name is DSAUtilities.
To set up SSH keys between hosts, use the /opt/dsau/bin/csshsetup command. The csshsetup command simplifies the task of setting up SSH public-key authentication
trust relationships between hosts. The –r (round-robin) option sets up bidirectional authentication. Round-robin
key exchange establishes “any-member-to-any-member” authentication.
For more information, see csshsetup.
Alternatively, SSH keys can be generated manually
on the individual systems and then copied to the remote system's $HOME/.ssh/authorized_keys2 file by using the ssh_keygen command. The ssh_keygen command
generates, manages, and converts authentication keys for SSH. It
also creates RSA keys for use by the SSH protocol.
To use SSH with RSA or DSA authentication, the ssh_keygen command creates the authentication key in one
of the following files:
The system administrator may also use the ssh_keygen command to generate host keys, as seen in /etc/rc. For more information about SSH key generation,
see ssh-keygen.
Table 10-2 lists the files that are modified or created
for RSA key generation.
Table 10-2 RSA Key Files
File Name | File
Contents |
---|
$HOME/.ssh2/id_rsa | Default
RSA private key for the user |
$HOME/.ssh2/id_rsa.pub | Default RSA public key for the user |
$HOME/.ssh/authorized_keys | Names of the host RSA public keys that can authenticate to this account |
Troubleshooting SSH Key Setup
If the SSH is installed on both the source and
the destination system, you can run the ssh command
on the source host to establish a connection to the destination host.
This action ensures that SSH keys are set up between the two hosts.
The following error message can result from having SSH keys set up
improperly:
Error: hpvmmigrate: SSH execution error.
Error: hpvmmigrate: Remote execution error on destination-host. |