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“.
Manchmal muss man Abhängikeiten von Windows-Diensten untereinander bearbeiten. Die Abhängigkeiten machen auch genau das was sie sagen: Dienste starten damit erst, wenn ein Anderer fertig ist.
Sinnvoll ist das zum Beispiel bei Lizenzdiensten die erst nach dem USB-Link starten sollen oder Middleware-Services erst nach einer Datenbank.
Lösung
An der guten alten CMD-Shell (als Administrator) lassen sich Abhängigkeiten schnell hinzufügen:
sc config <DIENST> depend=<ABHAENGIG VON ANDEREM DIENST>
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.
