Overview

IBM i Partition Mobility allows the movement (sometimes called migration) of an IBM i partition from one physical machine to another. There are a few different states in which partitions can be moved:

Active Partition Mobility

Active Partition Mobility is the actual movement of a running partition from one physical machine to another without disrupting the operation of the operating system and applications running in that partition. There are many uses:

• Workload consolidation (move from many systems to one system)
• Workload balancing (move a partition to a system that has a lighter workload)
• Planned CEC outages for maintenance/upgrades
• Impending CEC outages (as an option to keep a partition running if hardware warnings are received)

Inactive Partition Mobility

Inactive Partition Mobility transfers a partition that is “powered off” (not running) from one system to another.
 

Suspended Partition Mobility

A partition can be suspended and later resumed. Suspended Partition Mobility transfers a partition that is suspended from one system to another. It may then be resumed on the target system at a later time.
 

Requirements
 

Software

• IBM i 7.1 TR4 PTF group – SF99707 level 4, or later
• PowerVM Enterprise Edition on both source and target system
• VIOS 2.2.1.4, or later, on both source and target system

Hardware

• Power 7 tower/rack system (or newer generations of Power servers) for both source and destination systems with both:
  1) Firmware release 740.40 or 730.51, or later
  2) IBM Hardware Management Console V7R7.5.0M0, or later
• All I/O must be virtual and supported by VIOS -- can be Virtual SCSI (VSCSI), Virtual Fibre Channel (NPIV), or Virtual Ethernet
• Configuration must use only external storage, and it must be accessible to both source and destination systems
• Both source and destination systems must be on the same Ethernet network

Restrictions

· The logical partition must have all disks backed by physical volumes.

· The logical partition must not be assigned a virtual SCSI optical or tape device.

· The logical partition cannot be activated with a partition profile which has a virtual SCSI server adapter.

· The logical partition cannot be activated with a partition profile which has a virtual SCSI client adapter that is hosted by another IBM i logical partition.

· No virtual SCSI server adapters can be dynamically added to the logical partition.

· No virtual SCSI client adapters that are hosted by another IBM i logical partition can be dynamically added to the logical partition being moved.

· An IBM i logical partition cannot be moved if it has a varied on NPIV attached tape device.

April and May 2016 update - Note that this restriction is lifted with IBM i 7.3 and IBM i 7.2 TR 4.  A partition may now be moved while a supported multi-path capable tape drive is actively in use.  Mult-path capable tape drives include fibre channel attached 3580-005 and later, 3592-E07 and later, and the TS7600 ProtecTIER Virtual Tape Library.  The tape device may be in the midst of a tape operation, such as save or restore, while the partition is moving to the target server, and it will continue to operate seamlessly during that move.  A remaining restriction is that the tape drive or tape library Vary On operation may fail during the move to another server.  If a tape Vary On fails due to an LPM operation, just retry the Vary On.

· For NPIV, you must zone both Worldwide Port Names (WWPNs) associated with a virtual fibre channel adapter.

· The logical partition must not be an alternative error logging partition.

· The logical partition cannot collect physical I/O statistics.

Planning

Configuring your IBM i for virtualization

Refer to the “IBM PowerVM Virtualization Introduction and Configuration” Redbook.

Additional notes:

1. The maximum number of virtual I/O slots is 1024 in the VIOS.

Registering exit programs

If you are interested in having your applications know when a partition is going to move to another system, and when it has completed the move, refer to the IBM Documentation topics Suspend System Exit Programs and Resume System Exit Programs.

For example, by making use of the exit programs, a program could be written that includes automatically varying off any Virtual Fibre Channel attached tape drives prior to the mobility operation and varying them back on again afterwards.

Set-up

Information on preparing for partition mobility can be found in the IBM Documentation topic “Preparing for partition mobility”.

Additional notes:

1. If using 5250 interactive support, ensure both the source and target systems have the "5250 application capable" set to “True” as part of the Capacity on Demand configuration on the Management Console. This capability is turned on via an Activation Code for IBM i interactive support if it was not already part of the system.
2. The Management Console must configure the partition for “restricted I/O”.
3. The VLAN IDs used by the migrating client partition must exist on both the source and target systems.

Once you have set up your server to support mobility, you can validate the configuration using the IBM Documentation topic “Validating the configuration for partition mobility”.

Execution

The mobility function is performed by using the Management Console. Information on using the Management Console to migrate can be found in the IBM Documentation topic “Migrating the mobile partition with HMC”.

Additional notes:

1. Examples of messages in QSYSOPR and/or history log around the time of a partition move:

· CPI09A5 - Partition suspend request in progress.

· CPI09A6 - Partition not ready for suspend request.

· CPI09A7 - Partition suspend request canceled.

· CPI09A8 - Partition resumed after migration.

· CPI09A9 - Partition resumed from hibernation.

