In this chapter we provide SAP-relevant specifics for the use of Live Partition Mobility (LPM). The International SAP IBM Competence Center (ISICC) provides the technical whitepaper Live Partition Migration of SAP Systems under Load, available at:

Some parts of this technical brief are also reflected here.

Using IBM PowerVM Live Partition Mobility (LPM), SAP clients can move SAP application server and database instances running in AIX or Linux from one physical server to another without the need to schedule application downtime. LPM is currently available for POWER6 and POWER7 technology-based servers.

Even with today's mid-range servers, clients typically run a number of different SAP systems in shared processor pool partitions on a single server. This makes it increasingly difficult to schedule the required downtime window to perform system maintenance or upgrades, as one has to negotiate with a number of different departments. Live Partition Mobility helps to solve this challenge.

Live Partition Mobility can also be used as a mechanism for server consolidation because it provides an easy path to move applications from individual, stand-alone servers to consolidation servers. For partitions with workloads that have widely fluctuating resource requirements over time, for example, with a peak workload at the end of the month or the end of the quarter, one can use LPM to consolidate partitions to a single server during the off-peak period, allowing you to power-off unused servers. Then move the partitions to their own, adequately configured servers, just prior to the peak. This approach also offers energy savings by reducing the power to run and cool machines during off-peak periods. Live Partition Mobility can be automated and incorporated into system management tools and scripts. Support for multiple concurrent migrations makes it possible to vacate systems very quickly. For single-partition migrations, the HMC offers an easy-to-use migration wizard. LPM can help to achieve the overall continuous availability goals.

With Live Partition Mobility you can eliminate the need to shut down SAP applications to achieve the following goals:

A migration transfers the complete system environment. This includes the memory content, processor states, attached devices, and network sessions connected to users or other systems. During the migration process there is a very short period of time where processing is suspended on the source server. LPM then performs some critical synchronization before resuming the partition on the destination server again. To an SAP user this might look like a temporary increase in response time (you would see the hour glass), but running transactions will continue seamlessly after the switch.

Figure 6-1 on page 65 shows a potential migration scenario. A partition called siccpm01 is migrated from an 8-way server to a 32-way server. During the whole duration of the migration process, SAP users that are connected to the SAP application can continue to work.

It is important to note that Live Partition Mobility is not an alternative for high availability solutions for a number of reasons, for example:

Live Partition Mobility is currently available on POWER6 and POWER7 processor-based servers. AIX 5.3, AIX 6.1, AIX 7.1, and Linux are supported. On IBM i, Live Partition Mobility is planned to be made available with a Technology Refresh for Release 7.1 and will be available on POWER7 processor-based servers. All I/O must be fully virtualized.

The OS and all other data of the mobile partition must reside on external storage subsystems. There must be at least one Virtual I/O Server (VIOS) active on the system and the mobile partition cannot use any physical adapter during the migration. Typical client implementations use a dual VIOS configuration for redundancy. LPM will keep the same configuration when moving a partition to another server (presuming that the target server is also running with a dual VIOS setup).

Requirements, setup, and operations including advanced migration scenarios, as for example the migration of partitions with dedicated I/O adapters, are covered in detail in the product documentation in IBM PowerVM Live Partition Mobility, SG24-7460, accessible at:.

The ISICC evaluated the performance of the Live Partition Mobility migrations with SAP systems running at various load levels. The results are documented in the whitepaper Live Partition Migration of SAP Systems under Load, available at:

One result documented in that paper is the end-to-end migration rate with different load scenarios (see Figure 6-2). An idle partition can be migrated with a rate of about 4 GB/min. The migration rate decreased to about 2.2 GB/min when the partition was running at about 80% utilization. The transfer rates documented in the paper are consistent with transfer rates clients have achieved with real live migrations of their production systems.

SAP-specific recommendations are documented in SAP Note 1102760.

Live Partition Mobility is transparent to SAP applications, and no code changes (for example, in the SAP kernel) are required to exploit this feature. Check the above note for the minimum database levels that are supported with LPM.

An SAP-specific issue is that SAP license keys (for ABAP and Java systems) are based on a hardware key of the partition that is currently hosting the SAP message server. This hardware key changes after moving an SAP application server instance with a message server to another physical system. The hardware key is only read during start-up of the SAP instance and then buffered in local memory. Because the message server stays up and running during the migration, any subsequent logins will be checked against the old hardware key and will proceed without a problem.

However, the next time the message server is restarted the new hardware key is read and user logins may fail, unless a valid SAP license based on the new hardware key is installed. To avoid any problems regarding this license check, it is recommended to install the additional license keys for all potential target servers in the system landscape in advance. This is similar to what one would have to do for high-availability cluster setups. SAP allows requesting license keys for different hardware keys (check SAP Notes 181543 and 538081).

To simplify the administration of SAP license keys in system landscapes where the message server can move between several physical servers, SAP has introduced a new license key feature called Flexible License Mechanism. With that method the license key is no longer tied to the hardware key of the message server. The flexible license mechanism uses a separate ID generator, which creates a unique network ID for each message server. This network ID is hardware independent and therefore it is possible to move the message server to a different host and retain the unique ID. It is possible to configure multiple ID generators to eliminate any potential single point of failure.

Refer to the current SAP NetWeaver documentation for a detailed description and instructions of how to set up this new Flexible License Mechanism:

SAP NetWeaver 7.0 EHP2:

SAP NetWeaver 7.3:

There are two videos available that demonstrate the live migration of running SAP systems. The first demo shows the migration of an SAP system running under load using the Hardware Management Console (HMC) to manage the move. The second video shows the integration of IBM PowerVM technology in the SAP NetWeaver stack, making it possible to start LPM operations from the SAP Adaptive Computing Controller (ACC). It also highlights some of the PowerVM-specific performance monitoring metrics that have been integrated in the operating system monitor in SAP CCMS (OS07n).

POWER6 Live Partition Mobility Demo with SAP:

IBM PowerVM and SAP ACC Integration demo:

Live Partition Mobility can be used to perform hardware refreshes without stopping the application. For example, it is possible to migrate from existing POWER6 processor-based servers to new POWER7 technology-based systems. During such a migration operation, the migrating partition will stay in a POWER6 compatibility mode. This is a partition attribute that can be set in the partition profile. The effect is that after the migration POWER7-specific processor enhancements are disabled; most notably the partition is still running in 2-way SMT (Simultaneous Multi-Threading) mode instead of the new 4-way SMT mode that is available with POWER7 technology-based processors. To fully exploit all of the new POWER7 features, a partition eventually has to be stopped and started in POWER7 mode, which requires a scheduled downtime window.

Note that you cannot perform a live migration of a partition that is running in POWER7 mode back to a POWER6 system. Should this be necessary, you would have to either restart the partition in POWER6 compatibility mode or stop the partition and perform an inactive migration.