Manchmal kommt es vor, dass in dem VMFS sogenannte Zombie-Files liegen, die nicht von einer VM verwendet werden.
Dies können VMDK-Dateien sein, die nicht einer VM zugeordnet sind. Ebenso dazugehörige CTK-Files (Change Block Tracking Dateien) und Snapshotdateien die über die Konsolidierung nicht aufgelöst werden können.
Um diese Dateien zu prüfen, dass diese wirklich nicht mehr registriert sind, habe ich hier eine mögliche Vorgehensweise beschrieben.
Nach der Prüfung, können die Files verschoben oder gelöscht werden, wenn die Daten nicht mehr benötigt werden.

1. Anmelden am ESXi Server auf dem die entsprechende VM registriert ist. Anmelden via CLI (z.B. Putty).
   
   
2. Nun können wir uns z.B. alle vmdk Dateien mit einem Snapshot anzeigen lassen, die in der LUN liegen:
   find /vmfs/volumes/ -name *-0000*
   
   
   wird in eine LUN gewechselt, um nur den entsprechenden Inhalt der LUN anzuzeigen, muß die LUN mit der UUID angegeben werden.
   eine Übersicht der LUNs auf dem ESXi kann mit folgendem Befehl abgefragt werden:
   esxcli storage filesystem list
   
   
3. Um zu sehen, dass der Server auf dem ESXi registriert ist, mit dem wir per CLI verbunden sind, folgenden Befehl eingeben:
   esxcli vm process list | grep <Servername>
   
   
   Ebenso wird mit diesem Befehl das zugehörige Config File (vmx) ausgegeben.
   
   
4. Jetzt müssen wir prüfen, welche VMDK Files in der VM registriert sind. Diese Informationen stehen in dem .vmx File.
   Hierzu in das Verzeichnis der VM wechseln und mit folgendem Befehl den Inhalt des VMX-File anzeigen lassen in Bezug auf die verwendeten VMDK-Files:
   cat <Servername>.vmx | grep vmdk
   
   
5. Um zu prüfen, welche Verlinkungen in den VMDK-Dateien enthalten sind, kann folgender Befehl verwendet werden:
   cat <vmdkname>.vmdk
   
   Wir benötigen 3 Informationen aus der VMDK:
   - Vorhandener Snapshot
   - Extent description
   - Change Tracking File
   
   
6. Prüfen ob auf einem File ein Lock vorhanden ist (File in Benutzung von einem ESXi oder aktiver I/O vorhanden).
   Bei folgenden Files kann dies der Fall sein:
   - Flat File (Datenfile der vmdk)
   - Delta File (Datenfile Snapshot)
   - Ctk-File (Datenfile Change Block Tracking)
   vmkfstools -D <Filename>-flat.vmdk
   
   ist die "owner" MAC-Adresse auf 0, ist das File nicht durch einen ESXi in Benutzung. Sonst würde die MAC-Adresse des entsprechenden ESXi angezeigt werden.
   in unserem Fall liegt auf dem File kein Lock.
   
   Der "mode" gibt an um welchen Lock es sich handelt:
   - mode 0 = kein Lock
   - mode 1 = ist ein exclusiver Lock (z.B. vmx File von einer eingeschalteten VM)
   - mode 2 = ist ein Read-Only Lock (z.B.  auf einer -flat.vmdk von einer laufenden VM mit snapshot)
   - mode 3 = ist ein multi-writer Lock (z.B. FT VM)
   
   Um zu prüfen welcher Prozess für den Lock verantwortlich ist folgenden Befehl eingeben:
   lsof |grep /vmfs/volumes/LUN/VM/disk-flat.vmdk
   
   Wenn immer noch ein Lock vorhanden ist, der auf die Netzwerkkarte verweist, auch eventuell an die Backupsoftware denken.
   
   
7. Als nächstes Prüfen wir, wann der letzte I/O auf dem File stattgefunden hat (wir befinden uns immer noch im Verzeichnis der VM):
   ls -ltr | grep vmdk
   oder eine genaue Ausgabe von Access/Modify/Change
   stat <Filename>.vmdk
   
   Achtung: Die Zeitangabe auf dem ESXi ist immer UTC.

Wenn wir alle Schritte durchgearbeitet haben und es besteht keine Beziehung mehr zu einem ESXi oder Dienst bei dem entsprechenden VMDK-File, können wir das File in einen anderen Ordner verschieben zur Archivierung. Wenn die Daten nicht mehr benötigt werden, kann die Datei im Anschluß gelöscht werden.

Perfekt. Wieder etwas Platz geschaffen auf dem SAN.

{jcomments on}