VMware Workstation – Virtual Ethernet failed – sometimes for good!

I use VMware Workstation as a hypervisor for hosting a few MS Windows guests, which I need in customer projects. As I do not trust Windows systems I sometimes place such guests in different virtual and isolated host-only networks on my workstation or a dedicated server. On other systems I run virtualized Linux server systems for production and tests with the help of KVM/QEMU, LXC and libvirt. Some time ago I learned the hard way that I have to keep track of the different "local" virtual networks more thoroughly. As the VMware side was affected by a misconfiguration in a rather peculiar way I thought this experience might be interesting for others, too.

Host interface to VMware virtual network sometimes not available?

The whole thing coincided with an upgrade of one of my Opensuse workstations. I am always a bit nervous whether and how such an upgrade may impact the VMware WS installation. Quite often I experienced problems with the automatic compilation in the past. In addition the start of some modules lead to secondary errors. However, at a first test VMware WS 14 compiled without problems on a system with Opensuse Leap 15. No wonder, I thought, as the kernel version 4.12 of Leap15 is relatively old.

Then I had to set up a Windows guest. I gave it an IP address within a virtual VMware host-only network, which covered an IPv4 address range of a class C network. VMware uses a kind of virtual bridge to support such a network; normally one associates a virtual network device on the host with it, to which you can assign a certain IP address in the net's address ange. For a C-net VMware uses yyy.yyy.yyy.1 as a default on the host's interface (with yyy.yyy.yyy defining the C-network). In my case the device on the host was named "vmnet6". In the beginning this virtual interface also worked as expected.

However, during the following days I noticed trouble with "vmnet6". In a normal host configuration the VMware WS initialization script ("/etc/init.d/vmware") is started as a LSB service by systemd. The script loads VMware modules and configures the defined virtual networks. Unfortunately, relatively often, my "vmnet6" interface did not become directly available after the start of the Linux host. Some experiments showed however that I could circumvent this problem by some "dubious" action:

I had to enter the "Virtual Network Editor" with root rights and save the already existing virtual network again. Then ifconfig or the ip command enlisted interface "vmnet6" - which also seemed to work normally.

You get a strange feeling when you are forced to remedy something as root .... However, I ignored this problem, which I could not solve directly, for a while. I also noticed that the problem did not occur all the time. This should have rang a bell ... but I was too stupid. Until, yesterday, when I needed to set up another special MS WIN guest in the same address range.

Virtual Ethernet failed

In addition I upgraded to VMware WS Version 14.1.3. The (automatic) compilation of the VMware WS modules on Opensuse Leap 15 again worked without major problems. But, when I manually (re-) started the VMware modules via "/etc/init.d/vmware restart" I saw an error message:

"Virtual Ethernet failed".

Such a message makes you nervous because you assume some real big problem with the VMware modules. However, starting some of my VMware guests (not the ones linked to vmnet6) proved that these guests operated flawlessly and could communicate via their and the hosts network devices. But my "vmnet6" did not appear in the output of "ip a s".

The problem "Virtual Ethernet failed" is reported in some Internet articles; however without a real solution. See e.g. https://ubuntuforums.org/showthread.php?t=1592977; https://www.linuxquestions.org/questions/slackware-14/vmware-workstation-unable-to-start-services-4175547448/; https://communities.vmware.com/thread/264235.

Now, I seriously began to wonder whether and how this problem was related to the already known problem with my virtual device "vmnet6". Some tests quickly showed that the error message disappeared when I eliminated the host-only network related to "vmnet6". Then I tried a new host-only test network with a device "vmnet7" and a different IP range. Also then the "virtual Ethernet" started flawlessly. So, what was wrong with "vmnet6" and/or its IP range? Some residual garbage from old installations? A search for configuration files gave me no better ideas.


After a minute I thought: Maybe VMware is right. A look into the log-file "/var/log/vnetlib" revealed:

