©Nadja, Fotolia.com

Virtualisierung mit Open-Source-Tools brummt. Das schlanke und schnelle KVM reicht seit Kurzem auch physische PCI-Hardware direkt durch, wenn der Admin ein paar Sachen beachtet. Wie das ohne Probleme klappt, zeigt diese Anleitung .

Die Verwirrung ist groß, wenn es um die Versionsnummer der KVM-Softwarepakete geht. Das liegt nicht nur an der vom Entwicklerteam geänderten Versionierung, sondern auch am Hin und Her mit der Mutter-Software Qemu. Ursprünglich ein Fork von Qemu 0.8 – oder zumindest ungefähr dieser Version -, lief die Entwicklungen von KVM und Qemu einige Zeit lang parallel.

Der Plan der Developer war es, mit Qemu durch die GPL-Lizenz Appetit zu machen und dank der kommerziellen Lizenzierung des Kqemu-Moduls, das die Emulation immerhin fast auf das Fünffache beschleunigte, Geld zu verdienen. Dummerweise machte die Einführung der Vanderpool-Hardware mit der Gerätevirtualisierung das obsolet, so schildert es zumindest einer der Entwickler der KVM-Firma Qumranet, Avi Kivity, in seinem Blog [1].

Hardware-Virtualisierung

Damit läuft virtualisierte Software ohne Emulation auf Wunsch direkt auf dem Prozessor. Nur wenn diese auf die Peripherie zugreifen will, fängt die Virtualisierungsschicht die Aufrufe ab und verarbeitet sie. Die Software arbeitet mit annähernd voller Geschwindigkeit, solange sie nicht mit der Außenwelt kommunizieren muss. Diesen neuen Anteil des ausgegliederten KVM haben die Developer mit der Version 0.11.1 nach Qemu zurückgeforkt, was wiederum dazu führte, dass die Entwickler von KVM beschlossen, damit auch die Versionierung von Qemu zu übernehmen.

Seitdem heißt das Programm selbst ein- heitlich »qemu«. Um eine bestmögliche Unterstützung beim PCI-Passthrough zu erreichen, empfehlen sich die neuesten KVM-Kernelmodule oder der neueste Kernel, mindestens aber ein 2.6.26-er, optimal mit den Userspace-Tools 0.12.2, wie sie in den folgenden Beispielen zum Einsatz kommen. Erhältlich ist das Ganze auf der KVM-Homepage [2].

Die Einschränkung, nur auf Intel-Prozessoren mit Vanderpool-Erweiterung oder AMDs Entsprechung Pacifica lauffähig zu sein, stellt keine Schwierigkeit mehr dar. Die meisten Prozessoren mit Ausnahme einiger Atoms, Celerons und der OEM-Reihen für Billig-Notebooks haben diese Erweiterungen eingebaut. Auch bei AMD sind sie bei allen neueren Prozessoren seit der Einführung der Dualcores (Ausnahme: Sempron) an Bord. Sogar der neueste Via Nano soll Vanderpool beherrschen.

Um in einer virtualisierten Umgebung direkt auf die Hardware zugreifen zu können, gibt es bei KVM zwei Möglichkeiten:

• Der Zugriff über ein emuliertes Device ist vor allem bei
  Netzwerk- und Soundkarten, aber auch für Festplattencontroller
  interessant.
• Direkter Zugriff auf ein durchgereichtes PCI-Device.
  Grundsätzlich gilt: Nur Hardware, die der Host nicht
  verwendet, kann Linux an eine virtualisierte Instanz
  weiterreichen.

Daher muss der Admin zuerst die Module entladen oder das Laden per Blacklist unterbinden. Wie es zum Beispiel unter Gentoo üblich ist, empfiehlt es sich generell, die Module beim eigenen Kernel gar nicht erst einzubinden, das spart Platz und bringt Tempo.

Ausschalten: IRQ-Sharing

