VMware-Server verweigert den Dienst

© Nikita Sobolkov, 123RF

Lost in Update

Ein Administrator gerät bei einer Linux-Distribution mit Paket-Updates in eine Falle, aus der er sich mit Geschick wieder befreien kann. Ein Einblick in einen Unfall und seine praktische Lösung.
Strom sparender Computereinsatz hilft nicht zuletzt auch Kosten zu senken. ADMIN 02/2011 geht der Frage nach, was Administratoren tun können, damit ihre ... (mehr)

Gerade im heimischen Umfeld sind Linux-Distributionen mit tagesaktuellem Update-Stand keine Seltenheit. Die Updates sind höchstwahrscheinlich sogar automatisiert und der Benutzer bemerkt davon nichts – es sei denn, eine Applikation verweigert anschließend ihren Dienst.

Prinzipiell gibt es dann verschiedene Ansätze, um das Problem zu lösen. Der vorliegende Artikel erläutert diese am konkreten Beispiel – hier versagte der VMware-Server 2.0 seinen Dienst, nachdem der Administrator das darunterliegende OS von Fedora 13 auf Fedora 14 aktualisiert hatte.

Vorgeschichte

Ausgangspunkt war ein funktionierender Vmware-Server [1] unter einem 64-Bit-Fedora 13 (inklusive aller vorhandenen Updates) [2] . Neben den verschiedensten Gästen für Test-Zwecke laufen dort zwei quasi-produktive virtuelle Maschinen, auf die der Autor nur für einen begrenzten Zeitraum verzichten kann. Fedora 14 war gerade frisch erschienen und die ersten Erfahrungen auf anderen Rechnern stimmten positiv auf ein vollständiges Upgrade der heimischen Linux-Welt. Also flugs die neuen Paket-Repositories einbinden und den Paketverwalter Yum [3] anwerfen.

Dank eines schmalen OS-Images und schneller Internet-Anbindung schmückte den Server einige Minuten und einen Reboot später ein taufrisches Fedora 14. Nur irgendwie funktionierte die Verbindung zur Vmware-Anwendung nicht mehr. Ein Blick in die Datei »/var/log/messages« offenbarte das zugrunde liegende Problem ( Listing 1 ) – der Prozess »vmware-hostd« hatte sich mit einem sogenannten Segmentation Fault verabschiedet, er hat also versucht, auf einen Speicherbereich zuzugreifen, der vor einem solchen Zugriff geschützt ist.

Listing 1

Segmentation Fault bei vmware-hostd

 

Ein erste Analyse zeigte, dass sich die Vmware-Anwendung nicht mit der neueren Version der glibc von Fedora 14 verträgt. Gibt es eine neuere Version des VMware-Servers? Nein, denn VMware entwickelt dieses Produkt nicht mehr weiter [4] . Die Alternative wäre das ESXi-Produkt [5] . Leider ist die vorhandene Hardware nicht kompatibel, also scheidet dieser Ansatz als kurzfristige Lösung aus. Ein Blick auf den Fedora-Update-Server zeigt, dass es auch keine neuere Version des Glibc-Paketes gibt. Ein OS-Update als Lösungsmöglichkeit entfällt somit auch.

Bleiben nur noch zwei Wege, um des Problems Herr zu werden: ein Fallback der Änderung am System oder ein eigener Fix oder Workaround. Der Fallback entspricht praktisch dem Downgrade von Fedora 14 auf Fedora 13. Ohne entsprechende Vorbereitungen wie Dateisystem- oder Volume-Snapshots ist dies keine triviale Angelegenheit. Außerdem ist das Problem der Unverträglichkeit von Applikationen mit neueren Glibc-Version nicht unbekannt und für bestimmte Anwendungen recht einfach zu beheben.

Notbehelf

Der Workaround in diesem Fall ist die Parallel-Installation einer älteren Variante der Bibliothek und die anschließende Modifikation der Applikations-Umgebung, um die "richtigen" Bibliotheken zu verwenden. Was sich einfach anhört, kann im konkreten Fall ziemlich aufwendig sein und hier führte der erste Versuch leider gar nicht zum Erfolg. Inzwischen war ein ganzer Tag vergangen und der Verlust der zwei oben erwähnten virtuellen Server begann so richtig zu schmerzen. Eine Lösung musste her – also doch der Downgrade ( Listing 2 ).

Listing 2

Handarbeit vor dem Downgrade

 

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023