Allgemeines
- Auf einer Quell-SU kann immer nur eine LM gestartet werden, jeder weitere Aufruf wird abgewiesen solange die LM noch läuft.
Eine weitere LM, bei der diese SU als Ziel-SU fungiert, ist jedoch möglich. - Die LM wird abgewiesen wenn eine dynamische I/O-Konfigurationsänderung läuft (angestoßen durch /START-CONFIGURATION-UPDATE im Monitorsystem - siehe das VM2000-Manual [3]).
- Während der LM wird das Kommando /START-CONFIGURATION-UPDATE abgewiesen.
- Eine Live Migration zwischen Server Units mit unterschiedlicher CPU-Leistung beeinflusst die Performance der laufenden Anwendungen.
- Wird zu einer Ziel-SU mit mehr Prozessoren als auf der Quell-SU migriert, bleibt die Anzahl der laufenden BS2000-CPUs unverändert.
- Wird zu einer Ziel-SU mit weniger Prozessoren als auf der Quell-SU migriert, werden die überzähligen BS2000-CPUs per /DETACH-DEVICE außer Betrieb genommen und geblockt.
Bei einer Zurückmigration werden die vorher geblockten und weggeschalteten CPUs automatisch wieder zugeschaltet. - Wenn sich nach der LM die Geschwindigkeit einer einzelnen CPU ändert, können die vom Accounting geschriebenen Daten nicht ohne weiteres für eine genaue bzw. korrekte Abrechnung der verbrauchten CPU-Zeiten benutzt werden.
In solchen Fällen sollte man das Accounting nach der LM neu starten und die Abrechnungsdateien getrennt auswerten.
- Bandbetrieb ist während einer LM technisch nicht möglich und ist deshalb vor der Migration einzustellen, da die Geräte sonst nicht weggeschaltet werden können (/DETACH-DEVICE).
Weggeschaltete Bandgeräte werden auf der Ziel-SU nicht automatisch zugeschaltet. - Lokale Platten (z.B. das im Werk installierte STBY Pubset) werden ebenfalls weggeschaltet.
- PAV-Alias-Geräte auf SU /390 werden vor der Migration automatisch weggeschaltet und nach der Migration auf der Ziel-SU wieder zugeschaltet, allerdings kann es sich dabei um andere PAV-Alias-Geräte handeln (DPAV).
- Die aus dem SE Manager aufgebauten Verbindungen zu lokalen KVP-Konsolen und Dialog-Verbindungen über das Server-interne LOCLAN werden durch die LM abgebrochen.
Verbindungen aus dem Netzwerk des Kunden (auch Konsol-Verbindungen über OMNIS) bleiben dagegen erhalten.
Hinweise zum VM2000-Betrieb
- Das Monitorsystem von VM2000 kann nicht migriert werden.
- Die Hauptspeichergröße des Monitorsystems sollte mindestens 512 MB betragen.
- Bei SU /390 muss das Monitorsystem mit genügend CPU-Kapazität ausgestattet sein (Anzahl virtueller CPUs / Multiprozessorgrad, CPU-Quote, Maximale CPU-Leistungsaufnahme), sonst kann es zu Performanceproblemen kommen, die unter Umständen zum Abbruch der LM führen.
Hinweis: Die für eine LM notwendige CPU-Kapazität entspricht auf der Quell-SU etwa einer realen CPU und auf der Ziel-CPU etwa 1,4 realen CPUs. - Abhängig von der Größe der CPU-Pools kann bei der Migration die Anzahl der aktiven CPUs erhöht oder reduziert werden, sie kann jedoch nie größer werden als der beim /CREATE-VM angegebene Multiprozessorgrad. Falls der Ziel-CPU-Pool weniger reale CPUs hat als die migrierte VM zugeschaltete vCPUs hat, werden die überzähligen vCPUs automatisch weggeschaltet und geblockt. In dem umgekehrten Fall werden eventuelle weggeschaltete vCPUs automatisch zugeschaltet.
- Die globalen VM2000-Ressourcen (CPU-Pools, VM-Gruppen, Assignment-Sets) und die BS2000-Geräte des migrierenden BS2000-Systems dürfen während der LM nicht geändert werden.
- Wird die zu migrierende VM mit einer MONJV überwacht (definiert bei /CREATE-VM oder /ACTIVATE-VM-DEFINITION), wird auf der Quell-SU zu Beginn der Migration auf Distanz 87 - 94 der MONJV der String MIGR-OUT eingetragen.
War die Migration erfolgreich, dann wird der Überwachungs-Zustand auf $T gesetzt (VM terminiert). - Die LM wird abgewiesen, wenn vorher VM2000-Shutdown eingeleitet wurde (Kommando /SHUTDOWN-VM VM-ID=*VM2000).
Hinweise zur I/O-Konfiguration bei SU /390
Bei einer LM wird die I/O-Konfiguration nur für jene BS2000-Geräte, die der zu migrierenden BS2000-VM zugewiesen sind, im Hinblick auf einer Abweisung geprüft.
Dennoch wird empfohlen, die I/O-Konfiguration an der Quell-SU und Ziel-SU gleich zu halten.
Wenn sich bei SU /390 die I/O-Konfiguration der Quell-SU und der Ziel-SU unterscheiden (z.B. wenn an der Ziel-SU zusätzliche Geräte generiert sind), dann bekommt die VM zusätzlich zu ihrem Status den Substatus DIFF.
Beispiel :
/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
Im SE Manager wird der Status RUNNING | DIFF. nach der Migration auf der Ziel-SU im Menü Bedienung des migrierten Systems angezeigt:
Solange eine VM den Substatus DIFF hat, ist sie von der dynamischen I/O-Konfigurationsänderung ausgeschlossen, und Geräte, die auf der Quell-SU nicht generiert waren, können ihr auf der Ziel-SU nicht zugewiesen werden.
Den Substatus DIFF behält die VM, bis sie entweder zur Quell-SU zurück migriert oder auf der Ziel-SU neu aktiviert wird (neue Aktivierung erfolgt durch die Kommandos /DELETE-VM und /ACTIVATE-VM-DEFINITION und ist nur für persistente VMs möglich).
Hinweise zur I/O-Konfiguration bei SU x86
Bei einer LM wird die I/O-Konfiguration nur für jene BS2000-Geräte, die dem zu migrierenden BS2000-System zugewiesen sind, im Hinblick auf einer Abweisung geprüft.
Dennoch wird empfohlen, die I/O-Konfiguration an der Quell-SU und Ziel-SU gleich zu halten.
Auf SU x86 sollten auch jene BS2000-Geräte gleich generiert werden (Gleichheit von Gerätetyp, Host-Connector und Unit-ID für dieselbe BS2000-MN), welche der zu migrierenden BS2000-VM nicht zugewiesen sind.
Andernfalls kommen bei der LM auch für nicht zugewiesene Geräte mit unterschiedlicher Generierung Warnungen und solche Geräte können dann auf der Ziel-SU der migrierten BS2000-VM gar nicht zugewiesen werden.
Im Native-BS2000-Fall sind ale Geräte dem BS2000 zugewiesen. Bei ungleicher Generierung von BS2000-Geräten ist eine LM je nach Situation nur einseitig oder gar nicht möglich.