Hin und wieder ist es notwendig, die Konfiguration eines ESXi Hosts zu exportieren. Zum Beispiel dann, wenn das Flashmedium getauscht werden muss. Das ist eine Standardprozedur, die in der Regel keine Probleme bereitet. Beim Versuch, die Konfiguration eines ESXi 5.0.0 Hosts zu sichern, der ein von IBM angepasstes Image hatte, scheiterte der Export und ich erhielt die Fehlermeldung:

Restore failed: A general system error occured: Internal error

Zunächst ist verwunderlich, daß hier “Restore faild” steht, denn ich wollte die Konfiguration sichern. Der Rest der Fehlermeldung ist so vielsagend wie die “Allgemeine Schutzverletzung im Modul XYZ”, die wir als der PC Steinzeit noch kennen. 😉

Frag die Suchmaschine

Die erste Massnahme ist in einem solchen Fall natürlich, die Fehlermeldung in die Suchmaschine der Wahl einzutippen. Leider bekam ich nur Links auf VMware KB Artikel, die sich nicht genau auf das Problem bezogen. Die dort genannten Ursachen konnte ich an den betroffenen Systemen ausschliessen.

Versionskonflikt?

Der erste Exportversuch wurde mit einer vSphereCLI v5.1 gegen einen ESXi Host v5.0 gemacht. Um einen Versionskonflikt auszuschliessen, probierte ich das selbe nochmals mit einer vSphereCLI v5.0. Es könnte ja sein, daß sich die Syntax der Kommandos verändert hatte, oder Kommandos durch andere ersetzt wurden. Das Ergebnis war aber in beiden Fällen das selbe.

ESXi Shell

Um ein Problem mit der CLI auszuschließen, versuchte ich den Export direkt auf der ESXi Shell.

• DCUI > Troubleshooting options > enable ESXi Shell
• Ctrl + F1
• Login

William Lam hat in seinem Blogartikel “How To Backup & Restore Free ESXi Host Configuration” die Kommandos dazu geschildert.

vim-cmd hostsvc/firmware/backup_config

Es wird normalerweise ein TGZ File erzeugt und unter /scratch/downloads abgelgt. Aber auch diese Methode endete mit einem Fehler.

Made in Japan

Den entscheidenden Hinweis zur Ursache des Problem erhielt ich auf einer japanischen Blog-Site von einem Blogger, der sich v-akiras nennt. Ich spreche zwar nicht japanisch und kann die Schrift auch nicht lesen, aber die entscheidenden Shell Kommandos waren zum Glück in Lateinischen Zeichen. Den Rest erledigte der Google Translator. Das Problem besteht darin, daß auf den betroffenen ESX-Servern das “downloads” Verzeichnis nicht existierte.

Zwischenzeitlich wurde ein Support Ticket bei VMware ausgelöst. Für den beschriebenen Fall schien es keine Unterlagen in der KB zu geben, also verwies ich auf den Blog von v-akiras. Wir konnten gemeinsam das Download Verzeichnis erstellen und so den Export der Konfiguration ermöglichen.

cd /usr/lib/vmware/hostd/docroot
ls -l

Die Ausgabe zeigt einen Symbolic Link “downloads” auf /scatch/downloads

/usr/lib/vmware/hostd/docroot # ls -l
-r--r--r--    1 root     root                544 May 18  2012 background.jpeg
-r--r--r--    1 root     root               2572 May 18  2012 banner.png
-r--r--r--    1 root     root                109 May 18  2012 bullet.png
drwxr-xr-x    1 root     root                512 Nov 13  2012 client
-r--r--r--    1 root     root               4898 May 18  2012 default.css
-r--r--r--    1 root     root                241 May 18  2012 default.js
lrwxrwxrwx    1 root     root                 19 May 18  2012 downloads -> /scratch/downloads/
drwxr-xr-x    1 root     root                512 Nov 13  2012 en
-r--r--r--    1 root     root               1851 May 18  2012 esxcli.css
-r--r--r--    1 root     root               5154 May 18  2012 index.html
-r--r--r--    1 root     root                793 May 18  2012 print.css
drwxr-xr-x    1 root     root                512 Nov 13  2012 sdk
-r--r--r--    1 root     root               2984 May 18  2012 watermark.js
-r--r--r--    1 root     root              54275 May 18  2012 watermark.png

Das Verzeichnis /scratch ist ein Symbolic Link auf ein Verzeichnis /ibm.

lrwxrwxrwx    1 root     root            4 Aug 27 14:30 scratch -> /ibm

In diesem befindet sich nur ein Verzeichnis /var, jedoch kein /download. Genau das ist das Problem.

cd /scratch
/ibm # ls
var

Reparatur

Die notwendigen Schritte sind:

• alternatives Download Ziel anlegen
• symbolic link entfernen
• neunen symbolic link auf neues download Verzeichnis erstellen

/usr/lib/vmware/hostd/docroot # mkdir /tmp/downloads
/usr/lib/vmware/hostd/docroot # rm downloads
/usr/lib/vmware/hostd/docroot # ln -s /tmp/downloads/ /usr/lib/vmware/hostd/docroot/downloads

Nach diesen Schriiten funktionierte der Expor der Konfiguration wieder problemlos. Es handelte sich hierbei nicht um eine Störung, sondern um eine Eigenschaft des von IBM angepassten ESXi Images. Man hatte in diesem Release offensichtlich das Download Verzeichnis vergessen.

Ich hoffe, die Erfahrung wird in einen VMware KB Artikel einfliessen.

Links

• v-akiras Blog – http://srvinfo.exblog.jp/16871567
• virtuallyGhetto – How To Backup & Restore Free ESXi Host Configuration