Lablog: Virtualisierungssoftware

Aus dem Testlabor: Update-Chaos bei Virtuozzo-Installation

16. März 2009, 18:06 Uhr | Andreas Stolzenberger
Zum Aufwecken der Parallels Container musste sich der 2nd-Level-Support einloggen und die Installation per Fernsteuerung »wachküssen«.

Im Sommer 2008 installierte Network Computing die Parallels-Virtuozzo-Containers für Windows 4.0 auf zwei Maschinen. Nach dem Test bleiben die Systeme monatelang im Winterschlaf, aus dem sie jetzt nicht mehr richtig aufwachen wollen.

Mit Virtuozzo von Parallels hat Network Computing im letzten Jahr gleich doppelt virtualisiert. Die eigentlichen Host-Rechner für die System-Virtualisierungsoftware waren ihrerseits virtuelle Maschinen innerhalb des laboreigenen Vmware-Clusters. Technisch funktioniert das problemlos und für die primär auf Funktion und Bedienung ausgelegten Tests genügt auch die Performance.

Nachdem Network Computing im Spätsommer 2008 die Tests mit Virtuozzo Containers vorerst beendet hatte, legte das Laborteam die Host-VMs schlafen. Für den Moment bestand kein Bedarf an dieser Installation.

Doch das ändert sich gerade. Für eine der kommenden Ausgaben von Network Computing steht das Thema Virtualisierung auf dem Plan. Also weckt das Labor-Team die Virtuozzo-Server aus ihrem Dornröschenschlaf. In den vergangenen sechs Monaten hat sich natürlich eine ganze Reihe an Updates angesammelt.

Updates en masse

Sowohl die Container-Software als auch der darunter liegende Windows-2003-Server möchten eine Fülle neuer Patches einspielen. Auf beiden Hosts beginnt das Update-Rennen, wobei sich das Parallels-Update-Tool mehrfach darüber beschwert, dass sich etliche Neuerungen gar nicht einspielen lassen.

Am Ende der Update-Orgie und vielen Neustarts scheinen beide Hosts glücklich und zufrieden zu sein, nur: Die Virtuozzo-Core-Service läuft auf beiden Hosts nicht an. Selbst ein paar weitere Neustarts als übliches Windows-Allheilmittel helfen nicht: Die Container bleiben stumm.

Network Computing startet einen Support-Call und übermittelt dem 1st-Level-Support mittels des Parallels-eigenen Tools alle wesentlichen Informationen zu einem der Systeme. Zwei Tage liefern sich Labor und 1st-Level-Support einen E-Mail-Schlagabtausch: Zunächst ist die abgelaufene Lizenz schuld, dann scheint das Update-Durcheinander die Quelle allen Übels zu sein.

Microsoft soll schuld sein

Microsoft soll verschiedene Updates unter ein und derselben Hotfix-Nummer verteilt haben, und eines davon würde sich wohl mit Parallels kabbeln. Die Empfehlung vom Support: Die letzten paar Updates von MS und Parallels entfernen und nochmal von vorne anfangen. Auf Nachfrage kann der Support aber keine exakte Liste der Updates liefern, welche Parallels zur »Koalition des Bösen« rechnet.

Also eskaliert das Ganze zum 2nd-Level-Support, welcher sich am dritten Tag per Webex auf einen der betroffenen Server einklinkt.

Nach einigen Tests steht der Schuldige fest: Im System hängt unter c:windowssystem32 eine veraltete vzdsklib.dll herum, die ein Virtuozzo-Update schon längst hätte austauschen sollen. Der Support spielt manuell eine neuere Version ein, und schon schaltet Virtuozzo die Lichter in den Containern an. Auch der zweite Node erwacht mit einer neuen vzdsklib.dll zum Leben.

DLL wurde nicht ersetzt

Als Ursache stellt der Parallels-Support nun folgendes fest: Eines der Virtuozzo-Updates konnte die gelockte DLL nicht ersetzen und hätte dies bei einem Neustart machen müssen. Dem sei jedoch ein heimtückisches Windows-Update zuvor gekommen, das den DLL-Tausch offensichtlich verhindert habe.

Der Support rät daher: Administratoren müssen immer zuerst alle verfügbaren Virtuozzo-Updates einspielen und danach neu starten, auch wenn das Virtuozzo-Update-Tool nicht explizit einen Neustart verlangt. Erst danach darf der Verwalter MS-eigene Updates installieren, sonst könnte es abermals zu einem Konflikt wie dem aktuellen kommen.

Fragen bleiben offen

Die Labor-Crew wird sich zukünftig wohl an diese Anweisung halten. Dennoch bleibt Unverständnis: Die vzdsklib.dll ließ sich bei abgeschaltetem Virtuozzo-Dienst und laufendem System umbenennen und ersetzen.

Daraus folgt: Wenn der Dienst steht, ist auch die dll nicht gesperrt. Warum also kann der schlaue Parallels-Update-Manager nicht genau diesen Weg automatisch beschreiten und allen Beteiligten einen lästigen Neustart ersparen?

Auch sollte ein herstellereigenes Update-Tool in der Lage sein, die Integrität der Softwareinstallation zu prüfen und nötigenfalls korrigierend einzugreifen. Zumindest hätte dem Tool auffallen müssen, dass eine der dringend benötigten Bibliotheken einen falschen Versionsstand aufweist. So wüsste der Administrator umgehend, was er zu tun hat und könnte sich drei Tage Downtime ersparen.

Immerhin geht es um eine Software, die auf einem einzelnen Node Dutzende wenn nicht Hunderte virtueller Systeme betreiben kann. Da fallen drei Tage Ausfallzeit in der Regel unangenehm auf.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Parallels

Matchmaker+