Oct 14 14:22:49 VNL_Load - LOG_ERR logged
Oct 14 14:22:49 VNL_Load - LOG_WRN logged
Oct 14 14:22:49 VNL_Load - LOG_OK logged
Oct 14 14:22:49 VNL_Load - Successfully initialized Vnetlib
Oct 14 14:22:49 VNL_StartService - Started "Bridge" service for vnet: vmnet0
Oct 14 14:22:49 VNLPingAndCheckSubnet - Return value of vmware-ping: 0
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet2 is available
Oct 14 14:22:49 VNL_CheckSubnetAvailability - Subnet: yyy.yyy.yyy.yyy on vnet: vmnet6 is not available
Subnet on vmnet6 is no longer available for usage, please run the network editor to reconfigure different subnet
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet7 is available
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet8 is available

(I have replaced real addresses by xxx and yyy.) So, obviously VMware at startup performs a kind of ping check beyond the locally defined virtual devices and networks. Interesting! Why do they ping?

The answer is trivial: When you set up the (virtual) internal bridge for the host-only network you may want to guarantee that the IP-address for the respective host device ("vmnet6") does not exist anywhere else in the reachable network - especially as the host's interface of a host-only network may be used for a host controlled routing (and NAT) of the otherwise isolated VMware guests to the outside world.

Address overlap

And this resolved my problem: A manual ping for the address of the planned host's interface address yyy.yyy.yyy.1 indeed gave me a result. I located the source on another server, where I sometimes perform tests of different virtual network configurations with KVM guests, LXC containers and libvirt. Unfortunately, I had not disabled all of my test networks after my last tests. Due to default DHCP-settings a virtual interface with address yyy.yyy.yyy.1 got established on the test server whenever it was booted. This also explained the finding that the VMware WS problem did not occur always - it only happened when the test server was active in my physical LAN!

Then I actually remembered that I had had a similar problem once in 2016, whilst experimenting with QEMU/VMware-bridge-coupling. (See: Opensuse/Linux – KVM, VMware WS – virtuelle Brücken zwischen den Welten). So, I should have known better and planned my "local" virtual experiments a bit more carefully to avoid address overlaps with other potential virtual networks on different hosts in the LAN.

Stupid me ... The VMware WS startup script was absolutely right to not establish a second address of that kind on my workstation! This lead to the error message "Virtual ethernet failed" - which in my opinion should include a bit more detailed information or a hint to a log-file. But the fault clearly was on my side: One should not think in terms of a local host environment when using VMware WS for virtual networks, but consider the global network configuration.

Still, the whole VMware handling of a possible IP address overlap left me a bit puzzled :

Why can you by saving the questionable virtual network again establish a host interface despite the fact that another interface with the same address is running somewhere in the network? OK, you are root when you do it - but why is no warning given at this point? (VMware could do a ping check there, too .... )

A second question also worried me: Why did the existence of two devices with the same IP-address did not lead to more chaos in the network? One reason probably was that I had allowed pinging but no general TCP-transport to the virtual device on the test server. And explicit routes were otherwise defined properly on the different hosts. However, I could bet on some problems on the ARP-level when the test server was up and running. Anyway - such a basic misconfiguration in a a network may lead to security holes, too, and should, of course, be avoided.

A third question that came up for a second was: How do you avoid overlaps in case one wants to assign KVM/QEMU-guests and VMware guests IP addresses within the same network address space on one and the same virtualization host? Such a scenario is not at all as far fetched as it may seem at first sight. One reason for such a configuration could be the EU GDPR (DSGVO):

If you need to guarantee a customer confidentiality and are nevertheless forced to use a standard MS Windows client, you have a problem as MS may in an uncontrollable way transfer data to their own servers (outside the EU). Just read the license and maintenance agreements you sign with the operation of a standard Win 10 client! Therefore, you may want to isolate such clients drastically and only allow for communication with certain IP-addresses on the Internet (and NOT with MS servers). You may allow communication with some (virtualized) Linux machines in the same sub-network and one of them may serve as a gateway and perimeter firewall with strict filters. You can build up such scenarios by coupling a QEMU-virtual bridge to a VMware virtual bridge. At the same time, however, you need full control over the DHCP-systems on both sides (besides a bit of scripting) to avoid address overlaps. But this is actually easy: the DHCP-control files on the VMware side are found under the directory "/etc/vmware/vmnetX/dhcpd", with "X" standing for a virtual VMware interface number. On the QEMU side you find the files at "/etc/libvirt/qemu/networks". There you can control your IP assignments (or even no assignments for some special interfaces). Ok, but this is the beginning of another story.


