Upgrade to xen-tools-4.4.4-196.0.1.el6.x86_64 breaks OVM 3.4.5
Das Upgrade der Xen Tools mit OVM 3.4.5 bringt ein fehlerhaftes Python Script mit, das bei der Live Migration einen Fehler produzieret. Der Fehler selbst sieht schwerwiegend aus, tritt aber erst NACH der erfolgreichen Live Migration auf - sprich die Live Migration funktioniert sehr wohl mit korrektem Ergebnis. Den Fehler kann einfach ignoriert werden.
Nachdem Upgrade auf Xen bzw. Xen-Tools 4.4.4-196.0.1 tritt bei Live Migrations folgender Fehler auf:
OVMAPI_5001E Job: 1532593083343/Migrate VM: myhost.example.com to Server: myserver.example.com/Migrate VM: myhost.example.com to Server: myserver.example.com, failed.
Job Failure Event: 1532593127368/Server Async Command Failed/OVMEVT_00C014D_001 Async command failed on server: myserver2.example.com.
Object: myhost.example.com, PID: 9215, Server error: Command: ['xm', 'migrate', '--live', '0004fb0000060000039081cfef8dd607', '10.46.1.45'] failed (1):
stderr: Error: 'NoneType' object has no attribute 'has_key' stdout: Usage: xm migrate Migrate a domain to another machine.
Options: -h, --help Print this help. -l, --live Use live migration. -p=portnum, --port=portnum Use specified port for migration. -n=nodenum, --node=nodenum
Use specified NUMA node on target. -s, --ssl Use ssl connection for migration. -c, --change_home_server Change home server for managed domains.
--vmfiles="src:dst,src:dst,..." Files for use with storage migration utility , on server: myserver2.example.com,
associated with object: 0004fb0000060000039081cfef8dd607 [Thu Jul 26 10:18:47 CEST 2018]
In /var/log/xen/xend.log findet sich folgende Information
[2018-07-26 10:18:42 4106] ERROR (XendCheckpoint:192) Save failed on domain 0004fb0000060000039081cfef8dd607 (None) - resuming.
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line 182, in save
dominfo.setName(domain_name, False)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2044, in setName
self.info['name_label'] = name
TypeError: 'NoneType' object does not support item assignment
[2018-07-26 10:18:42 4106] DEBUG (XendDomainInfo:3905) XendDomainInfo.resumeDomain(None)
[2018-07-26 10:18:42 4106] ERROR (XendCheckpoint:198) Failed to reset the migrating domain's name
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/xen/xend/XendCheckpoint.py", line 196, in save
dominfo.setName(domain_name)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2044, in setName
self.info['name_label'] = name
TypeError: 'NoneType' object does not support item assignment
[2018-07-26 10:18:45 4106] ERROR (xmlrpclib2:181) Internal error handling xend.domain.migrate
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/xen/util/xmlrpclib2.py", line 134, in _marshaled_dispatch
response = self._dispatch(method, params)
File "/usr/lib64/python2.6/SimpleXMLRPCServer.py", line 418, in _dispatch
return func(*params)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomain.py", line 1417, in domain_migrate
dominfo.setChangeHomeServer(None)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2693, in setChangeHomeServer
if self.info.has_key('change_home_server'):
AttributeError: 'NoneType' object has no attribute 'has_key'
Lt. Oracle (MOS 2420753.1) sollte man nun einen SR eröffnen.
Anmerkung: Die Migration läuft ohne Probleme erfolgreich durch und die migrierte VM kann ohne Einschränkung benutzt werden.
Es handelt sich um einen Fehler im entsprechenden Python Skript, bei dem auf ein undefiniertes Objekt ohne Prüfung referenziert wird, was zu o.a. Problem führt (das Objekt wird in Zeile 3874 auf "None" gesetzt).
Workaround
Mit xen-tools-4.4.4-196.el6.x86_64 sollte der Fehler nicht auftreten.
Wer möchte, kann den Fehler auch selbst beseitigen - Vorsicht, man arbeitet dann auf einer nicht sauberen Version:
Im Skript /usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py muss die Zeile 3874 "self.info = None" gelöscht (oder auskommentiert) werden. Dann den xend neu starten oder besser gleich den OVM Server.
Update: Lösung des Problems
Es gibt inzwischen auch eine Lösung für das Problem - man muss die xen-4.4.4-196.0.3.el6.x86_64 bzw. xen-tools-4.4.4-196.0.3.el6.x86_64 aktualisieren. Diese gibt es seit Mitte August 2018.