InfoScale™ 9.0 Virtualization Guide - AIX
- Section I. Overview
- Storage Foundation and High Availability Solutions in AIX PowerVM virtual environments
- Overview of the InfoScale Virtualization Guide
- About the AIX PowerVM virtualization technology
- About InfoScale products support for the AIX PowerVM environment
- About IBM LPARs with N_Port ID Virtualization (NPIV)
- About Veritas Extension for Oracle Disk Manager
- Virtualization use cases addressed by InfoScale
- 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
- Dynamic Multi-Pathing in the logical partition (LPAR)
- Dynamic Multi-Pathing in the Virtual I/O server (VIOS)
- InfoScale products in the logical partition (LPAR)
- Storage Foundation Cluster File System High Availability in the logical partition (LPAR)
- Dynamic Multi-Pathing in the Virtual I/O server (VIOS) and logical partition (LPAR)
- Dynamic Multi-Pathing in the Virtual I/O server (VIOS) and InfoScale products in the logical partition (LPAR)
- Cluster Server in the logical partition (LPAR)
- Cluster Server in the management LPAR
- Cluster Server in a cluster across logical partitions (LPARs) and physical machines
- Support for N_Port ID Virtualization (NPIV) in IBM Virtual I/O Server (VIOS) environments
- About setting up logical partitions (LPARs) with InfoScale products
- Configuring IBM PowerVM LPAR guest for disaster recovery
- Installing and configuring Storage Foundation and High Availability (SFHA) Solutions in the logical partition (LPAR)
- Installing and configuring storage solutions in the Virtual I/O server (VIOS)
- Installing and configuring Cluster Server for logical partition and application availability
- Enabling Veritas Extension for ODM file access from WPAR with VxFS
- 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
- About simplified management
- About Dynamic Multi-Pathing in a Virtual I/O server
- About the Volume Manager (VxVM) component in a Virtual I/O server
- 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 IO client adapter settings for Dynamic Multi-Pathing (DMP) in dual-VIOS configurations
- Using DMP to provide multi-pathing for the root volume group (rootvg)
- Boot device management on NPIV presented devices
- Virtual machine (logical partition) availability
- Simplified management and high availability for IBM Workload Partitions
- About IBM Workload Partitions
- About using IBM Workload Partitions (WPARs) with InfoScale products
- Implementing InfoScale support for WPARs
- How Cluster Server (VCS) works with Workload Patitions (WPARs)
- Configuring VCS in WPARs
- Configuring AIX WPARs for disaster recovery using VCS
- High availability and live migration
- About Live Partition Mobility (LPM)
- About the partition migration process and simplified management
- About Storage Foundation and High Availability (SFHA) Solutions support for Live Partition Mobility
- Providing high availability with live migration in a Cluster Server environment
- Providing logical partition (LPAR) failover with live migration
- Limitations and unsupported LPAR features
- Multi-tier business service support
- Server consolidation
- About IBM LPARs with virtual SCSI devices
- Using Storage Foundation in the logical partition (LPAR) with virtual SCSI devices
- Using Storage Foundation with virtual SCSI devices
- Setting up DMP for vSCSI devices in the logical partition (LPAR)
- About disabling DMP for vSCSI devices in the logical partition (LPAR)
- Preparing to install or upgrade Storage Foundation with DMP disabled for vSCSI devices in the logical partition (LPAR)
- Disabling DMP multi-pathing for vSCSI devices in the logical partition (LPAR) after installation or upgrade
- Adding and removing DMP support for vSCSI devices for an array
- How DMP handles I/O for vSCSI devices
- Using VCS with virtual SCSI devices
- About server consolidation
- About IBM Virtual Ethernet
- 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.