Usage scenarios and preconditions for LM

During Live Migration (LM) a BS2000 system is moved from a Server Unit (source SU) to a different Server Unit with the same architecture (target SU), without affecting the availability of the BS2000 and the running applications for the user.
The operating system and the running applications continue running during relocation, which means that the user will not notice the relocation.

LM is possible both for SUs with /390 architecture and VM2000 as well as for SUs x86 with Native BS2000 or with VM2000.

Usage scenarios for Live Migration

• Before planned maintenance, upgrade, reconfiguration and hardware or firmware update.
  The running BS2000 system is migrated to a different SU before the pending date.
• To avoid or solve a resource bottleneck (workload management)
• Reversion: The running BS2000 system can later be relocated back again without interruption

• Recommendation

  It is recommended that the LM is done during a low-peak time.
  For reasons see the following chapter with the frame conditions and details for the sequence of events of an LM.

Prerequisites for Live Migration

• SU Cluster
  • The source SU and the target SU must belong to the same active SU Cluster.
  • For an LM, two servers of the same type (with the same architecture) are needed. Mixed configurations within the /390 family are allowed, for example SU500 with SU700.
  • If the Server Units are on different SE Servers then these SE Servers must be connected to a Management Cluster (see chapter -> Management Cluster - central management of SE Servers).
• BS2000 operating mode
  The source SU and target SU must run in the same BS2000 operating mode (LM of native BS2000 is only possible for SU x86).
• CPU
  The physical CPU expansion of the source and target SUs can be different. The number of active CPUs of the migrated BS2000 system is automatically adjusted for an LM if necessary (see also "General" and "Notes on VM2000 Operation" in chapter -> Further notes about LM).
• Main memory
  The physical main memory expansion of the source and target SUs can be different. There must be enough main memory on the target SU to take over the BS2000 system that needs to be migrated – at least as much as the BS2000 system has allocated on the source SU.
• VM name
  The VM name is not used on the target SU yet.
• VM index
  The VM index of the guest system that needs to be transferred must be free during VM2000 operation, when the VM was created with a permanent VM index.
  If the VM was created with VM-INDEX = *ANY then it’s enough that a random VM index is free on the target SU.
• Maximal number of VM definitions
  The maximal number of VM definitions was not yet reached on the target SU.
• Network connections
  The network connections configured in BS2000 must be implemented on the participating SE Servers in the same network segment. Only in this way can it be ensured that the network connections of the BS2000 systems work correctly after LM.
  Note: This condition is not checked before the LM is carried out.
• BS2000 devices/ I/O configuration
  The configuration of the peripherals used in BS2000 (IORSF/X2000) must be compatible for source SU and target SU, i.e. the BS2000 MNs must be configured the same on both server units (same host connector and unit ID) and assigned to the same devices. (see also the notes on I/O configuration in chapter -> Further notes about LM).
• Availability of the BS2000 devices
  All of the devices assigned to the guest system that is to be relocated must be available on the target SU.
• Global VM2000 resources (CPU pools, VM groups, assignment sets)
  If the VM2000 guest system is assigned to a VM group or to a specific CPU pool, then they must also exist on the target SU (the CPU pool must have at least one CPU attached).
• Status of the BS2000 system
  The status of the guest system that needs to be migrated must be RUNNING, INIT_ONLY, DOWN or DEFINED_ONLY (i.e. the status cannot be WAIT).
  The status is not changed by the LM.
• Special case Native BS2000 for SU x86
  The target SU must also be in the BS2000 operation mode Native BS2000 and there must not exist any BS2000 there. If necessary, it must be deleted in the SE Manager.
• Subsystem REWAS
  The subsystem REWAS (at least V2.0C) must be active in both monitor systems of the SU /390 Cluster. However, for a full functionality, it is recommended that the subsystem REWAS is active in every BS2000 system of a SE Server.
• Product version
  The product versions of VM2000, BS2000 and ONETSERV/BCAM necessary for the LM are listed in the release documentation.