Oracle VM - Konfiguration von PCI Passthrough

von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG

Ziel von Virtualisierungslösungen ist es, möglichst viele Systeme in die virtuelle Welt zu überführen. Dies bringt neben der Kosteneinsparung durch die Hardwarekonsolidierung auch mehr Flexibilität und vereinfacht die Sicherung ganzer Systeme. Allerdings gibt es unter den laufenden Systemen bei Kunden oft einige "Ausreißer", bei denen die herkömmlichen Virtualisierungsmöglichkeiten, wie zum Beispiel für Netzwerk, Storage, Memory und CPU nicht ausreichen. Hierzu könnte zum Beispiel ein System gehören, welches die Funktion eines FAX Servers übernimmt oder ein System, welches exklusiven Zugriff auf eine Netzwerkkarte, einen USB Port oder eine andere im Rechner installierte Hardware benötigt.

Die Möglichkeit des exklusiven Zugriffs, bzw. des Zugriffs auf Ressourcen, für die im Hypervisor keine Virtualisierungslösung vorgesehen ist, nennt sich bei XEN (der Basis von Oracle VM) PCI Passthrough: Das Gast System bekommt direkten Zugriff auf die Hardware Ressource und "greift" direkt auf die Physik durch.

Leider sind die Möglichkeiten diese Einbindung vorzunehmen sehr vielfältig, da sie von vielen Parametern abhängig sind:

Nicht jede Hardware unterstützt diese Funktionalität
Version des Hypervisors
Art des Gast Systems - Virtualisierung durch die Hardware bzw. CPU (HVM) oder paravirtualisiert (PVM), d.h. die Virtualisierungsfunktionen stecken im Kernel des Gast Systems
Installierte Kernelmodule in der Dom0 (Administrationsdomain für den Hypervisor)

Zusätzlich ist es auch noch möglich, die Konfiguration unterschiedlich vorzunehmen.

Das Ergebnis hieraus: Eine sonst erfolgversprechende Suche im Internet, lässt den Administrator eines solchen Systems mit einer Vielzahl an Konfigurationsmöglichkeiten zurück. Diese müssen erst sondiert und getestet werden. Da einige einen Reboot des Systems erfordern, kann dies ein zeitraubender Prozess sein. Aus diesem Grunde habe ich meine Erfahrungen, wie die Konfiguration bei Oracle VM funktionieren kann, hier festgehalten.

Anmerkung: Es muss auch erwähnt werden, dass PCI Passthough noch nicht offiziell in OVM von Oracle supported ist.

Hardware Vorraussetzung

Für die generelle Funktionalität von PCI Passthrough, sollte die CPU im Rechner entweder IOMMU (I/O Memory Mapping Unit) unterstützen bzw. VT-d (Virtualisation for Direct I/O), wie dieses Feature bei Intel heißt. Vorsicht: Beides sind zusätzliche Optionen im Bios neben der für HVM benötigten Virtualisierung im Chipset.

Hypervisor Vorraussetzung

Damit OVM die IOMMU Funktionalität verwendet, muss dies dem Kernel beim Booten mitgeteilt werden. Das passiert über das iommu Flag in /boot/grub/grub.conf

title Oracle VM server (2.6.18-128.2.1.4.37.el5xen)
        root (hd0,0)
        kernel /xen-64bit.gz dom0_mem=574M iommu=pv
        module /vmlinuz-2.6.18-128.2.1.4.37.el5xen ro root=UUID=557cc7ef-6d72-4665-af2e-a26fc8d7348c
        module /initrd-2.6.18-128.2.1.4.37.el5xen.img

Ob IOMMU nun vorhanden ist, kann beim nächsten Boot anhand der xen dmesg Protokolle beobachtet werden:

# xm dmesg |grep io
(XEN) Xen version 3.4.0 (mockbuild@(none)) Fri May 13 14:47:55 EDT 2011
(XEN) Command line: dom0_mem=574M iommu=pv
...
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests enabled
...

Vorbereitung des Device zur Weitergabe an das Gast System

Um ein PCI Device nun direkt dem Gast System zuzuordnen, muss es vom Zugriff der Dom0 gelöst werden. Hierzu dient das sogenannte pciback Modul. Leider wird dieses Modul aber bei OVM nicht automatisch geladen, so dass die Verzeichnisstruktur (mit dem entsprechenden Device) über mkinitrd neu aufgebaut werden muss.

Hierzu wird unter /etc/sysconfig/mkinitrd/ eine Datei mit dem Namen pciback und folgendem Eintrag erstellt:

# echo 'MODULES="$MODULES pciback"' > /etc/sysconfig/mkinitrd/pciback
# chmod 755 /etc/sysconfig/mkinitrd/

Als nächstes wird das / werden die Device/s ermittelt, welche/s nicht mehr im Zugriff der Dom0 stehen sollen. Der Befehl "lspci" zeigt die vorhandenen Devices an:

