Wie entfernt man eigentlich einen VMFS-Datastore von einem ESXi-Host und was kann man tun, wenn der ESXi-Host das Entfernen eines VMFS-Datastores zu verhindern scheint?

Möchte man in einer vSphere-Umgebung nicht mehr benötigte VMFS-Datastores unmounten und/oder ganz entfernen oder möchte man die Backend-seitigen LUNs hinter einem Datastore  reorganisieren oder löschen, was ebenfalls mit dem Löschen des Datastores einher geht, sind zuvor in der vSphere-Umgebungen folgende Punkte zu überprüfen:

• es dürfen keine VMs oder Templates auf dem Datastore liegen,
• der Datastore darf nicht mehr Mitglied eines Datastore Clusters sein
• der Datastore darf nicht von Storage DRS verwaltet werden,
• Der Datastore darf nicht für Datastore Heartbeats für vSphere HA verwendet werden
• Storage I/O-Control muss für diese Datastore deaktiviert sein.

Coredump-Partition

Trotzdem ist es manchmal nicht möglich, einen VMFS-Datastore erfolgreich zu entfernen. Man bekommt dann einer 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“.

Das wiederum kann mehrere Ursachen haben: es kann z. B.  daran liegen, dass der Datastore als “diagnostic coredump partition“ konfiguriert ist. Hierbei handelt es sich um ein mit ESXi 5.5 eingeführtes Feature, um Coredumps in einer Datei auf einem Datastore speichern zu können. In manchen Fällen wird eine solche Datei automatisch erzeugt, was verhindert, dass der Datastore entfernt werden kann.

Ob solche Dump-Files existieren, findet man schnell auf der Kommandozeile durch Eingabe von

esxcli system coredump file list

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

Zum Entfernern der coredump-Datei verbindet man sich per SSH mit diesem Host und löscht dann die Datei mit

esxcli system coredump file remove –force

Grundsätzlich deaktivierbar ist das Erstellen des Dumpfiles über den erweiterten Parameter „VMkernel.Boot.autoCreateDumpFile“.

oder auf der Kommandozeile mit …

esxcli system coredump file set –enable false

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 Host über keine lokale Festplatte verfügt – eine Solche würde sonst beim Installieren von ESXi vorzugsweise (und automatisch) als Scratch-Location konfiguriert -, z. B. wenn dieser sein System von einem USB-Stick oder aus dem Netzwerk (PXE/Auto Deploy, Boot-from-SAN) startet. Zu erkennen ist dies einerseits dadurch, dass im Datastore-Browser das Verzeichnis „.locker“ sichtbar ist und zum anderen dadurch, dass der erweiterte Parameter „ScratchConfig.ConfiguredScratchLocation“ auf dieses Verzeichnis zeigt. Dies erkennt man z. B. im Web-Client in den erweiterten Einstellungen für den Host, wenn man nach diesem Schlüssel sucht.

An dieser Stelle 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-Client auf einem anderem Datastore angelegt an. Die Änderungen erfordert allerdings einen Reboot des ESXI-Hosts. Die konfigurierte Scratch-Partition muss auf ein Verzeichnis in einem für den ESXi-Host zugänglichen Dateisystem verweisen, beispielsweise ein FAT16- oder VMFS-Volume. Der Speicherort kann ein Verzeichnis auf einer freigegebenen Festplatte oder einer Remote-Festplatte sein, solange man jedem ESXi-Host sein eigenes Verzeichnis zugeweist.

Man kann Scratch-Speicherplatz für den ESXi-Host auf die beschriebene Weise manuell, aber auch per vCLI oder PowerCLI, bzw.  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.

Danach ist ein Neustart des ESXi-Hosts erforderlich, damit die Änderungen wirksam werden. Wichtig ist, dass man kein Scratch-Verzeichnis für mehrere ESXi-Hosts gleichzeitig freigibt, d. h. jeder ESXi-Host muss wie oben erwähnt seinen eigener Ordner bekommen, wenn z. B. einen SAN-basierten VMFS-Datastore als Scratch-Partition verwendet, z. B. „.locker-esx1“, „.locker-esx2“ usw. . Nicht unterstützt wird die Konfiguration einer Scratch-Partition in einem VSAN-Datenspeicher.