There may be other messages in those logs around the same time that will help determine why a mobility operation may have failed.

2. Before moving the partition, vscsi tape and optical devices must be un-configured.
3. Ensure all Virtual Fibre Channel attached tape drives are varied off.
4. When the partition is starting to run on the target system, the Collection Services collector job will cycle the collection so correct hardware information is recorded on the target system.
5. Active State Performance Explorer (PEX) collections that have the PMCO event enabled such as a Trace Profile collection or Profile Mode collection will be forced to a Stopped State during a partition mobility operation. All other Active State PEX collections will continue to run during an LPAR migration. Note that PMCO events in a PEX collection will be enabled if *PMCO is in the list of event subtypes provided in the BASEVT keyword of the ADDPEXDFN command. This command creates the PEX definition used by the STRPEX command.
6. Moving a suspended partition must be done using HMC CLI (migrlpar command with the "--protectstorage 2" parameter).
7. During a mobility operation, the partition ID can change. You may be able to control the partition ID if you use the HMC CLI (migrlpar command with “ –i dest_lpar_id=<lpar_id>”).
8. During a mobility operation, virtual slot IDs may change.

Sampling of ISVs

IBM has tested IBM i Partition Mobility in at least one basic configuration with SAP and with Lawson M3. In each case it was an ISV workload with multiple users, so there was a high CPU utilization throughout the mobility operation. No functional issues were observed, and there was only a small performance impact as the partition was moved. Neither of these ISVs has licensing restrictions that would prevent use of Partition Mobility.

Licensing Considerations

A key consideration for licensing is that Live Partition Mobility is moving from one machine to another -- i.e., from a "Source System" to a "Destination System". The Source System and the Destination System must be owned or leased by the client's enterprise. So, it is the client who acquires, or already owns, the required processor activations on all potential Destination Systems. Note that there are no special processor activation rules or offerings with Live Partition Mobility, so the client should acquire processor activations by using one of the current offerings.

When a partition is moved, the entire image -- and all software in it -- is moved to a Destination System. Passport Advantage products are subject to their Virtualization Capacity License Counting Rules -- refer to the "IBM i" link at that website. For any ISV applications, you must check with the ISV application provider.

Licensing for a Permanent Partition Move

Requirements for a permanent partition move are the same as when doing a manual migration to a new system, namely:

• All standard transfer terms and current transfer offerings apply, in particular:
  • IBM i operating system is licensed to machine serial number. IBM i Entitlement Transfer offering is available if the requirements of the offering are met.
  • IBM i LPPs may be permanently transferred to a new machine within the enterprise, subject to the transfer terms of the LPPs
• Entitlements/Keys are required
• There are no special rules for a Live Partition Mobility permanent move

Licensing for a Temporary Partition Move

If it's a Capacity Back Up (CBU) license, the client owns the registered CBU system and a temporary transfer occurs according to the CBU Terms and Conditions (Ts and Cs). This is business as usual.

If software entitlements have been acquired on all systems, no special Ts and Cs are needed, so partitions may be moved among those systems whenever desired.

If software entitlements have NOT been acquired on the Destination System, there are special rules that apply to the IBM i operating system and the standard set of IBM i Licensed Program Products, namely that the client may temporarily move a partition for up to 70 days to a Destination System. If the partition is active, the 70-day clock starts upon the move. If the partition is inactive or suspended, the 70-day clock starts when the partition becomes active. In either case, warning messages will be issued during the 70-day grace period. These are the requirements that must be met:

• The client must have purchased software entitlements on a Source System
• The Source System must be equal or larger in processor group than any Destination System
• After 70 days, the client must:
  • acquire entitlements on the Destination System, or
  • move entitlements back to the Source System, or
  • move entitlements to another Destination System

An IBM i operating system license amendment allows a temporary move to another machine since the base IBM i operating system license does not allow this.

Software Maintenance Agreement (SWMA) is required on the Destination System in order to get support. These are the main choices:

• Existing SWMA can be transferred, subject to the standard SWMA transfer rules (which may not prove practical for temporary moves), or
• The client must have a minimum of one core of SWMA (and therefore one core of IBM i) on the Destination System in order to get support (note that one core of permanent SWMA will cover a temporary move), or
• The client runs the partition without support on the Destination System

References

Partition mobility overview for HMC

IBM PowerVM Virtualization Introduction and Configuration - This is an introduction to PowerVM that includes basic installation and set up

IBM PowerVM Virtualization Managing and Monitoring - This is a deep dive into how to manage PowerVM virtualization 24x7

IBM PowerVM Enhancements What is new in 2013 - This is a description of the enhancements that were added in 2013, including a chapter on mobility

API Guide (For registering system exits) 

General IBM i Licensing Information 

Software Knowledge Base (Search for “Live Partition Mobility” to find any usage notes.)