Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Rejection and abortion of an LM

If an LM cannot be done then it is rejected or aborted and the BS2000 system that needs migrating continues running on the source SU.
All measures undertaken by the LM are automatically reversed.

Rejecting an LM

Before the migration it is first checked if all preconditions for a successful LM are fulfilled.
If the preconditions are not fulfilled, then the task is rejected and the reasons are provided (as conflicts) to the caller in individual messages. These can be, for example:

  • There is not enough free main memory on the target SU.
  • A device that is assigned to the guest system that needs to be transferred is not generated on the target SU or is assigned exclusively to another system.

As a measure, the reported issues or conflicts must be solved. The process can be repeated then.

Details about the prerequisites are described in chapter -> Usage scenarios and preconditions for LM.

Aborting an already running LM

Also after the start of the LM problems can occur that force the abortion of the migration.
In this case, all already finished action are reversed (this is valid also for the devices that were automatically detached – they are attached again automatically).
The reason for an abortion is reported to the caller in additional messages.

The following reasons can cause an abortion:

  • Problems when assigning the necessary resources to the target SU.
  • The networks connection between the SE Servers was interrupted.
  • The always changing main memory pages of the guest system cannot be transferred from the source SU to target SU within the intended time (SU /390).
  • The attached disks in the guest system are not in operable state on the target SU (SU /390).


Abortion of the Live Migration because of issues when transferring the main memory

On SU /390:

VM2000 checks the necessary time for memory transfer to keep the interruptions of the system under migration between SUSPEND and RESUME as short as possible.
The decisive factor here are the number of the changes of the main memory, the available CPU capacity of the monitor system and the transfer rate of the internal network MCNPR (the recommended LAN configuration is described in the chapter -> Network connections).
If it cannot be ensured that the guest system under migration can be transferred to the target SU without noticeable delays, then the LM is interrupted with the message VMS2425 and the system continues running on the source SU.

Example for output of the message VMS2425:

% VMS2425 CHANGING MEMORY PAGES CANNOT BE TRANSFERRED IN TIME. LIVE MIGRATION OF VM (12,VM12PROD) TO TARGET SU 'ABGSE701' ABORTED

On SU x86:

X2000 executes the memory transfer with own CPUs. This means that the LM has no influence on the CPU capacity in BS2000. However, LM causes the BS2000 to become slower because of the memory monitoring and memory transfer.
A slow ISL connection and a high memory change rate can lead to long SUSPEND/RESUME times here, but the LM is executed in every case.