Ganz wichtig ist es dabei – nicht nur für die Kernelbauer -, die Shared-Interrupt-Funktionalität zu deaktivieren. Im Moment ist KVM nur in der Lage, PCI-Devices mit eigenem Interrupt durchzureichen. Sobald mehrere Geräte den Interrupt nutzen, schlägt das Durchreichen fehl. Um derartige Doppelbelegungen aufzudecken, empfiehlt sich das Scannen der benutzten Interrupts (Listing 1). Die Ausgabe von »lspi -vv | grep IRQ« vergleicht der Admin nun mit dem Gerät, das er durchreichen will (Listing 2). In diesem Beispiel wird das Durchreichen nicht funktionieren, da der Interrupt 11 gleich dreifach belegt ist.

Interrupt: pin D routed to IRQ 10
Interrupt: pin D routed to IRQ 12
Interrupt: pin D routed to IRQ 12
Interrupt: pin ? routed to IRQ 9
Interrupt: pin A routed to IRQ 11
Interrupt: pin A routed to IRQ 12
Interrupt: pin A routed to IRQ 10
Interrupt: pin A routed to IRQ 11
Interrupt: pin A routed to IRQ 11

00:11.0 Network controller: AVM GmbH B1 ISDN
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d800 [size=64]
Region 1: I/O ports at dc00 [size=32]
Kernel driver in use: b1pci
Kernel modules: b1pci
Capabilities: [40] Power Management version 3

Listing 3 zeigt dagegen ein anderes Beispiel, mit einer PCIe-ISDN-4-fach-Karte von Beronet. Deren Interrupt 19 ist nur einmal belegt, und zwar von der ISDN-Karte selbst. Admins von Ubuntu oder Debian tragen in »/etc/modprobe.d/ blacklist.conf« die Module ein, die sie nicht benötigen:

blacklist mISDN_dsp
blacklist hfcmulti
blacklist mISDN_core

Das Beispiel zeigt die Module für die erwähnte aktive HFC4S-Karte, es sind die Treiber für das neue »mISDNv2«-Subsystem, das seit Kernel 2.6.28 Einzug gehalten hat und vor allem für HFC-ISDN-Karten sehr zu empfehlen ist. Für Asterisk ist zusätzlich noch der Channel-Driver »lcr_chan« vom Linux-Call-Router-Projekt [3] erforderlich.

08:04.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01)
Subsystem: Cologne Chip Designs GmbH Device b752
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 5000 [disabled] [size=8]
Region 1: Memory at c6000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: hfc_multi
Kernel modules: hfcmulti

PCI-ID holen

Um eine PCI- oder auch PCIe-Karte an ein virtualisiertes OS durchzureichen – dabei spielt es keine Rolle, ob eine Windows-Variante, Linux oder ein BSD zu Gast ist -, benötigt der Admin zunächst die PCI-ID. Die lässt sich bequem mit Lspci

[...]
00:11.0 Network controller: AVM GmbH B1 ISDN

ermitteln und an KVM als Startparameter übergeben (Abbildung 1).

Abbildung 1: Nachdem er mit Lspci etwaige Interrupt-Doppelbelegungen ausgeschlossen hat, startet der Admin das KVM-Image. 2 GByte Speicher sind mehr als genug für die Knoppix-Version 6.3. Ihr hat der Host eine PCI-Netzwerkarte durchgereicht, auf Wunsch kann er auch deren MAC-Adresse bestimmen.

Das sollte auf allen Plattformen so funktionieren, wenn der Admin einige grundlegende Regeln beachtet, etwa dass zum Beispiel auch virtualisierte Linux-Derivate Arbeitsspeicher brauchen. Wer den »-m« Parameter nicht angibt, bei dem geht KVM von der Standard-RAM-Größe von 128 MByte aus, die für Windows XP auf jeden Fall, aber auch für manche Linux-Distributionen deutlich zu knapp ist. Fedoras Installer und Yast haben meist Probleme, wenn ihnen nicht mindestens 256 MByte zur Verfügung stehen.

Anwendern mit speichermäßig ausgelasteten Virtualisierungsservern hilft da bald Kernel Samepage Merging (KSM, [4]), das die belegten RAM-Pages fortlaufend scannt und bei Übereinstimmungen diese nur einmal im Speicher ablegt. Vor allem Red Hat, neuer Besitzer von Qumranet, und Fedora entwickeln aktiv weiter.