Never think "local" or host based when working with virtual networks! Always include local virtual test networks in your documentation of your global network landscape! An do not always just accept the standard address assignment for host interfaces to virtual networks without thinking.

Upgrade auf Opensuse Leap 15.0 – Probleme mit Nvidia-Treiber aus dem Repository und mit VMware WS 12.5.9

Opensuse Leap 15.0 ist nun schon eine Weile auf dem Markt. Zeit, von Leap 42.3 umzusteigen. Also ein Upgrade durchführen. Geht das problemfrei?

Upgrade von PCs/Workstations

Ich habe Upgrades inzwischen an einem Laptop und auf zwei Linux-Workstations durchgeführt. Ich spreche nachfolgend also nicht über echte Opensuse-basierte Server-Systeme. Die gute Nachricht für Leute, die ihre PCs / Workstations bislang unter Opensuse Leap 42.3 mit ext4 und LVM betrieben haben, ist:

Man kann ohne allzu große Schwierigkeiten auf Leap 15.0 upgraden. Das gilt auch, wenn man eine Reihe von Zusatz-Repositories für bestimmte SW eingesetzt hat (in meinem Fall für Produkte aus den Packman-, Security-, Network-, Forensic-, PHP, Java-, .... -Repositories, die Opensuse eben so anbietet).

Da Leap 15.0 bzgl. BTRFS ein paar neue Features mitbringt, traue ich mich nicht, dieses Statement so auch für Systeme zu machen, bei denen das Root-Filesystem auf BtrFS aufsetzt. Auch Laptops mit Optimus-Systemen habe ich noch nicht umgestellt.

Vorgehensweise für das Upgrade
Man folgt für das Upgrade am besten der unter
beschriebenen grundsätzlichen Schrittfolge. Der genannte Artikel beschreibt zwar den Wechsel von Leap 42.2. auf Leap 42.3. Die angegebenen Schritte lassen sich aber ganz analog auch auf ein Upgrade auf von Leap 42.3 auf Leap 15.0 anwenden. Natürlich muss man "Leap 42.2" bzw. "Leap 42.3" in den Vorgaben sinngemäß durch "Leap 42.3" bzw. "Leap 15.0" ersetzen.

Das Upgrade von KDE/Gnome und SSDM/GDM3 funktioniert. Auch Apache2- und MySQL-Dienste werden auf den neuesten Stand gebracht und laufen dann mit den alten Konfigurationen weiter. KVM/Gäste ließen sich in der erneuerten KVM/QEMU/libvirt/spice-Umgebung problemfrei starten. Nach dem Upgrade des System-Kerns bindet man die benötigten zusätzlichen Repositories ein und zieht seine Spezialanwendungen und Multimedia-Anwendungen nach. Bzgl. Multimedia primär über Packman; nur im Einzelfall greife ich auf Pakete anderer Multimedia-Repos zu. Unter Leap 15 unterstützt auch eine Implementierung von JAVA 10 etwa Eclipse Photon bei entsprechender Konfiguration sehr stabil. Das Weiterentwickeln von SW mit Hilfe von Eclipse ist also gesichert. Einzig manche Default GTK3-Styles muss man ändern, um sowohl LibreOffice 6 als auch Eclipse Photon mit Dark Scheme ohne Augenprobleme nutzen zu können (s. hierzu frühere Artiekl im Blog).

Natürlich gibt es im Einzelfall aber doch ein paar knifflige Hürden. Nachfolgend zwei, die mir den Umstieg erschwert haben:


Für ein KDE-basiertes System "mytux1", auf dem ich schon bislang die Nvidia-Treiber aus dem Opensuse-Nvidia-Repository genutzt hatte, funktionierte der Wechsel auf Leap 15.0 anstandslos. Man landet bei der Vorgehensweise des oben erwähnten Artikels zwar zunächst (erwartungsgemäß) im Konsolen-Modus. Dort muss man über die ASCII-Variante von YaST Oberfläche das Nvidia-Repository
zum YaST-Software-Management hinzufügen und anschließend die passenden Treiber für sein Nvidia-Kartenmodell installieren. SDDM und KDE5 Plasma kamen nach einem Reboot dieses Systems auf Anhieb hoch.

Schwierigkeiten bereitete aber ein anderes KDE-basiertes System "mytux2", für das ich seit Jahren aktuelle proprietäre Treiberversionen von der Nvidia Web-Site heruntergeladen und manuell über den Nvidia-Installer installiert hatte. Auf diesem System führte der Versuch einer ersten Treiberinstallation aus den Opensuse-Nvidia-Repositories ins Nirwana:

Beim Hochfahren flackerte zunächst das Konsolen-Terminal mit dem angezeigten Prompt; in diesem Modus sind kontrollierte Eingaben kaum möglich. Das ist mir übrigens nicht zum ersten Mal bei Upgrades passiert. Zur Vorsorge ist es sehr nützlich, vor dem Upgrade den SSHD-Service zu aktivieren (systemctl enable ....). Man kann sich dann beim Hochfahren nach dem Upgrade wenigstens von anderen Systemen aus einloggen und ein "init 3" absetzen, damit sich die Anzeige "beruhigt".

Nun hat man zwei Möglichkeiten: Download einer aktuellen Treiber-Version von der Nvidia-Website und manuelle Installation. Oder aber: Zuschalten des Nvidia-Repositories und Installation der Treiber über RPM-Pakete und YaST. Ich habe zuerst Letzteres versucht. Systemd initiierte dann nach einem Restart auch den Wechsel zum graphischen "Target" und versuchte erkennbar X und SDDM zu starten; das Ganze endete aber in einem schwarzen Schirm mit Mauszeiger. Und nicht mit der Anzeige des SDDM-Login-Schirm ...

In einigen Internet-Beiträgen zu ähnlichen Problemen wird empfohlen, den User "sddm", unter dem der Login- und Display-Manager SDDM für KDE Plasma-Nutzer ausgeführt wird, zu einem Mitglied der Gruppe "video" zu machen. Das half in meinem Fall aber gar nichts.

Was war da faul?

Zunächst besorgte ich mir zum Vergleich den aktuellen Treiber manuell von der Nvidia-Website; in der gleichen Version wie im Nvidia-Repository hinterlegt. Und siehe da: die manuelle Installation (inkl. Kompilation etc.) über den Nvidia-Installer (also das "run"-Skript ) funktionierte! Allerdings kam eine Warnung, dass die vorhandene "libglvnd"-Installation nicht vollständig sei. Man wird dann vom Nvidia-Installer gefragt, ob er die Installation aus eigenen Ressourcen korrigieren solle. Ich habe dem zugestimmt. Danach kamen SDDM und KDE Plasma anstandslos hoch. Durchatmen: wenigstens die manuelle Installation führt zum Erfolg. Es gibt also kein fundamentales Problem zwischen Leap 15 und den Nvidia-Treibern. Was aber, wenn man aus bestimmten Gründen zu den Opensuse-Nvidia-Repos wechseln will?

Eine komplette Deinstallation des Nvidia-Treibers über das zugehörige Run-File per

bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run --uninstall

und eine anschließende Installation des gleichen Treibers per Opensuse-Nvidia-Repo führte leider wieder ins Nirwana.

Auffällig war bei der manuellen Deinstallation allerdings eine Meldung zu nicht ordnungsgemäß herstellbaren Links im Verzeichnis "/usr/lib64". Dort liegen bekanntermaßen *.so-Libraries. Ein genaues Studium der im Zuge der verschiedenen Installationen angelegten Links in diesem Verzeichnis brachte dann die Lösung:

Nach einer funktionierenden manuellen Installation des Treibers von der Nvidia-Website gab es dort folgende relevante Einträge :

