VMFS-Datastore aus ESXi bzw. vSphere entfernen

Vor dem Entfernen von LUNs in vSphere-Umgebungen müssen unbedingt folgende Bedingung geprüft werden. Der Datastore darf

• keine VMs oder Templates enthalten,
• nicht mehr Mitglied eines Datastore-Clusters sein
• nicht von Storage DRS verwaltet werden,
• nicht Datastore für Heartbeats von HA verwendet werden
• Storage I/O Control muss für diese Datastore deaktiviert sein.

Trotzdem ist es manchmal nicht möglich, einen VMFS-Datastore erfolgreich zu löschen. Man bekommt dann eine Fehlermeldung der Art

The resource 'Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55' is in use. Cannot remove volume 'Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55' because "file system is busy". Correct the problem and retry the operation.

Coredump entfernen

Eine Ursache für dieses Verhalten kann darin liegen, dass der Datastore als Diagnostic Coredump Partition konfiguriert ist. Hierbei handelt es sich um ein mit ESXi 5.5 eingeführtes Feature, das dazu dient, Coredumps anstatt auf einer Scratch-Partition in einer Datei auf einem Datastore zu speichern. In manchen Fällen wird eine solche Datei automatisch erzeugt, was verhindert, dass sich der Datastore entfernen lässt.

Ob solche Dump-Files existieren, findet man auf der Kommando­zeile recht schnell durch Eingabe von

esxcli system coredump file list

heraus. In der Ausgabe erkennt man die UUID des ESXi-Hosts, der die Datei gesperrt hat. Der hintere Teil der UUID ist die MAC-Adresse von vmnic0, was eine eindeutige Identifikation des Hosts zulässt.

Eine Coredump-File kann "konfiguriert" und/oder "aktiv" sein. Ist es konfiguriert aber nicht aktiv, lässt es sich ohne Angabe des Filenamen mit der force-Option entfernen. Ist es aktiv, muss es mit set erst deaktiviert werden. Ist es weder konfiguriert noch aktiv, also ein Überbleibsel einer früheren Verwendung auf dieser LUN, muss der Filename beim entfernen mit remove explizit angebenen werden.

Zum Löschen der coredump-Datei verbindet man sich per SSH mit diesem Host und gibt im Fall einer nicht aktiven Coredump-Datei folgenden Befehl ein:

esxcli system coredump file remove -force

Scratch-Partition

Es kann aber auch durchaus sein, dass der betreffende VMFS-Datastore von einem oder mehreren ESXi-Hosts als Scratch-File-Location verwendet wird. Dies ist insbesondere dann wahrscheinlich, wenn der ESXi-Server über keine lokale Festplatte verfügt. In diesem Fall startet der Server den Hypervisor von einem USB-Stick oder aus dem Netzwerk (PXE/Auto Deploy, Boot-from-SAN).

Zu erkennen ist die Nutzung als Scratch-Location einerseits dadurch, dass im Datastore-Browser das Verzeichnis mit dem Namen .locker existiert und zum anderen, dass der erweiterte Parameter

ScratchConfig.ConfiguredScratchLocation

auf dieses Verzeichnis zeigt. Diesen findet man im Web-Client in den erwei­terten Einstellungen für den Host, wenn man nach diesem Schlüssel sucht.

Hier lässt sich der gewünschte Pfad auch gleich ändern, sofern man vorher das Verzeichnis .locker auf der Kommandozeile, im Datastore-Browser oder mit Hilfe eines SCP/SFTP-Clients auf einem anderen Datastore angelegt hat.

Man kann Scratch-Speicherplatz für den ESXi-Host aber nicht nur manuell, sondern auch per vCLI, PowerCLI oder im Verlauf einer skriptbasierten Installation konfigurieren. Unabhängig von der gewählten Methode schreibt ESXi die Konfiguration zur Verwendung beim nächsten Startvorgang in die Konfigurationsdatei /etc/vmware/locker.conf.

Die konfigurierte Scratch-Partition muss auf ein Verzeichnis in einem Dateisystem verweisen, das für den ESXi-Host zugänglich ist, beispielsweise ein Fat16- oder VMFS-Volume. Der Speicherort kann auf einer freigegebenen Festplatte oder einer Remote-Festplatte liegen. Nicht unterstützt wird die Konfiguration einer Scratch-Partition auf einem vSAN-Datenspeicher.

Wichtig ist dabei, dass man kein Scratch-Verzeichnis für mehrere ESXi-Hosts gleichzeitig freigibt, d. h. jeder ESXi-Host muss seinen eigener Ordner (zum Beispiel .locker-esx1, .locker-esx2, usw.) bekommen, wenn man etwa einen SAN-basierten VMFS-Datastore als Scratch-Partition verwendet. Damit die Änderungen wirksam werden, ist ein Neustart des ESXi-Hosts erforderlich.