Update, 17. Januar 2008: Xen 3.2 final wurde heute veröffentlicht. Golem berichtet darüber.
Ein großes Problem bei vielen Virtualisierungstechnologien ist die fehlende Möglichkeit, in einem Gastsystem “rohen” Zugriff auf einzelne Hardwarekomponenten zu erhalten. Zwar bieten VMware und andere das Durchreichen von USB-Geräten, doch das ist eine Lösung, die für physikalisch vom Netz des Wirts getrennte Firewalls oder RAID-Subsysteme nicht wirklich akzeptabel ist. Eine interessante Abhilfe bietet Xen, wo mit vertretbarem Aufwand Gäste direkten Zugriff auf PCI-Karten bekommen.
Anpassungen am Dom0-Kernel
Der Dom0-Kernel sollte in der Regel richtig konfiguriert sein. Hier muss unter “Xen” der “PCI-device backend driver” aktiviert sein und dessen Modus auf “Passthrough” stehen.
Anpassungen am DomU-Kernel
In vielen Fällen werden Sie einen eigenen DomU-Kernel benötigen. Die von mir und einigen anderen angebotenen DomU-Kernel integrieren nur die Frontend-Treiber für Xen-Block-Devices und Xen-Network-Devices, Sie benötigen jedoch einen Kernel, der einerseits den PCI-Frontend-Treiber mitbringt und andererseits Treiber für die zu unterstützenden Geräte. Als Ausgangsbasis können Sie einen normalen XenU-Kernel verwenden und die gewünschten Treiber zusätzlich auswählen:
Stillegen der PCI-Devices in der Dom0
Damit einzelne PCI-Geräte durchgereicht werden können, müssen diese per Bootparameter stillgelegt werden. Identifizieren Sie zunächst mit lspci -v die betreffenden Karten und ergänzen Sie dann die Appendzeile der Dom0:
title Xen 3.2.0rc4 - Linux 2.6.18.8
root (hd0,0)
kernel /boot/xen-3.2.0-rc4-pre.gz
module /boot/vmlinuz-2.6.18.8-xen0 root=/dev/hda1 ro pciback.permissive pciback.hide=(00:0c.0)(00:0c.1)(00:0c.2)(00:0d.0)(00:09.0)
boot
Nun ist ein Reboot des gesamten Systems erforderlich. Anschließend können Sie in der DomU mit lspci die durchgereichten Karten ermitteln, Treiber laden und so die Hardware direkt verwenden:
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0c.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Anmerkungen:
Der hier zu sehende Gast war ein temporär aufgesetztes Testsystem mit einer Hauppauge DVB-C-Karte, der die Möglichkeit haben sollte, Videoaufnahmen zu machen, ohne dass Änderungen an der Dom0 erforderlich sind, und der via direktem USB-Zugriff diese Videos flott auf USB-Festplatten kopieren sollte. Hierfür kam ein als PCI-Steckkarte ausgeführter USB-Controller zum Einsatz. Ob es möglich ist, einzelne Roothubs dieses Controllers (immerhin werden diese als separate Geräte angezeigt) durchzureichen, habe ich nicht ausprobiert.
Nach meinem bisherigen Kenntnisstand funktioniert das PCI passthrough nicht bei Domains im Full Virtualization Mode. DomUs haben Kenntnis über die Speicheraufteilung und können demnach Adressen richtig zuordnen. Full Virtualization Mode Clients sehen dagegen Speicher ab 0 Byte.
Ich habe noch keine Performancetests von SATA-Controllern, die via Xen-Block freigegeben wurden, gegenüber dem Durchreichen dieser Controller durchgeführt. Allerdings sollte die Performance spürbar besser ausfallen, da der Weg über den Blockdevice-Treiber der Dom0 wegfällt.
Theoretisch sollte es möglich sein, auch von einer durchgereichten SATA-Karte zu booten. Damit verliert man aber einen der größten Vorteile von Xen, die weitgehende Abstraktion von der darunterliegenden Hardware. In Einzelfällen, in denen Performance vor Abstraktion geht, dürfte es ein guter Kompromiss sein, das Grundsystem von einem kleinen Image zu starten und dann die Datenverzeichnisse, auf denen Performance benötigt wird, via passthrough anzusprechen.
Der Screenshot des domU-Kernels entstand mit dem openSUSE-10.3-Kernel auf einer Ubuntu-7.10-domU. Eine etwas exotische Konfiguration, aber openSUSE liefert recht aktuelle Distributionskernel mit sauber integrierten Xen-Patches. In diesem Fall war ein Kernel >2.6.19 erforderlich, um die DVB-Treiber aus dem Mercurial-Repository integrieren zu können.