mytux2:/usr/lib64 # la | grep libGL
-rw-r--r--   1 root root       656 Sep 21 18:46 libGL.la
lrwxrwxrwx   1 root root        10 Sep 21 18:46 libGL.so -> libGL.so.1
lrwxrwxrwx   1 root root        14 Sep 21 18:46 libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x   1 root root    665720 Sep 21 18:45 libGL.so.1.7.0

Das Vergleichssystem "mytux1" zeigte hingegen folgende Konstellation:

mytux1:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0

Andere Versionsnummern, aber eine ähnliche Verlinkung.

Nach dem manuellen Uninstall per "bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run --uninstall " auf "mytux2"
und einem Installieren der Treiberdateien aus den Opensuse-Nvidia-Repositories für Leap 15.0 ergab sich hingegen folgendes Bild:

mytux2:/usr/lib64 # la | grep libGL       
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    430760 Nov 21  2016 libGL.so.1.2.0

Hier war zwischenzeitlich offenbar etwas Altes aus dem Jahre 2016 restauriert worden! Woher der Nvidia-Uninstaller das auch immer genommen haben mag... Dass der Nvidia Installer/Uninstaller damit zu tun hatte, ergab sich aus der Tatsache, dass die Datei "libGL.so.1.2.0" sich keinem RPM-Repository zuordnen ließ, die libGL.so.1.0.0 aber schon :

mytux2:/usr/lib64 # rpm -qf libGL.so.1.0.0

Wer immer da wann was im "libGL/libglvnd"-Umfeld verbrochen hatte; dieser Schaden ließ sich beheben. Offenbar ist für die Repository basierten Treiber nur die "libGL.so.1.0.0" maßgeblich. Ich habe daher eine Umsetzung der Links vorgenommen und die "libGL.so.1.2.0" gelöscht. (Auch die manuelle Treiberinstallation nutzt diese Bibliothek ja nicht ...; s.o.).

mytux:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1.2 -> libGL.so.1.0.0

Die Dateien aus dem Opensuse-Nvidia-Repository habe ich dann zur Sicherheit nochmal überinstalliert. Und siehe da, danach lief alles. Den Link "libGL.so.1.2" konnte ich schließlich auch ohne Schaden wegschmeißen.

Merke: Eine Historie mit Wechseln von Nvidia-Treiber-Installationen aus dem Opensuse-Repository und manuellen Installationen per Nvidia-Installer-Daten bleibt nicht immer verwerfungsfrei. Ein Blick in die Links unter "/usr/lib64" ist hilfreich.

Problem mit VMware WS 12.5.9 unter Leap 15.0

Auf einem meiner Systeme läuft eine relativ aktuelle VMware WS 14.1.1-Umgebung. Die überlebte das Upgrade auf Leap 15.0 anstandslos. Die Module wurden im Hintergrund neu kompiliert und erfolgreich gestartet.

Auf einem anderen System lief aber die WS 12.5.9. Die ließ sich zunächst nicht dazu bewegen zu starten. Die Module für den "Virtual Machine Monitor" wie das "Virtual Network" konnten nicht erfolgreich kompiliert werden. Hier hatten findige Menschen aber dankenswerterweise schon vorgearbeitet; das Problem ist bekannt und gelöst. Die notwendigen Schritte, die auch auf meinem System zum Erfolg führten findet ihr hier


Addendum, 25.03.2020: The steps described in the referenced community article work on Leap 15.1, too.

Viel Spaß dann mit Opensuse Leap 15 ! ZU Leap 15 und Optimus bald mehr, wenn ich Zeit finde ...

Mounten eines vmdk Laufwerks im Linux Host – I – vmware-mount

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;

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

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. "" ist; diese Info erhält man z.B. aus einem von unter VMware bereitgestellten PDF (VMwareDiskMount.pdf :

"In the following list of options, is an identifier of the form username@hostname:/path/to/disk for remote disks, or just the /path/to/disk for local disks."

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 ...


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
    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.


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
wurden automatisch aber unter "/vmw/Win7Prod/" abgelegt - der letzte als

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-
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 # 


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.