Veritas InfoScale™ 7.4.1 Virtualization Guide - AIX
- Section I. Overview
- Storage Foundation and High Availability Solutions in AIX PowerVM virtual environments
- Section II. Implementation
- Setting up Storage Foundation and High Availability Solutions in AIX PowerVM virtual environments
- Supported configurations for Virtual I/O servers (VIOS) on AIX
- Installing and configuring Storage Foundation and High Availability (SFHA) Solutions in the logical partition (LPAR)
- Installing and configuring Cluster Server for logical partition and application availability
- Supported configurations for Virtual I/O servers (VIOS) on AIX
- Setting up Storage Foundation and High Availability Solutions in AIX PowerVM virtual environments
- Section III. Use cases for AIX PowerVM virtual environments
- Application to spindle visibility
- Simplified storage management in VIOS
- Configuring Dynamic Multi-Pathing (DMP) on Virtual I/O server
- Configuring Dynamic Multi-Pathing (DMP) pseudo devices as virtual SCSI devices
- Extended attributes in VIO client for a virtual SCSI disk
- Virtual machine (logical partition) availability
- Simplified management and high availability for IBM Workload Partitions
- Implementing Storage Foundation support for WPARs
- How Cluster Server (VCS) works with Workload Patitions (WPARs)
- Configuring VCS in WPARs
- High availability and live migration
- Limitations and unsupported LPAR features
- Multi-tier business service support
- Server consolidation
- About IBM Virtual Ethernet
- Using Storage Foundation in the logical partition (LPAR) with virtual SCSI devices
- How DMP handles I/O for vSCSI devices
- Physical to virtual migration (P2V)
- Section IV. Reference
Providing high availability with live migration in a Cluster Server environment
You can use Live Partition Mobility to perform a stateful migration of a logical partition (LPAR) in a Cluster Server (VCS) environment. VCS supports LPAR live migration in two ways:
LPAR migration outside of VCS control
LPAR migration through VCS commands
VCS initiated LPAR migration
- To migrate a managed LPAR:
# hagrp -migrate <lpar_service_group> \ -to <target_vcs_node>
Requirements for high availability support for live migration through VCS commands:
The ProfileFile attribute must contain correct information. If it does not, the LPAR creation or deletion fails. VCS cannot guarantee the correctness of the ProfileFile attribute.
The ProfileFile for an LPAR resource must contain valid VIOS mappings. If it does not, and the LPAR resource fails, then VCS is not able to delete VIOS mappings. This leaves the LPAR configuration in an intermediate state.
The ProfileFile for an LPAR must be recreated for the specific physical server if it is live migrated to a physical server. The live migration might assign mapping information which is not the same as earlier ProfileFile.
If VCS encounters an error while creating or deleting an LPAR configuration or VIOS mappings, then online or offline of LPAR resource stops immediately and does not recover from the intermediate state. Administrative intervention is required when an LPAR configuration or VIOS mappings creation or deletion fails.
Some limitations for LPM apply when VCS is configured to manage high availability of LPARs.
See Limitations and unsupported LPAR features.
For more information, refer to the Cluster Server Administrator's Guide.
LPAR migration outside of VCS control
- VCS can detect LPAR migration initiated outside of VCS. During this period, you may see notifications if the migrating node is unable to heartbeat with its peers within LLT's default peer inactive timeout. You can reset the default LLT peerinact timeout value to enable the migrating node to heartbeat with its peers within LLT's default peer inactive timeout. For the example procedure below, the sample value is set to 90 seconds.
To avoid false failovers for LPAR migration outside of VCS control
- Determine how long the migrating node is unresponsive in your environment.
- If that time is less than the default LLT peer inactive timeout of 16 seconds, VCS operates normally.
If not, increase the peer inactive timeout to an appropriate value on all the nodes in the cluster before beginning the migration.
For example, to set the LLT peerinact timeout to 90 seconds, use the following command:
# lltconfig -T peerinact:9000
The value of the peerinact command is in .01 seconds.
- Verify that peerinact has been set to 90 seconds:
# lltconfig -T query
Current LLT timer values (.01 sec units): heartbeat = 50 heartbeatlo = 100 peertrouble = 200 peerinact = 9000 oos = 10 retrans = 10 service = 100 arp = 30000 arpreq = 3000 Current LLT flow control values (in packets): lowwater = 40
- Repeat steps 1 to 3 on other cluster nodes.
- Reset the value back to the default after the migration is complete.
To make LLT peerinact value persistent across reboots:
- Append the following line at the end of /etc/llttab file:
set-timer peerinact:9000
After appending the above line, /etc/llttab file should appear similar to the following:
# cat /etc/llttab set-node host1 set-cluster 1234 link en2 en-00:15:17:48:b5:80 - ether - - link en3 en-00:15:17:48:b5:81 - ether - - set-timer peerinact:9000
Some limitations for Live Partition Mobility (LPM) apply when VCS is configured to manage high availability of LPARs.
See Limitations and unsupported LPAR features.
For more information on VCS commands, see the Cluster Server Administrator's Guide.
For attributes related to migration, see the Cluster Server Bundled Agents Reference Guide.
To migrate the managed LPAR without ProfileFile support
- From the source managed system, back up the LPAR profile. After migration completes, the LPAR and its profiles are automatically deleted from the source.
For VCS to manage the LPAR, the profile is required on the managed physical system of the management VCS that is part of the system list of the LPAR resource.
- On the destination system, rename the LPAR profile that was created during initial configuration of LPAR as a resource on all systems. LPM validation fails if it finds the profile with same LPAR name on the destination managed physical system
- Migrate the managed LPAR.
- Perform one of the following:
If migration succeeds, the profile on source is removed. Restore and rename the LPAR profile from the backup that was taken in step 1. Remove the renamed LPAR profile on the destination.
If migration fails, remove the backup profile on the source. On the destination, rename the renamed LPAR profile to original LPAR profile.