Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Usage scenarios and preconditions for LM

During Live Migration (LM) a BS2000 system is moved to 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).
  • Main memory
    There must be enough main memory on the target SU to take over the BS200 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 both 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 on BS2000 (IORSF/X2000) must be compatible for source SU and target SU, i.e. that the BS2000 are configured in the same way on both Server Units (the same host connector and unit ID) and assigned to the same devices (see also notes about 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.0) 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, OSD/XC and ONETSERV/BCAM necessary for the LM are listed in the release documentation.