# lspci
00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller
00:06.0 PCI bridge: Intel Corporation 3210 Chipset Host-Secondary PCI Express Bridge
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
...          
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
02:00.0 PCI bridge: Intel Corporation 6702PXH PCI Express-to-PCI Bridge A (rev 09)
03:02.0 Network controller: AVM GmbH Fritz!PCI v2.0 ISDN (rev 02)
04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02)
05:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

In diesem Fall, soll der Zugriff auf "03:02.0 Network controller: AVM GmbH Fritz!PCI v2.0 ISDN (rev 02)" vom Zugriff der Dom0 ausgeschlossen werden. Hierzu wird der folgende Eintrag unter /etc/modprobe.conf gemacht:

options pciback hide=(03:02.0) permissive

Anmerkung: Leider ist es in der aktuellen Version von OVM (XEN 3.4.0) nicht möglich, nur ein sogenanntes "Subdevice" weiterzureichen. Es müssen immer alle Devices einer Domain (domain:bus:slot.func) versteckt werden. Wäre also der Ethnernet Controller nicht auf 05:02.0 sondern ebenfalls auf 03:XX.X, so sähe der Eintrag in /etc/modprobe.conf z.B. so aus:

options pciback hide=(03:00.0)(03:02.0) permissive

Ist dies nicht erwünscht (da die Netzwerkkarte natürlich von OVM benötigt wird), so ist nur ein Wechsel des PCI Slots möglich.

Zum Schluss wird nun über mkinitrd die Verzeichnisstruktur für den Systemstart neu erzeugt, damit nach einen Neustart das pciback Modul automatisch geladen und das Device versteckt wird:

# /sbin/mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`

Vor dem nun benötigten Reboot, wird getestet, ob alle Einstellungen richtig erzeugt wurden:

# mkdir /tmp/x
# cd /tmp/x
# zcat /boot/initrd-`uname -r`.img | cpio -id
# grep pciback *

init:echo "Loading pciback.ko module"
init:insmod /lib/pciback.ko hide=(03:02.0) permissive

# rm -rf /tmp/x

Ein Reboot aktiviert nun die Änderungen und sollte im Output des Befehls dmesg zu sehen sein:

# dmesg |grep pciback
pciback 0000:03:02.0: seizing device

Benutzung der PCI Devices

Die Devices, die nun direkt an ein Gast System (DomU) übergeben werden können, sind mit dem Befehl xm pci-list-assignable-devices zu sehen:

# xm pci-list-assignable-devices
0000:03:02.0

Nur wenn das der Fall ist, funktionieren die weiteren Aktionen. Die Implementation innerhalb XEN funktioniert Hot-Pluggable - d.h. ich kann jederzeit einer laufenden VM die AVM Karte zuweisen bzw. wegnehmen (vorausgesetzt, das Gastsystem unterstützt dies):

# xm pci-attach winxp 03:02.0 7
# xm pci-list
VSlt domain   bus   slot   func
0x07    0x0  0x03   0x02    0x0
# xm pci-detach winxp 03:02.0

Die AVM Karte erscheint direkt in der Systemsteuerung meines Gast Systems:

Da die AVM Karte direkt nach dem Starten des Gasts verfügbar sein soll, wird die Zuweisung der Karte durch folgenden Eintrag in der Konfigurationsdatei des Gast Systems auf dem OVM Server (vm.cfg) persistent:

pci = ['03:02.0@7']

Der String "@7" bezeichnet hierbei den sogenannten Virtuellen Slot (d.h. den PCI Steckplatz), unter dem das Gast System das Device erkennt. Bei alten XEN Versionen waren die Slots 6 und 7 genau f�r diese Funktionalit�t reserviert. OVM kennt diese Restriktion aber nicht, und man kann das @7 auch weglassen. Allerdings f�hrte dies bei einem meiner Versuche dazu, dass nach einem Neustart des Systems bestehende Netzwerkkarten pl�tzlich auf anderen Slots landeten, weshalb ich es vorziehe, den virtuellen Slot fest mit @ zu definieren.

Besonderheiten bei PV Gast Systemen

Zwar kann ein paravirtualisiertes System (PVM) ebenfalls mit VT-D/IOMMU arbeiten, allerdings hat man hier noch eine andere Alternative, die nicht die CPU Funktionalität (IOMMU) benötigt. Hierfür ist dann der iommu=pv beim Kernel der Dom0 nicht notwendig. Das Gast System (DomU) braucht aber dann bei seinem Kernel (/boot/grub/grub.conf) einen iommu=soft Eintrag:

title Enterprise Linux (2.6.18-194.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-194.el5xen ro root=LABEL=/ iommu=soft
        initrd /initrd-2.6.18-194.el5xen.img

Nützliche Links und Referenzen

Xen Wiki - XenPCI Passthough

Xen Wiki - VTd How To

Zurück zur Community-Seite