Wouldn't it be great if you could do mainframe hardware or software maintenance without ever stopping your critical applications? With z/VM Version 6, Release 2.0, guest mobility is part of z/VM’s toolbox for high availability.
Availability is one of the major strengths of the mainframe environment and z/VM’s Live Guest Relocation (LGR) is another tool to use in pursuit of the goal of continuous availability. The LGR function lets a system administrator move a Linux guest from one z/VM member system to another in a Single System Image (SSI) cluster while the guest continues to run its applications.
The SSI members don’t have to be running on the same level of hardware or z/VM software. An SSI cluster is a group of up to four z/VM systems that share system resources and can be managed as a single z/VM system. SSI was described in more detail in the May 2012 z/Journal article, “Flexible Horizontal Scalability With z/VM Single System Image,” by Emily Kate Hugenbruch and Damian Osisek (available at www.mainframezone.com/article/flexible-horizontal-scalability-with-z-vm-single-system-image.) The LGR capability facilitates application availability during planned outages since the relocation occurs without business disruption. LGR can be used to maintain application continuity during hardware or software maintenance that requires a member to be shut down. Linux guests that run important applications requiring continuous availability can be moved to another member of the SSI cluster during maintenance. The LGR capability may also be used to balance workload across the cluster.
Because of a new concept called relocation domains, relocations for the purposes described previously can occur between z/VM systems on Logical Partitions (LPARs) on the same machine or between z/VM SSI members on different machines, even when those machines are different models of System z. A Linux guest can be moved using LGR between a z10 and a z196 and back again as long as those systems are members of an SSI cluster. This can occur even though the z196 has more advanced architectural facilities than the z10.
The VMRELOCATE TEST Function
To be eligible for relocation to another member of the SSI cluster, a Linux guest must meet certain eligibility requirements. Tests for eligibility requirements are called eligibility checks and serve as the first step in relocation. These tests verify that none of the guest's configuration characteristics make the guest ineligible. For example, the guest's virtual processors must be either all type CP or all type Integrated Facility for Linux (IFL). These tests also include verification that a matching configuration can be established for the guest on the destination member. This includes access to the identical disks and identical shared segments.
LGR allows a non-disruptive test to determine in advance if a guest is eligible for relocation to a particular member of the SSI cluster. This occurs via the VMRELOCATE TEST command. If the guest isn’t eligible, the TEST command returns a message for each ineligibility problem. All eligibility problems can be addressed at once (see Figure 1).
If an attempt is made to relocate this guest without addressing the eligibility problems, the same messages will be received. Once steps are taken to remove the relocation eligibility problems, the user can actually be relocated using the command in Figure 2.
One reason LNX01 was ineligible for relocation to SYSTEM2 was an “architecture incompatibility.” This means an attempt was made to relocate the guest from a member with at least one architectural facility that isn’t available on the destination member system and the guest has already been told the facility is available. Clearly, it isn’t a good idea to do this, as the guest may already be using the facility and it would lose access to that facility if moved to the destination. Relocation domains are available in the SSI to address the issue of relocating Linux guests between SSI cluster members with different levels of z/Architecture hardware or z/VM software.
