Eine Meldung wie diese kann auf einem ESXi so aussehen:
(vim.fault.InvalidState) {
faultCause = (vmodl.MethodFault) null,
faultMessage = <unset>
msg = "Received SOAP response fault from [<<io_obj p:0x000000899beea2b8, h:5, <TCP '127.0.0.1 : 37600'>, <TCP '127.0.0.1 : 8307 '>>, /sdk>]: restoreConfiguration
The operation is not allowed in the current state."
}
Lösung
Meistens versucht der Admin da grade etwas, das im aktuellen Zustand wirklich nicht erlaubt ist. Zum Beipiel ein Backup der Konfiguration wiederherzustellen.
Es reicht in der Regel aus, den Host in den Wartungsmodus zu versetzen. An der Shell geht das mit:
In letzter Zeit müssen wir einige ESXi Hosts von USB-Sticks oder SD-Karten auf eine lokale boot-SSD (oder HDD, je nach Kundenwun$ch) umziehen. Das geht natürlich weder im laufenden Betrieb noch automatisch – man braucht eine Neuinstallation. Am einfachsten sichert man also die Konfiguration des vSphere ESXi Hosts, installiert schnell „sauber“ neu und stellt selbige Konfiguration wieder her.
ESXi von USB/SD Migration
Backup der Konfiguration
Host neu installieren
⚠️ Die gleiche Version verwenden! ein Umzug von 7.x zu 8.x geht meistens schief, vor allem wenn man mehrere Netzwerke und/oder Storagedapter hat. Im Zweifel erst migrieren, dann updaten. vmWare empfiehlt zwar auch noch den gleichen Build, aber mit (leicht) unterschiedlichen Buildnummern hatten wir bisher noch keine Schwierigkeiten.
Restore der Konfiguration
ESXi Konfiguration sichern (Backup)
SSH auf dem Host einschalten. Je nachdem via vSphere Host Client (Verwalten > Dienste > TSM-SSH > Starten) oder im vCenter (Host > Konfiguration > Dienste > SSH).
Als nächstes als root via SSH auf dem Hosts anmelden und diese beiden Zeilen ausführen:
Die Backup-Datei dann herunterladen (configBundle-HOSTNAME.tgz). Von der angegebenen URL einfach direkt via HTTP(s) herunterladen. Das Sternchen (*) in der URL ist der Hostname oder die IP des Hosts.
ESXi Konfiguration widerherstellen (Restore)
Ein Restore-Vorgang klappt nur wenn:
Der Host die selbe Version hat, wie das Backup (z.B. v7.0.3)
Der Host im Wartungsmodus ist
Das Management-Network erreichbar ist
Dann geht das schnell und einfach:
SSH einschalten
Via SCP die Konfigurationdatei (configBundle-HOSTNAME.tgz) auf den Host nach /tmp/ hochladen
Die Konfigurationdatei umbenennen zu configBundle.tgz
Konfiguration widerherstellen
# Restore der Konfiguration starten
vim-cmd hostsvc/firmware/restore_config 0
Der Host bootet nach dem Restore SOFORT neu. Aber nach dem Neustart ist fdann auch schon alles sofort wieder „wie vorher“.
Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].
Lösung
Der Fehlercode 0x8004231f steht für „VSS_E_INSUFFICIENT_STORAGE“ oder auch „nicht genügend Speicherplatz für die Schattenkopie“. Die Festplatte ist voll.
Schattenspeicherplatz wird für die Systemwiederherstellungspunkte von Veeam Backup & Recovery verwendet, wenn „Appication Image Aware Processing“ eingeschaltet ist (was auch empfohne ist).
Der Fehler tritt auf wenn die Festplatte tatsächlich voll ist. Das kann zum Beispiel ungewollt passieren, wenn man der 100Mbyte großen Windows „EFI-Systempartition“ oder der (möglicherweise eingerichteten) „Widerherstellungspartition“ einen Laufwerksbuchstaben gegeben hat. Naturgemäß haben diese Partitionen praktisch keinen freien Speicherplatz. „Voll“ bedeutet hier, „nicht genug Platz für eine Volumenschattenkopie“. Bei Maschinen mit viel Arbeitsspeicherbedarf, zum Beispiel ERP-Systeme oder SQL-Server, kann das plötzlich sehr viel sein. Wir haben einen SQL-Server VSS Dump „mal eben“ 20Gbyte schreiben sehen.
Das Upgrade auf vCenter 8.0 bleibt manchmal „kommentarlos“ bei 80% stehen und bewegt sich nicht mehr. Auch nach einiger Zeit nicht. Die neue Appliance wurde aber erfolgreich installiert und botet (scheinbar) auch fehlerfrei.
„Waiting for RPM installation to start. This may take several minutes“ 80%
Man kann die neue virtuelle vCenter-Appliance aber im Inventar sehen, pingen und auch die Konsole öffnen.
Lösung
Was die Ursache für diesen Effekt ist, wissen wir auch nicht genau. Aber man kann die Installation und Datenmigration problemlos über die VCSA-Oberfläche der „neuen“ vCenter-Instanz fortsetzen. Man öffne:
https://<temporäre-vcenter-adresse>:5480
und melde sich mit dem „frisch „alten“ root-Kennwort dort an.
Die zugehörige (temporär) IP-Adresse zeigt die Konsole ja an.
Der vCenter Screen zeigt die Appliance-IP
Wenn man dem Assistent dann dort weiter folgt, läuft das Setup (in aller Regel) problemlos durch.