Wer KVM mit durchgereichten PCI-Devices unter Debian verwenden will, findet das Ganze noch ein wenig komplizierter vor. In den Repositories von Lenny liefert eine Versionsabfrage mit »kvm -version« noch die veraltete Version 77, Squeeze und Ubuntu 9.1 kommen mit 0.11.1.

Debian und Fritz

Die Pakete für I-386 oder AMD64 gibts per Download vom Debian-Server. Anschließend installiert Root sie mit »dpkg -i«. Wer zuvor eine ältere Version installiert hatte, muss keine weiteren Probleme mit Abhängigkeiten haben.

Eine Erfolgsmeldung sollte »qemu-kvm –help« liefern (Listing 4). Nun kann auch auf Debian die erste Verleih-Aktion beginnen. Wer bereits eine ISDN-Fritz-Karte installiert hat, kennt das Problem: Es gibt nur RPM-Pakete für Suse, die mühsam anzupassen sind. Je neuer der Debian-Kernel, desto schwieriger die Beseitigung der Compiler-Beanstandungen. Das folgende Beispiel setzt eine Capisuite-Fax-Anrufbeantworter-Lösung auf Debian Etch auf, bei dem Module und Compiler unproblematisch sind, weil das System noch mit einem Kernel 2.6.18 läuft. KVM startet den Gast im Hintergrund und stattet ihn mit einer eigenen IP-Adresse für den SSH-Zugang aus.

# kvm --help
QEMU PC emulator version 0.10.50 (qemu-kvm-devel-88), Copyright (c) 2003-2008 Fabrice Bellard
usage: qemu [options] [disk_image]
[...]
-pcidevice host=bus:dev.func[,dma=none][,name=string] expose a PCI device to the guest OS.
           dma=none: don't perform any dma translations (default is to use an iommu) 'string' is used in log output.

Nach der Installation eines Standardsystems braucht der Gast noch die Pakete »build-essential«, »rpm« und »capiutils« sowie die Header. Eine detaillierte Anleitung zur Installation gibt [5]. Auch die Fritz-Card-Treiber gehören ins Gast-System. Weil in der Regel der Host diese noch exklusiv nutzt, zu allem Übel mit dem Steinzeit-Modul Hisax, ist die eingangs erwähnte Blacklist erforderlich. Die folgenden beiden Zeilen reichen in »/etc/modprobe.d/blacklist.conf«:

blacklist hisax_fcpcipnp
blacklist hisax

Jetzt ignoriert der Host diese Treiber, der Gast erkennt die neue Hardware erst, wenn KVM ihn informiert. Dabei ist auch der Gast zuerst der Meinung, Hisax wäre das geeignete Modul. Damit das nicht passiert, legt der Admin unter Etch das File »/etc/modprobe.d/blacklist-capisuite« an, dessen Inhalt ist identisch mit dem erwähnten Eintrag in der »blacklist.conf«. Beim Start von »kvm« übergibt der Admin noch die Device-ID auf der Kommandozeile. Das Gastsystem sollte jetzt das geladene Modul laden:

gast # lsmod | grep fcpci
fcpci   592768  1
kernelcapi      43680   2       capi,fcpci

Auch zeigt Capiinfo jetzt eine einsatzbereite PCI Karte im Gast (Listing 5). Der Konfiguration von Capisuite als Faxserver und Anrufbeantworter steht nun nichts mehr im Weg.

Number of Controllers : 1
Controller 1:
Manufacturer: AVM GmbH
CAPI Version: 2.0
Manufacturer Version: 3.11-07  (49.23)
Serial Number: 1000001
BChannels: 2
Global Options: 0x00000039
   internal controller supported
   DTMF supported
   Supplementary Services supported
   channel allocation supported (leased lines)

Im Hintergrund

Im Produktivbetrieb ist keine eigene Shell für das virtuelle System mehr notwendig, der Gast kann vollkommen headless als Hintergrundprozess laufen, die Adminis- tration erfolgt per SSH:

