VMware vSphere RDMs von SATA an VMDK binden

Raw Device Mappings auf lokale SATA-Disk

| Autor: Thomas Drilling

RDM-Disks in einer vSphere-VM
RDM-Disks in einer vSphere-VM (Thomas Drilling)

Raw Device Mappings (RDM) ist ein Feature, das vSphere schon lange unterstützt, das aber in den letzten Jahren etwas an Bedeutung verloren hat, weil die heutigen Anbindungsmöglichleiten an Storage-Backends von NFS-Freigaben über iSCSI-LUNs, FC-SAN bis zu Virtual SAN deutlicher vielfältiger und performanter sind als vor einigen Jahren. Zudem sind die Kosten für SAN oder gar SDS-Lösungen deutlich gesunken.

Unter Raw-Device-Mapping versteht man den das Anbinden einer physischen Disk an eine virtuelle Maschine, respektive VMDK-Datei. Die Funktion war vor 5 Jahren im Zusammenhang mit ESX/ESXi 4.0 und 4.1 populär, galten RDMs doch als performanter als virtuelle Disks. Mit der Performance heutiger Backendsysteme nutzt allerdings kaum mehr jemand RDMs ohne zwingenden Grund. 

Typische RDM-Szenarien

Ein typisches Szenario auf dem Enterprise-Bereich wäre z. B.: … ein Unternehmen betreibt einen physischen MS-Exchange-Server, dessen Datenbank- und Datendateien auf einer dedizierten iSCSI-LUN liegen. Nun soll der Exchange Server durch einen weiteren Knoten zu einem Cluster erweitert werden, allerdings ohne Anschaffung eines weiteren physischen Hosts.

Dies ist problemlos möglich, da sich ein MS Exchange Server auch als VM betreiben lässt. Letztere kann dann so konfiguriert werden, dass für die Systemdatei das virtuelle Laufwerk C: der VM verwendet wird, als Daten-Partition aber die vorhandene, externe LUN via RDM in die VM eingebunden wird. Ähnliche Szenarien sind mit jedem beliebigen anderen Anwendungsserver ebenso vorstellbar.


RDM und lokale SATA-Disks

Folgendes Szenario zum Verwenden von RDMs ist profaner: eine Test-Installation der Software-Defined-Storage-Lösung DataCore Hyper-converged Virtual SAN - der VM-basierten Variante von DataCore SANsymphony - unter VMware vSphere 6.0 benötigt in der VM Zugriff auf wenigstens ein physisches Backend-Gerät. Im Regelfall würde man dazu eine externe LUN aus einem vorhandenen SAN -Arra< verwenden.

Gibt es allerdings auf dem ESXi-Server noch eine lokale SATA-Disk, drängt sich deren Verwendung für ein Test-Setup dieser oder anderer Art auf, da lokale Disks in einem vSphere-Cluster ohnehin hin nicht verwendet werden sollten, weil fast alle Cluster-Features Shared-Storage voraussetzen.

Versucht man allerdings in den VM-Einstellungen des vSphere-Clients ein RDM mit einer lokalen Disk zu realisieren, ist die Funktion ausgegraut, weil VMware sie offiziell nicht unterstützt. Im Web-Client kann man zwar im Konfigurations-Editor unter „Edit Setting“ im Kontextmenü der VM problemlos ein RDM-Gerät hinzufügen, der Assistent erwartet dann allerdings die Angabe eines externe Targets.

So funktioniert ein RDM->SATA-Mapping per CLI

Das gewünschte Feature funktioniert aber sehrwohl, wenn man zur Kommandozeile greift. Die Vorgehensweise ist im Detail in VMwares Documentation Center erläutert. Hier die Kurzform:


Hierzu loggt man sich via SSH (oder ALT F1 direkt an der DCUI) auf den ESXi-Host ein. Zunächst muss man herausfinden, mit welcher Gerätedatei die gewünschte Disk tatsächlich korrespondiert. Hierzu navigiert man mit

cd /vmfs/devices/disks  (ein Link auf /dev/disks)

ins Verzeichnis der physischen Disks und schaut mit „ls“ nach. SATA-Disks sind an einer Bezeichnung wie t10.ATA_____WD5003ABYX2D88_______________________LEN______WD2DWMAYP6589359 zu erkennen.

Allerdings verwendet VMware intern, eigene Laufzeit-Gerätenamen. Mit „ls –l“ erkennt man dies am Link-Operator. Für das folgende „vmkfstools“-Kommando braucht man zwingend den VMware-Namen, der mit „vml….“ anfängt.

Übrigens darf man auch den Link „/dev/disks“ nicht verwenden sondern muss zwingend „/vmfs/devices/disks“ nehmen, sonst gibt es eine Fehlermeldung.

Das Anbinden der physischen Disk an ein vom Nutzer anzugebendes VMDK-File funktioniert dann wie folgt. Die Gerätenamen sind dabei durch die Eigenen zu ersetzen:

vmkfstools -r /vmfs/devices/disks/vml.0100000000202020202057442d574d41595036353839333539574435303033 rdmdisk.vmdk

Der Ordnung halber sollte man allerdings für die „rdmdisk.vmdk“ vorher einen Ordner im gewünschten Datastore anlegen und dann bei vmkfstools den vollständigen Zielpfad angeben, etwa …

vmkfstools -r /vmfs/devices/disks/vml.0100000000202020202057442d574d41595036353839333539574435303033 /vmfs/volumes/datastore5/RDM/rdmdisk.vmdk

Statt des Parameters „–r“ funktioniert auch „–z“ für den sogenannten RDM-Kompatibilitätsmodus. Die Unterschiede erklärt die oben verlinkte VMware-Dokumentation.

Jetzt lässt sich die Disk mit Hilfe der so erstellten VMDK, die quasi auf ein RDM zeigt, im Konfiguration-Editor problemlos in eine VM einbinden. Hierbei ist dann allerdings "Existing Hard Disk" und nicht "RDM Disk" auszuwählen.  Dann navigiert man im entsprechenden Datastore zur  eben erzeugten RDM.VMDK-Datei.

Tipp: Ist man sich nicht sicher, auch das richtige Disk-File erwischt zu haben, sollte man lieber mit

fdisk –l <Gerätedatei> (diesmal der echte Name)

nachschauen. Beherbergt die Disk z. B. noch eine vorhandene Partitionstabelle einer früheren Windows-Installation, ist sie zuvor in fdisk zu bereinigen.

Achtung: fdisk hat Probleme mit GPT; in diesem Fall sollte man dann partedUtil verwenden. Es gibt verschiedene Anleitungen im Internet, wie man die Disk mit partedUtil wieder in einen für ESXi verwertbaren Zustand versetzt. Einfacher ist es, man löscht mit fdisk alle vorhandenen Partitionen und wirft dann im vSphere-Client den grafischen Assistenten zum Anlegen eines neuen VMFS-Datastores für die betreffende Disk an, der auch einen grafischen Partitionierer mitbringt. Ist die Partitionstabelle geradegerückt, kann man den Datastore wieder löschen.