General
- Only one LM can be started on a source SU. Every further start is rejected as long as the LM is running.
However, a further LM for which this SU functions as target SU is possible. - The LM is rejected when a dynamic I/O configuration change is running (initiated with /START-CONFIGURATION-UPDATE in the monitor system – see the VM2000 manual [3]).
- The command /START-CONFIGURATION-UPDATE is rejected during the LM.
- A Live Migration between Server Units with different CPU performance influences the performance of the running applications.
- If a migration is done to a target SU with more processors than on the source SU, then the number of running BS2000 CPU remains the same.
- If a migration is done to a target SU with less processors than the source SU, then the redundant BS2000 CPUs are detached and blocked with /DETACH-DEVICE.
During a return migration the earlier blocked and detached CPUs are automatically attached. - If the speed of an individual CPU changes after the LM, then the data written by accounting cannot be readily used for an exact or correct calculation of used CPU times.
In those cases, the accounting should be restarted after LM and the accounting files should be evaluated in a separate way.
- Tape operation is technically not possible during an LM and therefore needs to be stopped before the migration as the devices cannot be detached otherwise (/DETACH-DEVICE).
Detached tape devices are not automatically connected on the target SU. - Local disks (for example the STBY pubset which has been installed in the factory) are also detached.
- PAV alias devices on SU/390 are automatically detached before the migration and attached after the migration on the target SU. However, other PAV alias devices can be involved (DPAV) on the target SU.
- The connections started from the SE Manager to the local KVP consoles and dialogue connections through server-internal LOCLAN are disconnected by the LM.
In contrast, connections from the network of the customer (also console connections through OMNIS) remain operable.
Notes for VM2000 Operation
- The monitor system of VM2000 cannot be migrated.
- The main memory size of the monitor system should be at least 512 MB.
- For SU /390 the monitor system must be equipped with enough CPU capacity (number of virtual CPUs / multiprocessor level, CPU quote, maximal CPU power consumption), otherwise performance issues can occur that in certain circumstances can lead to the LM being aborted.
Note: The CPU capacity needed for LM corresponds to approximately one real CPU on the source SU and to approximately 1,4 real CPUs on the target SU. - Depending on the size of the CPU pool, the number of active CPUs can be increased or reduced during the migration, but it cannot be increased beyond the multiprocessor level provided by /CREATE-VM. If the target CPU pool has less real CPUs than the migrated VM has attached vCPUs , then the surplus vCPUs are automatically detached and blocked. In the reversed case possible detached vCPUs are automatically attached.
- The global VM2000 resources (CPU pools, VM groups, assignment sets) and the BS2000 devices of the migrating BS2000 system should not be changed during the LM.
- If the VM that needs to be migrated is monitored with a MONJV (defined during /CREATE-VM or /ACTIVATE-VM-DEFINITION), then on the source SU at the start of the migration the string MIGR-OUT is written at the distance 87 – 94 of the MONJV.
If the migration is successful, than the monitoring state is set to $T (VM terminated). - The LM will be rejected if VM2000 shutdown has been initiated before (command /SHUTDOWN-VM VM-ID=*VM2000).
Notes about I/O configuration for SU /390
Only the I/O configuration for those BS2000 devices that are assigned to the BS2000 VM to be migrated is checked in regards to a rejection during an LM.
Nevertheless, it is recommended that the I/O configurations on the source SU and target SU are kept the same.
If in case of SU /390 the I/O configuration of the source SU and target SU are different (for example if additional devices have been generated on the target SU), then the VM receives additionally to its status the sub-status DIFF.
For example:
/SHOW-VM-RESOURCES
...
% VM-ID STATE VERSION PER ADMIN PRIV
% 1 MONITOR RUNNING V11.0A NO YES AS
...
% 12 VM12PROD RUNNING(DIFF) V10.0A NO NO AS
The status RUNNING|DIFF is displayed in SE Manager after the migration to the target SU in menu Operation of the migrated system:
As long as a VM has the sub-status DIFF, it’s excluded from the dynamic I/O configuration change and devices that were not generated on the source SU cannot be assigned to it on the target SU.
The sub-status DIFF keeps the VM until it’s either migrated to the source SU or it is reactivated on the target SU (new activation is done with the commands /DELETE-VM and /ACTIVATE-VM-DEFINITION and is only possible for persistent VMs.)
Notes for I/O configuration for SU x86
The I/O configuration is only checked in regards to rejection for those BS2000 devices that are assigned to the BS2000 system that needs to be migrated.
However, it is recommended that the I/O configuration on the source SU and target SU is kept the same.
The BS2000 devices that are not assigned to the BS2000 VM under migration should also be generated identically on SU x86 (sameness of device type, host connector and unit ID for the same BS2000 MN).
Otherwise, warnings will appear also for unassigned devices with different generation during LM and those devices cannot be assigned on the target SU of the migrated BS2000-VM at all.
In the case of native BS2000, all devices are assigned to the BS2000. In case of unidentical generation of BS2000 devices, an LM is only possible on one side only or not at all, depending on the situation.