# qemu-kvm -m 1024 -net nic,vlan=0,macaddr=00:80:ad:11:11:11 -net tap -pcidevice host=05:06.0 -nographic -daemonize etch.img

Um dem virtuellen System per DHCP eine statische IP-Adresse zuweisen zu können, übergibt der Admin beim Start eine virtuelle MAC-Adresse, die am DHCP-Server für dieses System reserviert ist.

Das letzte Beispiel verlagert zusätzlich zur ISDN-Karte auch gleich eine DVB-T-Karte ins Gastsystem, die als digitaler Videorecorder mit VDR zum Einsatz kommt. Dabei empfiehlt sich allerdings auch eine eigene Festplatte, die die umfangreichen Daten der Aufzeichnungen aufnimmt [6]. Wie in den vorangegangen Beispielen entzieht der Admin dem Host den Zu- griff auf die DVB-Karte und trägt die Treiber »dvb_ttpci«,»stv0299«,»saa7146vv« und »saa7149« aus Listing 6 in »/etc/modprobe/blacklist.conf« ein. Bei den meisten DVB-Karten reichen die Kernelmodule nicht, sie erwarten noch Firm- ware in »/lib/firmware«. Und zu guter Letzt braucht KVM die PCI-Device-ID der DVB-Karte, in diesem Beispiel listet Lspci den Philips-Chip SAA7146 als »05:07.0«.

dvb_ttpci             104576  18
dvb_core               99120  2 stv0299,dvb_ttpci
saa7146_vv             49920  1 dvb_ttpci
saa7146                19160  2 dvb_ttpci,saa7146_vv
ttpci_eeprom            2672  1 dvb_ttpci
i2c_core               26736  7 nvidia,stv0299,ves1x93,dvb_ttpci,videodev,ttpci_eeprom,i2c_piix4

PCI-Hotplug in KVM

Auch während des Betriebs kann der Admin dem Gast weitere PCI-Geräte aufzwingen. Das übernimmt die weniger bekannte Qemu-Monitor-Konsole, die aus dem Gast-Window heraus einfach per Tastenkürzel [Ctrl]+[Alt]+[2] erreichbar ist.

In klassischem Weiß auf schwarzem Grund stehen dem Benutzer hier zahlreiche praktische Befehle zur Verfügung. Detaillierte Dokumentation bietet [7] und wer am Prompt »help« eingibt, findet Informationen zur Syntax und den erlaubten Befehlen. Ein »info pci« listet alle der virtuellen Instanz bekannten PCI-Devices auf, mit »pci_add« fügt der Admin ein Gerät hinzu, zum Beispiel die nächste Ethernet-Karte:

(qemu) pci_add auto nic model=e1000
OK domain 0 bus 0 slot 9 function 0
(qemu)

Analog zur Syntax von KVM kann der Admin hier auch mit »host=« die PCI-ID des Gastgebers angeben. Damit das gut funktioniert, müssen im Gastsystem die Kernelmodule »acpiphp« und »pci_hotplug« geladen sein. Dann zeigt ein »dmesg« ausführliche Informationen über die neu angekommenen PCI-Geräte und die Liste von »lspci« wird immer länger. Damit nicht genug, in der Qemu-Konsole lassen sich auch fast beliebig Laufwerke, USB- und Storage-Devices hinzufügen oder entfernen. Nach getaner Arbeit lan- det der Benutzer mit [Ctrl]+[Alt]+[1] wieder im vertrauten KVM-Fenster.

Hardware satt

Der Gast ist nun bestens ausgestattet und hat außerdem exklusiven Zugriff auf physikalische Hardware (Listing 7). Was Insider und Forensiker [8] schon lange schätzen, wird damit auch in anderen Bereichen immer interessanter: Administratoren steuern Speziallösungen in geschützten Systemen, technikbegeisterte Anwender betreiben Videorecorder im Hintergrund. Wem das immer noch nicht reicht, der wartet auf Vias Nano und träumt von stromsparenden Embedded-Systemen, auf denen Windows und Linux parallel laufen. (mfe)

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20)
00:04.0 RAM memory: Unknown device 1af4:1002
00:05.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02)
00:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)