Category Archives: VMware Workstation

Beiträge zum Einsatz von VMware Workstation am Linux-Arbeitsplatz

Mounten eines vmdk-Laufwerks im Linux Host – II – Einschub, Spezifikation, Begriffe

Posted on by

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

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

Posted on by

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. “” 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 …

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

https://www.novell.com/communities/coolsolutions/retrieve-modify-take-backup-files-inside-vmdk-offline-mode/

Upgrade Laptop to Opensuse 42.3, Probleme mit Bumblebee und VMware WS 12.5, Workarounds

Posted on by

Gestern war ein Upgrade meines nun schon in die Jahre gekommenen Laptops von Opensuse Leap 42.2 auf Leap 42.3 fälllig.
Ich bin dabei gem. der schönen Anleitung in
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
vorgegangen. Zu der Anleitung gibt es nichts weiter zu sagen; die ist perfekt. Im Upgrade hatte ich nur die Standardrepositories (inkl. Update-Repository) für Leap 42.3 benutzt.

Mein Laptop hat eine Nvidia-Karte (Optimus-System). Das ursprüngliche Leap 42.2 lief auf dem Laptop deshalb mit einer Bumblebee-Installation; das funktionierte einwandfrei. Zudem nutzte ich auf dem Laptop VMware WS 12.5. Nach dem Leap-Upgrade hatte ich jedoch sowohl mit Bumblebee als auch VMware-Workstation Probleme – obwohl auch Leap 42.3 nur einen Kernel der nun doch schon recht alten Version 4.4 aufweist! nach dem Ugrade war bei mir 4.4.92-31 aktiv; bei der Leap_42.3 war dagegen der Kernel 4.4.76 der Default-Kernel.

Nebenbei: Bzgl. der Kernelversionen hat der SLES-Unterbau von Opensuse Leap plötzlich den unangenehmen Nebeneffekt, dass man an älteren Kernelversionen kleben bleibt … Von SUSEs Seite müssen ggf. Back-Portierungen aus neuen Kernelversionen zu älteren Versionen vorgenommen werden. Das kann Nebeneffekte zeitigen (s.u.). Bin mal gespannt wie Opensuse mit diesem Thema in Zukunft umgehen will …

Wiederholte Modul-Einträge in der Datei “/etc/sysconfig/kernel”

Das erste Problem war, dass die Datei “/etc/sysconfig/kernel” nach dem Neustart mehrfache Einträge zum Laden von nvidia-Modulen enthielt. Woher immer das stammte; vielleicht hatte ich das ja schon früher von Experimenten mit Bumblebee drin. Vielleicht wurden die Einträge aber auch im Upgrade hinzugefügt. Jedenfalls mal checken, dass in dieser Datei nach dem Upgrade kein überflüssiger Unsinn drinsteht.

Bumblebee-Installation wieder zum Laufen bringen

Bumblebee lief nach dem Upgrade nicht mehr. Ok, dachte ich, also die für Leap 42.3 passenden Repositories aktivieren und diverse Bumblebee-Pakete aktualisieren. Es gibt jedoch mehrere Repositories mit Bumblebee-Paketen für Opensuse Leap, u.a.
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nvidia:/3xx.xx/OpenSUSE_Leap_42.3.
Unter Leap 42.1/42.2 hatte ich etliche Pakete aus diesen Repositories benutzt.

Für Leap 42.3 gilt (nach meiner Erfahrung): Zu nutzen ist
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
und sonst gar nichts! Auch nicht das Nvidia-Community-Repository!

Die im “X11:Bumblebee”-Repository vorhandenen Pakete – inklusive der Pakete mit dem proprietären Nvidia-Treiber – kann und sollte man dagegen (bis auf eines) installieren; das Paket “primus” habe ich mir allerdings aus dem 42.3-Update-Repository geholt.

Ergänzung 02.12.2017: Wichtige Ausnahme:
bbswitch sollte man nicht installieren. Es reicht bbswitch-kmp-default! Und nur letzteres hat bei mir funktioniert – und zwar ohne dkms-Service.

Die Installation von bbswitch aktiviert den “dkms”-Service; waren sowohl “bbswitch-kmp-default” und “bbswitch” installiert, so führte dies bei mir anhand von Statusanzeigen erkennbar zu einem wechselseitigen An- und Abschalten der Graka im Bootprozess; sie wird danach von den Treibern nicht mehr erkannt.

(Auf die anderen Repositories zu unterschiedlichen Nvidia-Treibern sollte man wirklich nur im Notfall zurückgreifen, und zwar dann, wenn ihr für eure Graka zwingend einen älteren Nvidia-Treiber benötigt; aber auch dann nur x11-video-nvidia installieren. Nicht dagegen das Paket “dkms-nvidia”!)

Zu beachten ist also auch folgender Hinweis: Falls ihr früher einen laufenden dkms-Service hattet: Unbedingt deaktivieren! Und zwar nach der Installation der Pakete, aber schon vor einem anschließenden Neustart des Systems.

systemctl disable dkms

Das steht im Gegensatz zu den Anweisungen in der Anleitung
https://de.opensuse.org/SDB:NVIDIA_Bumblebee
absolut notwendig! Zumindest auf meinem Laptop … Fragt mich bitte nicht, warum der dkms-Service zu Problemen führt.

