Manchmal muss man sich auf einem Linux-Virtualisierungs-Host direkt – d.h. ohne Umweg über virtualisierte Gastsysteme – mit dem Inhalt von “vmdk”-Dateien auseinandersetzen. Ich stelle in diesem und nachfolgenden Beiträgen ein paar einfache Möglichkeiten vor, die ich selbst immer mal zum Mounten von Filesystemen, die sich innerhalb von vmdk-Dateien befinden, in den Verzeichnisbaum meiner Linux-Workstations benutze. Als Beispiele müssen dabei NTFS-Testpartitionen einer vmdk-Disk herhalten, die einer virtuellen Maschine mit Win7 zugeordnet wurden.
Szenarien für den direkten Zugriff unter Linux?
“vmdk”-Dateien dienen unter Linux primär dazu, VMware-Gastsysteme – aber z.B. auch Virtualbox- und qemu-Gastsysteme – mit einem virtuellen “Festplatten”-Unterbau auszustatten. Ich spreche nachfolgend daher auch von “vmdk-Disks“. Ein allgemeiner Begriff, der das Prinzip von virtuellen Disks in Form von Dateien umschreibt, ist der eines Disk-Images.
Eine vmdk-Disk kann wie eine echte Platte auch Filesysteme (wie Ext4, NTFS oder BrtFS) aufnehmen. Unter KVM korrespondieren zu “vmdk” etwa “qcow2”-Dateien. Die Nutzung von Linux-Dateien als Container für Filesysteme bringt beim Virtualisieren einige Vorteile mit sich: u.a. kann man die virtuellen Platten relativ problemlos zwischen Hosts hin- und her bewegen. Natürlich lässt sich auch die Durchführung von Backups für “vmdk”-Dateien besonders einfach mit Linux-Bordmitteln durchführen.
Nun könnte man sagen, dass man auf die über “vmdk” bereitgestellten Filesysteme ja immer über die virtuelle VMware-Gast-Maschine selbst zugreifen kann. Das stimmt so nicht uneingeschränkt: Bisweilen muss man etwa die Pflege des/der auf der vmdk-Datei installierten Filesystems/e über Tools des Hosts betreiben. In anderen Fällen ist eine Bereinigung von eingefangenen Viren auf einem NTFS-Filesystem nötig, ohne dass das betroffene Gast-System gebootet werden soll. Ein anderes wichtiges Szenario ist die forensische Analyse von Inhalten der virtuellen Maschine – z.B. eines kompromittierten Windows-Gastsystems – durch Linux-Tools. Für letzteres reicht oftmals der lesende Zugriff. Weitere Anwendungsfälle sind logischerweise auch Pen-Tests (oder Hacker-Angriffe), bei denen der “Angreifer” von einem (teil-)eroberten Virtualisierungshost aus die Extraktion von Daten aus dort vorhandenen vmdk-Dateien virtueller Maschinen anstrebt.
Toolunterstützung unter Linux?
Die Spezifikation zu “vmdk” ist seit einiger Zeit offen; man erwartet daher, dass der Zugriff auf Inhalte von vmdk-Dateien (bzw. -“Laufwerken”) unter Linux gut unterstützt wird. Unterstützung bedeutet für mich dabei primär die Erfüllung zweier Anforderungen:
- Der Inhalt von “vmdk”-Disks sollte sich für den berechtigten User nach ein paar Schritten so darstellen, als gebe es dort (ggf. mehrere) Partitionen mit je einem unter Linux handhabbaren Filesystem (wie etwa NTFS von MS).
- Unter diesen Filesystemen muss man dann eines auswählen und – wie von echten Festplatten gewohnt – mounten können.
Für den Anwender ist der Einsatz entsprechender Tools unter Linux unterschiedlich komfortabel: Einige Tools führen alle notwendigen Schritte inkl. des Mountens für den User bequem in einem Rutsch durch; besonders nachvollziehbar ist das Vorgehen hinter den Kulissen des/der jeweiligen Kommandos dann aber nicht. Dies gilt im Besonderen für die Behandlung sog. vmdk-Container.
FUSE, Loop Devices – Komplexität durch Snapshots, “sparse vmdk-Container” mit mehreren “Extension Files” und mit mehreren internen Partitionen/Filesystemen
Es gibt vier Hindernisse, die Entwicklern von vmdk-Tools überwinden müssen:
- Sparse-vmdk: Spezielle Schwierigkeiten bei der Analyse der in vmdk-Disks
verborgenen Filesysteme bereitet u.a. die Tatsache, dass eine einzelne vmdk-“Disk” oftmals in Form eines Containers daherkommt, der sich über mehrere vmdk-Dateien (jedes davon z.B. mit einer Größe von 4GB) erstreckt.
Man spricht hier von “growable split and sparse file vmdk“; die “virtuelle” Platte wächst auf dem Host durch immer neu angelegte 2GB oder 4GB große Extents erst im Lauf der Zeit auf die Gesamtgröße an. Auch jedes einzelne neue Extension File selbst wächst dabei bedarfsgerecht an.
Es gibt dann eine “führende”, beschreibende vmdk-Datei – etwa mydisk.vmdk – und etliche weitere Extension-Dateien mit der Endung “-sNNN” – also z.B. “mydisk-sNNN.vmdk“; “NNN” steht dabei für eine dreistellige Nummer. Die führende Datei nennt man auch Deskriptor-Datei (s. hierzu den nächsten kommenden Artikel). - Mehrere Partitionen auf einer Disk: In beiden Fällen (sparse und flat) kommt hinzu, dass eine vmdk-Disk mehrere Partitionen beinhalten kann.
- Loop-Devices und Offsets: Hat man die Partitionen in einer vmdk-Disk erstmal erkannt, muss man entsprechende Linux-“Devices” für den Zugriff als Blockdevice definieren. Dabei muss man sich natürlich auch um den sog. “Offset” einer spezifischen Partition relativ zum Anfang der beherbergenden Disk-Datei(en) kümmern.
- Snapshots: Weiter verkompliziert wird die Handhabung für den Nutzer noch dadurch, dass man unter VMware Snapshots einer virtuellen Maschine anlegen kann. Solche Snapshots äußern sich in weiteren Zusätzen der vmdk-Dateien; z.B. mydisk-000001-s001.vmdk. Man muss also unter der Menge vorhandene vmdk-Disk-Dateien geeignete Snapshot-Dateien auswählen (z.B. mydisk-000001.vmdk). Dabei können die führende Snapshot-Datei und die ehemals führende Datei (die auch der Snapshot mitnutzt) u.U. in verschiedenen Verzeichnissen liegen (s.u.). Noch weitere Namens-Zusätze unterscheiden übrigens ggf. Clones virtueller Maschinen.
Ergänzende Hinweise (im nächsten Artikel liefere ich dazu auch Links):
Zu einer “growable split and sparse Disk” (Container) gibt es auch die Variante, dass zwar über mehrere Files hinweg gesplittet wird, aber der gesamte Plattenplatz von vornherein allokiert wird. Die erste Extent-Datei nennt man auch “Base-File” des vmdk-Disk-Images.
Das Gegenteil zu einer Sparse Disk, die über viele Extension Files verteilt ist, ist das sog. “monolithic file vmdk“; dabei wird von Anfang an nur genau eine vmdk-Datei für die angestrebte virtuellen Platte angelegt. Das bringt neben strukturellen Unterschieden u.a. geringfügige Performance-Vorteile. Aber auch hier gibt es wieder zwei Möglichkeiten: Die Datei kann von vornherein den gesamten Platz der virtuellen Disk allokieren, oder sie kann langsam wachsen. In letzterem Fall spricht man auch von einer “Monolithic Sparse Disk”.
Bei aktuellen Linux-Werkzeugen zu vmdk führt der Weg zur Lösung der oben genannten Probleme intern regelmäßig über die Nutzung von FUSE und Loop-Devices. Letztere werden manchmal auch Loopback-Devices genannt; sie sind aber nicht mit dem gleichnamigen Netzwerk-Device “lo” zu verwechseln. Siehe zu Loop-Devices etwa
Wikipedia-Artikel zu Loop-Devices;
OSDevv.org zu Loopback-Device;
http://www.tldp.org/HOWTO/archived/Loopback-Root-FS/Loopback-Root-FS-2.html.
In “vmdk”-Containern mit einer Vielzahl von sparse vmdk-Dateien, aber auch in wachsenden monolithischen vmdk-Dateien ist die Adressierung von Sektoren
und Daten-Blöcke unterschiedlicher Partitionen verständlicherweise kompliziert. Auf solche vmdk-Disk-Images kann man unter Linux deshalb weder fdisk noch kpartx direkt loslassen. Leider. Aber kleine Umwege mit linux-eigenen Zusatztools führen auch dann zum Ziel – selbst wenn man nicht das nachfolgend besprochene Tool von VMware einsetzen will.
Zugriff mit dem VMware-Tool “vmware-mount”
Hat man die VMware-Workstation für Linux lizenziert, finden sich nach der Installation unter “/usr/bin/” eine Reihe von Kommando-Tools vor, die mit “vmware-” beginnen.
mytux:~ # vmware vmware vmware-installer vmware-ping vmware-authd vmware-license-check.sh vmware-tray vmware-authdlauncher vmware-license-enter.sh vmware-usbarbitrator vmware-collect-host-support-info vmware-modconfig vmware-vdiskmanager vmware-fuseUI vmware-mount vmware-vim-cmd vmware-gksu vmware-netcfg vmware-vprobe vmware-hostd
Die meisten dieser Kommandos haben eine Option “help”, die Informationen liefert. “man”-Seiten gibt es leider nicht.
Für uns relevant ist im aktuellen Kontext “vmware-mount“. Dieses nützliche CLI-Werkzeug ist auch Teil des VMware VDDK (s. folgenden Link vddk/; das VDDK wird unabhängig von der VMware WS angeboten und enthält auch Tools für den Remote-Zugriff auf Virtual Disks eines VMware ESX-Servers).
“vmware-mount help” zeigt die nötigsten Infos und Optionen zum Kommando an:
mytux:~ # vmware-mount help
VMware DiskMount Utility version 6.5.0, build-7528167
Usage: vmware-mount diskPath [partition num] mountPoint
vmware-mount [option] [opt args]
There are two modes for mounting disks. If no option is
specified, we mount individual partitions from virtual disks
independently. The filesystem on the partition will be
accessible at the mount point specified.
The -f option mounts a flat representation of a disk on a
user-specified mount point. The user must explicitly unmount
the disk when finished. A disk may not be in both modes at once.
Options: -p <diskID> list all partitions on a disk
-l <diskID> list all mounted partitions on a disk
-L list all mounted disks
-d <mountPoint> cleanly unmount this partition
(closes disk if it is the last partition)
-f <diskPath> <mountPoint> mount a flat representation of the disk
at "mountPoint/flat."
-k <diskID> unmount all partitions and close disk
-K <diskID> force unmount all partitions and close disk
-x unmount all partitions and close all disks
-X force unmount all partitions and close all disks
-r mount the disk or partition read-only
-o comma-separated list of options to be passed
to the 'mount' when mounting a partition
Wissen muss man demnach noch, was eine sog. “
“In the following list of options,
Man kann diskIDs für vmdk-Files auf ESX-Servern einsetzen. Das interessiert uns hier nicht
weiter.
Auf lokalen Linux-Systemen entspricht eine diskID gerade einem Pfad (Path) zu einer führenden vmdk-Datei.
Identifikation von Partitionen mit vmware-mount
Probieren wir “vmware-mount” einfach mal lokal aus; auf meinem Testsystem liegt etwa unter “/vmw/Win7” eine Windows 7-Installation für VMware Workstation, die u.a. eine kleine vmdk-Disk namens “Win7_x64_ssd_ex.vmdk” mit einer NTFS-Partition für Testzwecke beherbergt. Um es einfach zu machen, besteht dieses Disk-Image nur aus genau einem vmdk-File (monolithic sparse disk). Es sind keine Extension Files vorgesehen; der Speicherplatz ist aber nicht vorallokiert. “vmware-mount” hat damit erwartungsgemäß keine Probleme:
mytux:/vmw # vmware-mount -p /vmw/Win7/Win7_x64_ssd_ex.vmdk/ Nr Start Size Type Id Sytem -- ---------- ---------- ---- -- ------------------------ 1 2048 12576768 BIOS 7 HPFS/NTFS
Es wird korrekterweise genau eine Partition mit NTFS erkannt (6GB; 512Byte Sektorgröße). Wären mehrere File-Systeme enthalten, würden die entsprechend aufgelistet werden (s.u.).
fdisk erkennt weder die Partitionen einer über genau ein File repräsentierten monolithischen vmdk-Disk noch die eines echten vmdk-Containers
“fdisk -l” erkennt im Gegensatz zu vmware-mount nur die Blockstruktur des Files als Ganzes, nicht aber dessen interne Filesystem-Struktur:
mytux:~ # fdisk -l /vmw/Win7/Win7_x64_ssd_ex.vmdk Disk /vmw/Win7/Win7_x64_ssd_ex.vmdk: 34.9 MiB, 36569088 bytes, 71424 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Das gilt, obwohl für meine spezielle Test-Disk nur genau ein (wachsendes) vmdk-File vorliegt:
mytux:~ # la /vmw/Win7/ | grep ex -rw-rw-rw- 1 myself users 36569088 Mar 23 18:03 Win7_x64_ssd_ex.vmdk
Nun umfasst meine virtuelle Maschine aber auch noch eine weitere Test-Disk, deren Container tatsächlich zwei unterschiedliche Files beinhaltet:
mytux:/vmw/Win7 # la | grep ssdx -rw------- 1 myself users 2344157184 Mar 27 19:38 Win7_x64_ssdx-s001.vmdk -rw------- 1 myself users 131072 Mar 27 19:37 Win7_x64_ssdx-s002.vmdk -rw------- 1 myself users 511 Mar 27 19:34 Win7_x64_ssdx.vmdk
Leider liefert fdisk auch für diesen Fall kein besseres Ergebnis:
mytux:/vmw/Win7 # fdisk -l Win7_x64_ssdx.vmdk fdisk: cannot open Win7_x64_ssdx.vmdk: Inappropriate ioctl for device mytux:/vmw/Win7 # fdisk -l Win7_x64_ssdx-s001.vmdk Disk Win7_x64_ssdx-s001.vmdk: 2.2 GiB, 2344157184 bytes, 4578432 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
Dagegen ermittelt vmware-mount auch für diesen komplexen vmdk-Container die richtige Filesystem-Information:
mytux:/vmw/Win7 # vmware-mount -p Win7_x64_ssdx.vmdk Nr Start Size Type Id Sytem -- ---------- ---------- ---- -- ------------------------ 1 2048 5310464 BIOS 7 HPFS/NTFS 2 5312512 3072000 BIOS 7 HPFS/NTFS
Aus diesem Grund vermutet man, dass vmware-mount intern zunächst einmal das hoch-spezifische vmdk-(Container)-Format in ein für Linux handhabbares “flat-file”-Format aufdröselt. Zur linux-konformen Handhabung der vmdk-Spezifikation wird dabei intern auf zeitgemäße FUSE-Mechanismen zurückgegriffen. Sagt zumindest eine Recherche zu unterschiedlichen FUSE-Formaten im Internet …
Mounten
Die allgemeine Form des “vmware-mount”-Kommandos ist:
myself@mytux:~> su -c 'vmware-mount /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt/vmdk/'
Zur Durchführung des Mounts braucht man root-Rechte. Im obigen Fall muss man also das root-Passwort kennen. Alternativ wechselt man gleich in eine root-Shell.
Wir sehen dann in meinem Testfall etwa folgende Inhalte:
myself@mytux:~> la /mnt/vmdk/ insgesamt 9 drwxrwxrwx 1 root root 4096 22. Mär 10:57 . drwxr-xr-x 5 root root 4096 20. Mär 18:36 .. drwxrwxrwx 1 root root 0 22. Mär 10:34 $RECYCLE.BIN drwxrwxrwx 1 root root 0 21. Mär 08:41 System Volume Information -rwxrwxrwx 1 root root 11 22. Mär 10:57 ufo1.txt drwxrwxrwx 1 root root 0 22. Mär 10:36 ufodir -rwxrwxrwx 1 root root 6 20. Mär 18:35 ufo.txt
Beispiele mit mehreren Partitionen innerhalb einer vmdk-Disk und mit mehreren vmdk-Files eines echten vmdk-Containers diskutiere ich weiter unten. Dabei läuft alles aber weitgehend analog zum eben erläuterten Beispiel ab.
Zwischenschritte von vmware-mount
vmware-mount nimmt uns freundlicherweise gleich mehrere Aktionen ab:
- Involvieren von “FUSE”-basierten Methoden zur Bereitstellung der “vmdk”-Disk als zusammenhängendes “flat“-File. Dieses (scheinbar) zusammenhängende File wird in einem temporären Verzeichnis unter “/run/vmware/fuse” bereitgestellt
/run/vmware/fuse/ID-Nummer/flat
Das Verzeichnis erhält eine ID-Nr, die die Disk identifiziert. Die ID wird als Hash generiert. - Anlegen eines Loop-Devices (hier: /dev/loop0) mit richtiger Offset-Positionierung (hier: 1048576).
- Mounten des Loop-Devices (hier /dev/loop0) auf dem Ziel-Mount-Punkt (hier: /mnt/vmdk); das geschieht wiederum mit Hilfe des Fuse-Plugins für ntfs-ng3
Mehr Information?
Ein paar weiterführende Informationen findet man für unser Testbeispiel durch folgende Kommandos:
mytux:~ # mount .... /dev/fuse on /run/vmware/fuse/13958668715283886016 type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other) /dev/loop0 on /mnt/vmdk type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) ... mytux:~ # losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO /dev/loop0 0 1048576 0 0 /run/vmware/fuse/13958668715283886016/flat 0 .... mytux:~ # cat /run/vmware/fuse/13958668715283886016.info .encoding = "UTF-8" backingPath = "/vmw_win7/Win7_x64_ssd_ex.vmdk" diskName = "/vmw_win7/Win7_x64_ssd_ex.vmdk" mountPath = "/run/vmware/fuse/13958668715283886016" refCount = "1" privateFlatFile = "TRUE" isRemote = "FALSE" openFlags = "0" readOnly = "FALSE" mountPath0 = "/mnt/vmdk" loopPath0 = "/dev/loop0"
Auf die Bestimmung des Offsets kommen wir weiter unten zurück.
Sicheres Unmounten
Hat man mittes vmware-mount einen schreibenden Zugriff realisiert, so ist schon allein wegen des umfangreichen Cachings auf einem Linux-Host ein sicheres Unmounten erforderlich: Dabei erfolgt vorab eine Synchronisation (Sync) von geänderten Daten vom Cache in das/die Container-File/s hinein. Das Unmounten erfordert die Angabe der Option “-d”:
mytux:~ # vmware-mount -d /mnt/vmdk/
Anzugeben ist dabei lediglich der Mount-Point.
Manchmal dauert der Unmount-Prozess wg. der Syncs zur Festplatte einen Tick.
Mounten als Flat File?
Die Option “-f” (s. oben) deutet an, dass “vmware-mount” dem Linux-User auch die Möglichkeit gibt, einen vmdk-Container einfach nur in ein zusammenhängendes “flat”-File umzuwandeln, das man dann selbst einer weiteren Behandlung zuführen kann:
mytux:~ # vmware-mount "-f" /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt mytux:~ # la /mnt total 6291456 -rw-rw-rw- 1 myself users 6442450944 Mar 23 18:03 flat mytux:~ # fdisk -l /mnt/flat Disk /mnt/flat: 6 GiB, 6442450944 bytes, 12582912 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x77138461 Device Boot Start End Sectors Size Id Type /mnt/flat1 2048 12578815 12576768 6G 7 HPFS/NTFS/exFAT
Wie man die in einem solchen “Flat”-File enthaltenen Filesysteme konkret über Loop-Devices nutzen kann, besprechen wir im übernächsten Artikel, in dem wir ein natives Linux-Tool für den Zugriff auf einen vmdk-Disk-Container benutzen werden.
Vorsicht mit Modifikationen und Rechten bei NTFS-Partitionen einer vmdk-Disk
Da wir gerade bei Rechten waren, ist eine Warnung bzgl. NTFS-Systemen in vmdk-Containern angebracht:
Die User und Rechte im virtualisierten Gastsystem (hier Win7) sind im Linux-Host nicht ohne weiteres bekannt. Bei der Anwendung von ntfs-3g müssen daher Standard-“Umsetzungen” von Linux-UIDs/GIDs auf Windows SIDs verwendet werden sowie Standard-ACL-Abbildungen erfolgen. Im Fall von “vmware-mount” bedeuten die intern gewählten Standard-Umsetzungen:
Warnung 1: Nach dem oben besprochenen Einsatz von vmware-mount erhält jeder Linux-User auf dem Linux-System Lese- und Schreibrechte – sowohl am Flat-File wie auch bzgl. des gemounteten Filesystems.
Das ist leider unabhängig von den (ursprünglichen) Linux-Rechten des Mount-Punktes (hier: /mnt/vmdk). Man probiere das selbst aus und lasse sich die Rechte vor und nach dem Mounten anzeigen. Das hat denn ggf. auch Konsequenzen im virtualisierten Windows-System:
Warnung 2: Evtl. manuell nach dem vmware-mount angelegte Dateien/Ordner auf dem NTFS-System gehören später unter dem virtualisierten Windows zwar den dortigen Administratoren – aber auch dort hat jeder Windows-User trotzdem Vollzugriff.
Diese Rechte-Situation zu ändern ist meines Wissens mit VMware-Tools alleine nicht möglich. Siehe zu einer feingranulareren, Nutzer-unterstüzten Abbildung aber:
Windows Partitionen einbinden mit NTFS-3G.
Read-Only-Mount
Im Zweifel ist es besser, auf Nummer sicher zu gehen und die Filesystem der virtuellen Disk-Images nur read-only zu mounten. Also (als root):
mytux:~ # vmware-mount -r /vmw/Win7/Win7_x64_ssd_ex.vmdk /mnt/vmdk/
Obwohl die Rechte danach immer noch identisch zum vorherigen rw-Mount angezeigt werden, sind faktisch keine Schreibzugriffe mehr möglich. das verhindert aber immer noch nicht den Diebstahl von Daten durch unbefugte Nutzer. In einem kommenden Artikel komme ich beim Zugriff auf “flat”-Files über Loop-Devices auf dieses Thema zurück.
2-te Partition einer Snapshot-vmdk-Disk mounten
Abschließend habe ich zu unserer Test-Disk mal drei Snapshots angelegt und sie zudem danach in zwei NTFS-Partitionen unterteilt. Dann ergibt sich folgendes komplexere Bild:
Die ursprüngliche vmdk-Disk lag unter “/vmw/Win7/”, die virtuelle Maschine mit ihrer Haupdisk aber unter “/vmw/Win7Prod/”
. Die Snapshots der ursprünglichen Disk
/vmw/Win7/Win7_x64_ssd_ex.vmdk
wurden automatisch aber unter “/vmw/Win7Prod/” abgelegt – der letzte als
/vmw/Win7Prod/Win7_x64_ssd_ex-000003.vmdk.
Der Unterschied mach sich sich schon beim Betrachten der Partitionen bemerkbar:
mytux:/vmw/Win7Prod # vmware-mount -p ../Win7/Win7_x64_ssd_ex.vmdk Nr Start Size Type Id Sytem -- ---------- ---------- ---- -- ------------------------ 1 2048 12576768 BIOS 7 HPFS/NTFS mytux:/vmw/Win7Prod # vmware-mount -p Win7_x64_ssd_ex-000003.vmdk Nr Start Size Type Id Sytem -- ---------- ---------- ---- -- ------------------------ 1 2048 6295552 BIOS 7 HPFS/NTFS 2 6297600 6279168 BIOS 7 HPFS/NTFS
Mounten der zweiten Partition im dritten Snapshot zeigt:
mytux:/vmw/Win7Prod # la | grep _ex -rw------- 1 myself users 42860544 Mar 27 11:19 Win7_x64_ssd_ex-000001.vmdk -rw------- 1 myself users 1572864 Mar 27 11:51 Win7_x64_ssd_ex-000002.vmdk -rw------- 1 myself users 1572864 Mar 27 11:56 Win7_x64_ssd_ex-000003.vmdk mytux:/vmw/Win7Prod # vmware-mount Win7_x64_ssd_ex-000003.vmdk 2 /mnt/vmdk mytux:/vmw/Win7Prod # la /mnt/vmdk total 8 drwxrwxrwx 1 root root 4096 Mar 27 11:15 . drwxr-xr-x 38 root root 4096 Mar 20 11:14 .. drwxrwxrwx 1 root root 0 Mar 27 11:08 System Volume Information drwxrwxrwx 1 root root 0 Mar 27 11:50 tull mytux:/vmw/Win7Prod7 # la /run/vmware/fuse total 8 drwxr-xr-x 3 root root 80 Mar 27 12:08 . drwxr-xr-x 5 root root 180 Mar 27 11:56 .. dr-xr-xr-x 2 myself users 4096 Mar 27 12:08 11844985246325345490 -rw-r--r-- 1 root root 344 Mar 27 12:08 11844985246325345490.info mytux:/vmw/Win7Prod # losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO /dev/loop0 0 3224371200 0 0 /run/vmware/fuse/11844985246325345490/flat 0
Der Offset errechnet sich hier übrigens aus einem Standard vmdk-Offset von 2048 * 512 Byte plus der Größe der ersten Partition
2048 * 512 + 6295552 * 512 = 6297600 * 512 = 3224371200
Ganz analog läuft unser Beispiel mit dem echten Container “Win7_x64_ssdx.vmdk”, der zwei Extension-Files und zwei Filesysteme beinhaltet:
mytux:/vmw/Win7 # vmware-mount -p Win7_x64_ssdx.vmdk
Nr Start Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1 2048 5310464 BIOS 7 HPFS/NTFS
2 5312512 3072000 BIOS 7 HPFS/NTFS
mytux:/vmw/Win7 # vmware-mount Win7_x64_ssdx.vmdk /mnt2
mytux:/vmw/Win77 # la /mnt2
total 8
drwxrwxrwx 1 root root 0 Mar 27 19:35 $RECYCLE.BIN
drwxrwxrwx 1 root root 4096 Mar 27 19:35 .
drwxr-xr-x 38 root root 4096 Mar 20 11:14 ..
drwxrwxrwx 1 root root 0 Mar 27 19:34 System Volume Information
mytux:/vmw/Win7 # vmware-mount -d /mnt2
umount: /var/run/vmware/fuse/15887816320560912647.links/19: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
mytux:/vmw/Win7 # vmware-mount -d /mnt2
Failed to unmount partition '/mnt2': Nothing mounted at the given mountpoint
mytux:/vmw/Win7 # vmware-mount Win7_x64_ssdx.vmdk 2 /mnt2
mytux:/vmw/Win7 # la /mnt2
total 196124
drwxrwxrwx 1 root root 4096 Mar 27 19:38 .
drwxr-xr-x 38 root root 4096 Mar 20 11:14 ..
drwxrwxrwx 1 root root 0 Mar 27 19:37 System Volume Information
-rwxrwxrwx 2 root root 200822784 Nov 4 2013 mysql-installer-community-5.6.14.0.msi
mytux:/vmw/Win7 # vmware-mount -d /mnt2
Hier sieht man übrigens, dass man bei einer manchmal auftauchende
Fehlermeldung “target is busy” im Unmount-Process, die u.a. auch durch Desktop-Suchmaschinen bedingt sein kann, nicht gleich in Panik verfallen muss.
Man beachte beim zweiten Mount-Versuch die 2 in “vmware-mount Win7_x64_ssdx.vmdk 2 /mnt2″; diese 2 spezifiziert das zweite Filesystem. Auch in diesem Fall wird natürlich ein “Flat-File” angelegt:
mytux:/vmw/Win7 # vmware-mount Win7_x64_ssdx.vmdk 2 /mnt2 mytux:/vmw/Win7 # la /run/vmware/fuse total 8 drwxr-xr-x 3 root root 80 Mar 27 20:50 . drwxr-xr-x 5 root root 180 Mar 27 19:38 .. dr-xr-xr-x 2 rmo users 4096 Mar 27 20:50 15887816320560912647 -rw-r--r-- 1 root root 299 Mar 27 20:50 15887816320560912647.info mytux:/vmw/Win7 # la /run/vmware/fuse/15887816320560912647 total 4194304 -rw------- 1 myself users 4294967296 Mar 27 19:34 flat mytux:/vmw/Win7 #
Fazit
vmware-mount bietet eine einfache Möglichkeit, Partitionen, die in vmdk-Containern enthalten sind, unter Linux zu mounten. Container kann man aber auch einfach nur als ein Flat-File mounten und die Behandlung der enthaltenen Partitionen über Loop-Devices selbst übernehmen. Die automatisch vergebenen Rechte (voller Lese- und Schreibzugriff durch jedermann) erfordern aber Vorsicht.
Im nächsten Beitrag
Mounten eines vmdk-Laufwerks im Linux Host – II – Einschub, Spezifikation, Begriffe
liefere ich zunächst einige Hinweise zur vmdk-Spezifikation nach und versuche dann, durch Rückgriff auf ein Tool aus dem qemu-Bereich, das erforderliche Flat-File zu einem vmdk-Container ohne vmware-mount bereitzustellen.
Links