Fujitsu Siemens Computers SX series User Manual page 318

Performing DR
If a DR action is rejected by BS2000/VM2000, all configuration changes made up to
then are automatically undone.
Exception:
Owing to the length of time it takes separate mirror disks are not resynchronized.
If during a DR-disconnect action im BS2000 a ZASLAN device is deactivated for which
automatic reactivation has been enabled (SLOW-POLL=*ON), this results in constant
attempts to reactivate the device. In this case entries in the hardware error logging file
are also generated. Consequently reactivation should be disabled before DR-disconnect
is executed (e.g. with /MODIFY-LINE ...,SLOW-POLL=*OFF or with /BCDAC
LINE=... )
Further information on VM2000
The start of a DR process is accepted by VM2000 only if it is accepted within a certain
time by all active guest systems which support DR.
Pure CPU-XSBs are started up and shut down automatically by VM2000. CPUs which
are licensed in VM2000 but are located on XSBs which are not attached at a point in
time are displayed as having the OFF status in VM2000. This applies both for normal
and "extra" CPUs.
Explicit attachment of these CPUs is rejected with the following message until an XSB
is attached using DR:
VMS4152 CPU (&00) IS OFFLINE. COMMAND REJECTED
In the event of DR-connect "normal" CPUs are implicitly attached by VM2000. "Extra"
CPUs must, if required, be attached explicitly by the VM2000 administrator using the
following command (see
/ATTACH-VM-RESOURCES UNIT=*EXTRA-CPU(...)
In the event of DR-disconnect no "extra" CPU may be attached at this time, i.e. "extra"
CPUs must be explicitly detached beforehand by the VM2000 administrator using the
following command:
/DETACH-VM-RESOURCES UNIT=*EXTRA-CPU(...)
Otherwise VM2000 rejects the DR request with the console message VMS4555.
Use of the CPUs added is configuration-dependent and flexible:
The new CPU performance is initially assigned to the existing VMs in accordance with
the CPU-QUOTA set. However, it is also possible to specify, for example, that only one
(new) VM should (primarily) profit from the new CPU performance. Details on planning
the distribution of the CPU performance to the VMs are provided in the manual
Machine
318
"Virtual Machine
System" [14].
Dynamic Reconfiguration
System" manual [14]):
"Virtual
U41272-J-Z385-3-76