Diese Artikelserie befasst sich mit Linux-Kommandos, die den Zugriff auf Inhalte von Image-Files für virtuelle vmdk-Disks erlauben. Den Lesern meines letzten Artikels zum Kommando “vmware-mount”
Mounten eines vmdk Laufwerks im Linux Host – I – vmware-mount
möchte ich in diesem Artikel ein paar Links zur vmdk-Spezifikation nachreichen. Dabei wird einerseits nochmals die Komplexität des vmdk-Formats deutlich, mit denen Linux-Tools sich auseinandersetzen müssen. Andererseits möchte ich im Vorgriff auf weitere Artikel ein paar Begrifflichkeiten glattziehen und die Nomenklatur von “sprechenden” Zusätzen in vmdk-Datei-Namen erläutern. Dieser Einschub war nicht geplant; er erschien mir aber u.a. sinnvoll, um zu verdeutlichen, warum bestimmte Linux-Tools, mit denen wir uns noch beschäftigen werden, ernsthafte Problem mit bestimmten vmdk-Varianten haben.
vmdk-Spezifikationen
Das vmdk-Format ist ziemlich komplex und hat sich im Lauf der Zeit auch mehrfach geändert. Das Format nimmt auf unterschiedliche Bedürfnisse Rücksicht, die im Zusammenhang mit Virtualisierung und zugehörigen Image-Files für virtuelle Disks auf Virtualisierungshosts auftreten. Zu nennen sind diesbzgl.: Platzbedarf versus Performance; Zustandssicherung von virtuellen Maschinen durch Snapshots und zugehörige Delta-Informationen; unterschiedliche Lagerstätten von vmdk_Files im Verzeichnisbaum.
Den aktuellen Stand spiegeln Informationen unter folgenden Links wieder:
vmdk-spec-in-ascii-doc-format
VMware PDF zu Virtual Disk Format 5.0
https://www.vmware.com/app/vmdk/?src=vmdk
ttgtmedia-PDF zum Umgang mit vmdk
Einige weitere interessante Infos liefert auch die API-Beschreibung für Entwickler:
https://vdc-download.vmware.com/vmwb-repository/dcr-public/ae1a858c-2f59-4a75-b333-f2ddfa631fbd/4ae542fa-c7ec-4713-a3a0-6fef938b03d1/vddk60_programming.pdf
Ich kann euch das Lesen nicht abnehmen, nachfolgend gehe ich aber auf Punkte ein, die die Vielzahl und die unterschiedlichen Bezeichnungen von vmdk-Dateien, deren Anzahl sich unter bestimmten Voraussetzungen im Lauf der Zeit beträchtlich erhöhen kann, erklären.
Vielfalt – schon bei einer einzelnen virtuellen Maschine
Im Hauptverzeichnis zu einer meiner virtuellen Testmaschinen finden sich etwa folgende vmdk-Dateien:
mytux:/vmw/WinTest # ls | grep vmdk Win7_x64-cl1-000001-s001.vmdk Win7_x64-cl1-000001-s002.vmdk ... Win7_x64-cl1-000001-s016.vmdk Win7_x64-cl1-000001-s017.vmdk Win7_x64-cl1-000001.vmdk Win7_x64-cl1-000002-s001.vmdk Win7_x64-cl1-000002-s002.vmdk ... Win7_x64-cl1-000002-s016.vmdk Win7_x64-cl1-000002-s017.vmdk Win7_x64-cl1-000002.vmdk Win7_x64-cl1-000003-s001.vmdk Win7_x64-cl1-000003-s002.vmdk ... Win7_x64-cl1-000003-s016.vmdk Win7_x64-cl1-000003-s017.vmdk Win7_x64-cl1-000003.vmdk Win7_x64-cl1-000004-s001.vmdk Win7_x64-cl1-000004-s002.vmdk ... Win7_x64-cl1-000004-s016.vmdk Win7_x64-cl1-000004-s017.vmdk Win7_x64-cl1-000004.vmdk Win7_x64-cl1-s001.vmdk Win7_x64-cl1-s002.vmdk ... Win7_x64-cl1-s016.vmdk Win7_x64-cl1-s017.vmdk Win7_x64-cl1-s018.vmdk Win7_x64-cl1.vmdk Win7_x64_ssd_ex-000001. vmdk Win7_x64_ssd_ex-000002.vmdk Win7_x64_ssd_ex-000003.vmdk Win7_x64_ssdx-000001-s001.vmdk Win7_x64_ssdx-000001-s002.vmdk Win7_x64_ssdx-000001.vmdk Win7_x64_ssdx-000002-s001.vmdk Win7_x64_ssdx-000002-s002.vmdk Win7_x64_ssdx-000002.vmdk
Das ist schon eine erstaunliche Vielfalt; dabei habe ich in der Liste bereits viele Dateien (u.a. sog. Extents mit Namenszusätzen “s003” bis “s015”) ausgeblendet. Um die Lage noch zu verkomplizieren, liegen einige Basisdateien zu Testzwecken auch noch in in einem anderen Verzeichnis (nämlich /vmw/Win7).
Hinweis: VMware legt Snapshots defaultmäßig immer im Verzeichnis der virtuellen Maschine an; die Ursprungsdateien für Disk-Images können sich jedoch an anderer Stelle im Verzeichnisbaum befinden.
Hinweise und ein paar Zitate aus der Spezifikation
Die ersten drei der oben genannten Dokumente legen u.a. fest, dass die reinen vmdk-Dateien, also diejenigen ohne “-snnn”-Anteil im Namen, sogenannte “Deskriptor”-Dateien sind. Meine Leser kennen den Begriff schon vom vorhergehenden Artikel. Auch das nächste Zitat belegt (bis auf den letzten Satz) einige Punkte, die ich bereits früher angedeutet hatte:
“VMware virtual disks can be described at a high level by looking at two key characteristics:
* The virtual disk may use backing storage contained in a single file, or it may use storage that consists of a collection of smaller files.
* All of the disk space needed for a virtual disk’s files may be allocated at the time the virtual disk is created, or the virtual disk may start small and grow as needed to accommodate new data.
A particular virtual disk may have any combination of these two characteristics.
One characteristic of recent ‐ generation VMware virtual disks is that a text descriptor describes the layout of the data in the virtual disk. This descriptor may be saved as a separate file or may be embedded in a file that is part of a virtual disk.”
Ich nenne in dieser Artikelserie ein Disk-Image, das sich über mehrere Dateien erstreckt, auch einen “Container“. In der Reihe der Dateien, die gemäß vmdk-Spezifikation zu einem Container gehören, ist zu unterscheiden zwischen
- der Deskriptor-Datei
- den durchnummerierten “Extent”-Dateien.
Das erste Extent-File bezeichne ich auch als “Base-File” (nicht zu verwechseln mit der “Base-Disk”; s.u.)
Das vierte der oben per Link angegebenen Dokumente weist dabei auf Folgendes hin (eine noch präzisere Info zu den verschiedenen Erscheinungsformen von vmdk-Disk-Images liefert die API-Doku):
“The VMDK file can have four different forms. Type 0 (monolithic sparse disk), Type 1 (growable; split into 2GB files), Type 2 (single pre-allocated; monolithic sparse disk), and Type 3 (pre-allocated; split into 2GB files). Types 1, 2, and 3 use a disk descriptor file, while type 0 does not.
To make changes to the VMDK file, you need to be able to open and view the disk descriptor; otherwise, with the type 0 single disk, you would need to edit a very large binary file with a hex editor – an unwise choice. A better option, if you have the VMDK file on a VMFS file system, is to use vmkfstools to easily export the file in a Type 3 format.”
Hinweis:
Obwohl hier 2GB als Standardgröße der Extension-Files einer “growable, sparse Disk” angegeben werden, werden u.a. von der VMware-Workstation unter Linux inzwischen standardmäßig 4GB große Dateien für Extent-Dateien erzeugt.
Die Komplexität wird durch Snapshots noch weiter gesteigert: Die die
vmdk-Spezifikation erklärt Snapshots über Dateien (“Links”) in einer Link-Kette, bei der Delta-Files auf logisch vorhergehende Delta-Files und zuletzt auf Files der ursprüngliche “Base”-Disk verweisen – und zwar nach folgendem Muster:
Delta-Dateien zu Snapshot N => Delta-Dateien zu Snapshot N-1 => … => Delta-Dateien zu Snapshot 1 => Dateien der Base-Disk
Eine Base-Disk kann als “growable Disk” angelegt worden sein. Sie und auch zugehörige Snapshots weisen dann ein Base-File und weitere Extents auf – in den Snapshots sind die jeweiligen Dateien dann aber nur mit Delta-Informationen zum jeweiligen Extent gefüllt.
Wie schlägt sich die Komplexität in den Namens-Zusätzen der vmdk-Files nieder?
Eine interessante Frage, mit der man sich ggf. auseinandersetzen muss, ist, wie sich die mögliche Struktur in der Namensgebung von vmdk-Dateien widerspiegelt. Dazu gibt es – zumindest bzgl. der VMware Workstation – vier Regeln:
- Eine Datei, die durch Clonen einer Maschine mit VMware-Tools entstanden ist, erhält einen Zusatz “-clN”. N steht dabei für die Nummer des Clones.
- Ein Snapshot, der mit VMware-Tools angelegt wurde, erhält einen Zusatz in Form einer 6-stelligen Nummer, z.B. “-000024”. Im Beispiel wäre das der 24-te Snapshot.
- Eine Deskriptor-Datei enthält außer dem Clone- und dem Snapshot-Zusatz keine weiteren Zusätze im Namen.
- Eine neue Extend-Datei erhält in aufsteigender Nummerierung einen Zusatz “-sNNN”; dabei steht “NNN” für eine dreistellige Zahl – z.B. “-s017”. Das Beispiel würde das File für den 17-ten Extent markieren. Ein erster Extent (“-s001”) wird bei einer growable sparse Disk immer angelegt; das zugehörige File ist das von mir als solches bezeichnete Base-File.
Dabei gilt nicht zwingend, dass die Snapshot-Nummer für alle Disk-Images einer virtuellen Maschine immer gleich sein muss. Eine Disk könnte der Maschine ja z.B. erst nach dem Snapshot 43 hinzugefügt worden sein. Pro Disk wird ab dem ersten zugehörigen Snapshot-Event hochnummeriert: Die Dateien zur neuen Disk erhalten dann beim zweiten nachfolgenden Snapshot “-000002” als Zusatz, während bei älteren Disks der Zähler schon auf “-000045” steht.
Blick auf eine Deskriptor-Datei
Nun könnten wir uns ja einfach mal eine Descriptor-Datei ansehen. Aber Vorsicht bei “monolithic sparse disks” (Typ 0)! Die Shell (cat-Kommando) und viele einfache Editoren sind keine Hex-Editoren! “Typ 0” ist aber gerade für unsere Test-Disk, die durch “/vmw/WinTest/Win7_x64_ssd_ex-000003.vmdk” beschrieben wird, gegeben. Problemfreier sollte sich die Deskriptor-Datei dagegen für eine andere zweite vmdk-Disk, die als Container mit 2 “sparse extends” (Typ 1) angeboten wird, auslesen lassen. Probieren wir das mal mit dem Deskriptor File “Win7_x64_ssdx-000002.vmdk” des für diese Disk vorliegenden zweiten Snapshots aus:
mytux:/vmw/Win7Test # cat Win7_x64_ssdx-000002.vmdk # Disk DescriptorFile version=1 encoding="UTF-8" CID=a3a5e6df parentCID=d135caf6 createType="twoGbMaxExtentSparse" parentFileNameHint="Win7_x64_ssdx-000001.vmdk" # Extent description RW 8323072 SPARSE "Win7_x64_ssdx-000002-s001.vmdk" RW 65536 SPARSE "Win7_x64_ssdx-000002-s002.vmdk" # The Disk Data Base #DDB mytux:/vmw/Win7Test # cat Win7_x64_ssdx-000001.vmdk # Disk DescriptorFile version=1 encoding="UTF-8" CID=d135caf6 parentCID=b665cd6b createType="twoGbMaxExtentSparse" parentFileNameHint="/vmw/Win7/Win7_x64_ssdx.vmdk" # Extent description RW 8323072 SPARSE "Win7_x64_ ssdx-000001-s001.vmdk" RW 65536 SPARSE "Win7_x64_ssdx-000001-s002.vmdk" # The Disk Data Base #DDB ddb.longContentID = "d10b249e54a5cd42df5ab314d135caf6" mytux:/vmwssd_w7prod/Win7_x64 #
Was lernen wir?
- In der Deskriptor-Datei sind keine Informationen enthalten, die die Partitionsstruktur der Disk-Images offenbaren würden.
- Die Extents sind als wachsende “sparse”-Dateien konfiguriert.
- Die Verlinkung erfolgt über CIDs und Pfadangaben.
- Die Base-Disk wurde im vorliegenden Fall in einem anderen Verzeichnis definiert als dem der virtuellen Maschine.
Interne Daten-Adressierung und Partitionsinformation
Die vmdk-Spezifikation beschreibt relativ detailliert, wie die die Block-Adressierung der wachsenden Daten systematisch über zugehörige Informationen
- in Headern von Extent-Files,
- in einem sog. Grain-Directory des Extents
- und zugehörigen Grain-Tabellen mit Einträgen zu Offsets für konkret definierte “Grains” (Block of Sectors, GrainSize*SectorSize, z.B. 128 * 512 = 64KB)
realisiert und gesteuert wird. Ferner gilt, dass die Deskriptor-Information in Extent Files selbst enthalten sein kann.
Die Partitionsinformation liegt bei einer normalen Platte in der Partitionstabelle (MBR, GPT-Format). Diese befindet sich ziemlich am Anfang einer Platte. Daraus folgern wir, dass dem Erkennen des Basis-Files eines “sparse/growable”-Disk-Images und der Analyse dieses Files (neben der Deskriptor-Datei) große Bedeutung zukommt.
Runterbrechen auf ein Flat- oder Raw-File?
Der Einsatz von Loop-Devices unter Linux für den Zugriff auf Partitionen, die in Disk-Images verborgen werden, erfordert ein spezielles “flaches” Format einer zusammenhängenden Datei. Letztere wird manchmal als “raw”- oder “flat”-File bezeichnet.
Da vmdk-Disks wegen Snapshots und Extents vielfach in Einzeldateien gesplittet und letztere wiederum untereinander verlinkt sind, muss ein solches zusammenhängendes “raw”-File erstmal durch Analyse der Dateibeziehungen, der Adressierung von virtuellen Datenblöcken innerhalb einer Datei und durch Auswertung von Delta-Informationen erzeugt werden.
Das erledigen viele Tool-Entwickler, indem sie FUSE-Mechanismen nutzen.
Alternativ kann man (über FUSE) auch andere Schritte gehen – und das Filesystem direkt mit dem Host-Kernel oder dem zwischengeschobenen Kernel einer (verdeckten) virtuellen Maschine kommunizieren lassen (siehe hierzu etwa
http://libguestfs.org/guestfs-security.1.html. Generell ist übrigens zu sagen, dass das direkte Mounten eines Filesystems aus einer ggf. manipulierten virtuellen Maschine über Loop-Devices durchaus mit Gefahren verbunden sein kann.)
Da vmdk so komplex ist, wundert es nicht, dass etliche im Internet besprochene Linux-Tools wie affuse, vdfuse und z.T. auch vmdkmount in ihrem aktuellen Zustand an der korrekten Aufdröselung von Snapshots oder aber Extents scheitern. Zumindest nach meiner aktuellen Erfahrung.
Runterbrechen auf ein Block-Device?
Alternativ zu einem Flat-File kann ein Tool auch ein “künstliches” Block-Device für das Disk-Image bereitstellen. Dazu muss – ähnlich wie bei echten HW-Disk-Treibern – ein “künstliches” Device mit einem entsprechenden Block-Layer durch ein Kernel-Modul, das die korrekte Adressierung leistet, bereitgestellt und verwaltet werden.
Zusammenfassung / Ausblick
vmdk-Images sind komplex; sie
- vdmk-Disk-Images erlauben Snapshots – d.h. die Verlinkung von Delta-Files.
- Ein vdmk-Disk-Image kann als Container
angelegt werden, der sich über viele Einzeldateien (Extends) erstreckt. - Das Disk-Image kann so angelegt werden, dass die Zahl der Extents (und zugehöriger Dateien) im Lauf der Zeit bedarfsgerecht wächst. Jeder Extent wächst dabei dynamisch auf sein Limit an.
- Ein vdmk-Disk-Image kann alternativ als eine sukzessive wachsende Einzeldatei für ein Disk-Image angelegt werden.
- Ein vdmk-Disk-Image erlaubt eine einmalige, vollständige Platz-Allokierung für die gesamte Disk.
- Pro vdmk-Disk-Image sind mehrere Partitionen/Filesysteme erlaubt.
Davon treten ggf. mehrere Punkte in Kombination auf. Das stellt Linux-Tools u.a. vor das Problem, wie man interessierten Usern entweder
- eine flat- oder raw-Datei zur Verfügung stellen will, die der User dann selbst – z.B. über Loop-Devices – weiterverarbeitet,
- einen linux-fähigen Block-Layer über die vmdk-Adressierung legen,
- oder mittels FUSE gleich einen anderen, ggf. direkteren Zugang zu den enthaltenen Partitionen eines vmdk-Disk-Images liefert.
Im nächsten Artikel
Mounten eines vmdk-Laufwerks im Linux Host – III – qemu-nbd, loop-devices, kpartx
bespreche ich zunächst ein Linux-Tool, das den zweiten der genannten Wege einschlägt und dabei auch Snapshots und Extents beherrschen – nämlich qemu-nbd