Der Bumblebee-Dämon “bumblebeed” dagegen muss über den zuständigen Service aktiviert werden

systemctl enable bumblebeed

Zudem checken, dass der User, unter dem ihr mit einer grafischen Oberfläche arbeitet, Mitglied der Gruppen “video” und “bumblebee” ist. Ggf. mittels “usermod -G video,bumblebee USERNAME” korrigieren.

Dann Neustart des Systems. Die Kommandos

optirun glxspheres
vblank_mode=0 primusrun glxspheres
optirun -b none nvidia-settings -c :8

sollten danach alle einwandfrei funktionieren.

Sollte das nicht der Fall sein und immer noch eine Meldung kommen, dass die Graka nicht vorhanden sei und der “nvidia”-Treiber nicht geladen werden könne:

Alle Pakete aus dem Nvidia-(Community)-Repository (Treiber nvidia-gfx-GL04 und ähnliche), aus dem Nvidia-Bumblebee-Repository und dem oben angegebenen Standard-Bumblebee-Repository löschen. Danach nur die Pakete aus dem oben angegebenen Standard-Repository http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
mit Ausnahme von bbswitch (!) installieren. Den dkms-Service dann prophylaktisch deaktivieren! Neustart.

Ein probeweiser Start des dkms-Service führt nach einem vorhergehenden Erfolg mit “primusrun” in jedem Fall wieder in die Katastrophe:

Danach kommen in Logfiles Fehlermeldungen, dass es kein passendes Grafik Device gäbe. Am Terminal erscheint: “Cannot access secondary GPU …”. Das ließ sich durch ein anschließendes normales Stoppen des dkms-Service nicht mehr beheben. Bumblebee funktionierte auch nach dem Stoppen des dkms-Service nicht mehr ordnungsgemäß; nvidia Module ließen sich selbst manuell nicht mehr laden. Da half nur ein Reboot – natürlich bei deaktiviertem dkms-Service.

Ich habe leider keine Zeit, der genauen Ursache auf den Grund zu gehen. Bei künftigen Änderungen des Kernels muss man ohne korrekt funktionierendes dkms ggf. halt ein Update für die nvidia- und bbswitch-Module aus dem Bumblebee-Repository erzwingen und damit (zumindest bzgl. nvidia) eine Neukompilation durchführen lassen. Interessant ist, dass für den bei mir nach dem Leap-Upgrade aktiven Kernel 4.4.92-31 ein Link von
/lib/modules/4.4.92-31-default/weak-updates/updatesbbswitch.ko -> /lib/modules/4.4.676-1-default/updates/bbswitch.ko
angelegt wurde. Der funktioniert offenbar. Irgendwas am Kernel 4.4.92 missfällt womöglich dkms beim Versuch, für den neueren Kernel das passende Modul zu definieren. Der 4.4.92-Kernel führt aufgrund von Rückportierungen, die die SuSE-Leute wohl vorgenommen haben, auch noch in anderem Kontext – nämlich bzgl. der VMware WS – zu Schwierigkeiten.

Probleme mit der VMware Workstation 12.5. unter Leap 42.3 beheben

Meine unter Leap 42.2 installierte VM WS 12.5.1 lief nach dem Leap-Upgrade nicht mehr. Auch ein Upgrade der Workstation-SW auf die aktuelle Version 12.5.8 endete beim ersten Startversuch mit Kompilierungsfehlern. Die konnte ich mir im Detail zwar ansehen; wie man aber die problematischen Stellen im Quellcode der VMware-Module beheben hätte müssen, lag jenseits meiner Kenntnisse und Fähigkeiten.

Hier half aber der Beitrag eines offenbar Kernel-Kundigen im VMware Community Forum:
https://communities.vmware.com/message/2693257#2693257
Dort suche man nach dem Beitrag von “hendrikw84“! Herzlichen Dank an diesen Herrn! Seine Vorgaben zur Korrektur diverser Codezeilen funktionieren nämlich einwandfrei. (Ursache der Probleme sind offenbar Rückwärtsportierungen von Features des Kernels 4.10 in den Code des Kernels 4.4. Was immer die SuSE-Leute dabei gedacht haben …)

[ Warum allerdings die eine vorgeschlagene Korrektur-Zeile

retval = retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

nicht gleich zu

retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

verkürzt werden kann, ist mir etwas schleierhaft. Typo? Die letzte Zeile für retval klappt für den Code von hostif.c unter vmmon-only/linux nämlich auch.]

Nach Durchführung der Korrekturen ließen sich die VMware-Codes jedenfalls anstandslos für Kernel “4.4.9-31-default” kompilieren – und die nötigen Kernelmodule wurden fehlerfrei erzeugt. Meine zwei lokalen (non shared) virtuellen Maschinen für Windows-Installationen liefen damit bislang einwandfrei.

Ob es – wie in der Diskussion im VMware Community Forum angedeutet, Probleme mit “shared VMs” auf Servern gibt, habe ich nicht getestet. Auf Servern verwende ich KVM-Installaionen mit spice oder X2GO.

Viel Spaß denn mit Opensuse 42.3 auf dem Laptop!