qemu, kvm, xen & libvirtHauptseite | Über | Hilfe | FAQ | Spezialseiten | Anmelden

Druckversion | Impressum | Datenschutz

Paravirtualisierte Gerätetreiber, virtio, virtio_pci, VirtFS, Plan 9 Resource Sharing for Linux, virtio_ring, virtio_net, virtio_blk, virtio_balloon, Memory Balloning

(Link zu dieser Seite als [[QEMU-KVM-Buch/ Virtuelle Hardware/ Paravirtualisierte Gerätetreiber]])

<<<|###| >>> | English


Inhaltsverzeichnis

[bearbeiten] Paravirtualisierte Gerätetreiber für die Gast-Systeme

Die Kernel-based Virtual Machine unterstützt normalerweise nicht die Paravirtualisierung. Der Einsatz von paravirtualisierten Gerätetreibern ist aber über die Schnittstelle virtio möglich. Diese Geräte stellt QEMU bereit. Die Gast-Systeme benötigen die entsprechenden virtio-Treiber. Diese Treiber sind vergleichbar mit den VMware-Tools bei VMwares ESX. Die Vorteile der virtio-Treiber sind der geringere Overhead und die höhere Performance. Erst die Verfügbarkeit von Hardware-Erweiterungen, wie IOMMU, machen den Einsatz von paravirtualisierten Gerätetreibern überflüssig.

[bearbeiten] Treiber für Microsoft Windows

Download: http://www.linux-kvm.com/content/tip-how-setup-windows-guest-paravirtual-network-drivers

Für Microsoft Windows 2000/XP wird ein spezieller Netzwerktreiber angeboten. Dieser ist im Gast-System zu installieren. Bei der Optionen -net nic ist der Parameter model=virtio hinzuzufügen.

Host ~$ qemu-system-x86_64 Platte.img -net nic,model=virtio....

[bearbeiten] Virtio-Module für Linux

Virtio ist ein Paravirtualisierungs-Interface, mit dem nur ein Satz von Gast-Treiber entwickelt werden muss. Diese Treiber können von mehreren Virtualisierungslösungen verwendet werden. Diese paravirtualsierten Gerätetreiber sind nur für Linux-Gast-Systeme mit einer Kernel-Version ab 2.6.25 verfügbar. Die meisten Linux-Distributionen enthalten virtio-Treiber, die automatisch bei vorhandenen virtio-Geräten im Gast-System aktiviert werden.

[bearbeiten] Memory Ballooning (virtio_balloon)

Mit Memory Ballooning bezeichnet man die Größenänderung des Arbeitsspeichers des laufenden Gast-Systems. QEMU und die Kernel-based Virtual Machine unterstützen das Memory Ballooning nur für Linux-Gäste. Auf dem Host-System muss ein Kernel ab der Version 2.6.27 installiert sein. Aktiviert wird das Memory Ballooning mit der Option -balloon virtio[,addr=str]. Optional kann mit addr die PCI-Device-Adresse vorgegeben werden.

Host ~$ qemu-system-x86_64 Platte.img -balloon virtio

Auf dem Gast-System ist das Kernel-Modul virtio_balloon zu laden.

Gast ~# modprobe virtio_balloon

Im QEMU-Monitor ermittelt und ändert man die Größe des Arbeitsspeichers. Eine Vergrößerung des Arbeitsspeichers über den mit der Option -m vorgegebenen Wert ist nicht möglich. Im folgenden Beispiel wird die Größe des Arbeitsspeichers von 512 MByte RAM auf 256 MByte RAM verringert.

(qemu) info balloon
balloon: actual=512
(qemu) balloon 256
(qemu) info balloon
balloon: actual=256

Die Größe des Arbeitsspeichers kann im Gast-System mit dem Befehl free kontrolliert werden.

Gast ~$ free
      total ...
Mem: 252292 ...

Mit der Option -balloon none wird das Memory Ballooning deaktiviert.

Host ~$ qemu-system-x86_64 Platte.img -balloon none

[bearbeiten] Paravirtualisierte Netzwerkkarten (virtio_net)

Im Gast-System müssen folgende Module geladen werden: virtio, virtio_pci, virtio_ring, virtio_net und virtio_blk. Dazu muss der Option -net nic der Parameter model=virtio hinzugefügt werden.

Host ~$ qemu-system-x86_64 Platte.img -net nic,model=virtio -net tap,ifname=tap01

[bearbeiten] Paravirtualisierte Block-Devices (virtio_blk)

Paravirtualisierte Block-Devices werden mit der Option -drive ... if=virtio aktiviert.

Host ~$ qemu-system-x86_64 -drive file=Platte.img,if=virtio,boot=on

Im Gast-System überprüft man, ob die entsprechenden Module geladen wurden.

Gast ~$ lsmod | grep virtio
virtio_blk             16392  0 
virtio_pci             17668  0 
virtio_ring            12928  1 virtio_pci
virtio                 14336  3 virtio_blk,virtio_net,virtio_pci

Bei Verwendung von Virtio Block Devices sollte im Linux-Gast das File-System ext3 verwendet werden. Das File-System XFS ist nicht zu empfehlen, da es ein intensives Write-Caching betreibt. Bei einem plötzlichen Ausfall der virtuellen Maschine kann dies zu Problemen führen.

[bearbeiten] Shared Folder mit VirtFS

Einen Datenaustausch zwischen Host- und Gast-System ermöglichen gemeinsame Verzeichnisse (Shared Folder) mit VirtFS. VirtFS nutzt Plan 9 Resource Sharing for Linux (9P, http://sourceforge.net/projects/v9fs/) mit Virtio. Das Host-System benötigt dazu einen Kernel ab Version 2.6.36 mit aktivierten 9P-Optionen:

CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_DEBUG=y (Optional)
CONFIG_9P_FS=y
CONFIG_9P_FS_POSIX_ACL=y

Weiterhin werden die Pakete libattr1 und libattr1-dev (Debian/Ubuntu) beziehungsweise libattr und libattr-devel (Red Hat, Fedora) benötigt. Mit der Option -fsdev wird 9P unter QEMU (ab 0.15) aktiviert.

Die Option -fsdev wird zusammen mit der Option -device virtio-9p-pci verwendet. Die mit der Option ID -device virtio-9p-pci angegebenen ID muss gleich der mit -fsdev definierten ID sein. Der Tag-Name wird im Gast-System beim Einbinden des Shared-Folder angegeben. In diesem Beispiel wird das Verzeichnis /tmp dem Gast-System als gemeinsamer Ordner zur verfügung gestellt.

Host ~$ qemu-system-x86_64 Platte.img \
 -fsdev local,id=austausch,path=/tmp/,security_model=none \
 -device virtio-9p-pci,fsdev=austausch,mount_tag=mymount

Alternativ ist mit der Option -virtfs eine kürzere Schreibweise möglich.

Host ~$ qemu-system-x86_64 Platte.img \
 -virtfs local,path=/tmp/,security_model=none,mount_tag=mymount

Im Gast-System (Linux) wird das Laden der entsprechenden Kernel-Module überprüft. Es wird ein Verzeichnis für den Mount-Point angelegt. Anschließend wird das per 9P zur Verfügung gestellte Verzeichnis im Gast-System eingebunden. Zum Test wird im Gast-System eine Datei mit touch angelegt.

Gast ~# lsmod | grep virtio
9pnet_virtio           13171  1 
9pnet                  57184  2 9p,9pnet_virtio
virtio_pci             17630  0 
virtio_ring            14538  2 9pnet_virtio,virtio_pci
virtio                 14141  2 9pnet_virtio,virtio_pci
Gast ~# mkdir /tmp/shared/
Gast ~# mount -t 9p -o trans=virtio mymount /tmp/shared/ -oversion=9p2000.L
Gast ~# touch /tmp/shared/Test-Datei

Im Host-System erscheint die im Gast-System angelegte Test-Datei.

Host ~$ ls -l /tmp/Test-Datei 
/tmp/Test-Datei

Die allgemeine Syntax zur Definition von Dateisystem-Devices ist -fsdev fsdriver,id=id [,options]. Jedem Device muss mit id eine Zeichenkette zugeordnet werden. Diese dient zur eindeutigen Identifizierung. Je nach Art des Devices (fsdriver) sind bestimmte Optionen anzuwenden.

-fsdev fsdriver,id=id,path=path                 \
     [,security_model=mapped|passthrough|none]  \
     [,writeout=immediate][,readonly]
     fsdriver
Mit dieser Option wird der Datei-System-Treiber des Backends spezifiziert. Derzeit werden local und handle unterstützt.
     path
Definiert den zu exportierenden Pfad. Diese Angabe ist zwingend.
     security_model=[mapped|passthrough|none]
Definiert das zu verwendende Sicherheitsmodell. Diese Angabe ist zwingend bei dem Datei-System-Treiber local. Andere Datei-System-Treiber, wie zum Beispiel handle, unterstützen diesen Parameter nicht.
     security_model=mapped
Der VirtFS-Server (QEMU) fängt alle Anfragen zum Anlegen von Datei-Objekten ab und generiert die Dateien auf dem File-Server mit den Rechten des QEMU-Benutzers. Die Rechte des Clients werden stattdessen in erweiterte Attribute gespeichert. Mit getattr() extrahiert der Server die Datei-Rechte des Clients und sendet diese zum Client. Da nur die erweiterten Attribute im User Space für reguläre Dateien verfügbar sind, werden Special-Dateien als reguläre Dateien auf dem File-Server abgelegt. Die entsprechenden Mode-Bits werden als xattrs gespeichert und mit getattr wieder extrahiert. Wenn die erweiterten Attribute fehlen, sendet der Server unverändert das stat() des Datei-Systems. Damit werden die Rechte der Dateien für den Client bestimmt. Dabei ist folgendes zu beachten: Das Datei-System wird entsprechend VirtFS verwendet. Andere Datei-Systeme verstehen möglicherweise diese Datei-Rechte nicht. Geläufige Werkzeuge, wie zum Beispiel df, geben falsche Informationen aus. Notwendig sind spezielle Werkzeuge, die dieses Sicherheits-Modell verstehen.
     security_model=passthrough
In diesem Sicherheits-Modell reicht der VirtFS-Server alle Anfragen zum Anlegen von Datei-Objekten an das darunterliegende Datei-System weiter. Die Dateien werden mit den Anmeldeinformationen des Clients angelegt. Dies erfolgt mit setuid()/setgid() während des Anlegens der Datei. Als Resultat erhalten diese Dateien die UID/GID des Clients. Dabei ist folgendes zu beachten: Der File-Server muss unter dem Benutzer root laufen. Root Squashing kann erforderlich sein. Dies wird in Zukunft realisiert. Es sind Konflikte zwischen den User Space IDs des Gastes und den User Space IDs des Hosts möglich. Weiterhin werden Attribute des Sicherheits-Modell zum -fsdev device und zum -virtfs shortcut hinzugefügt.
     writeout=immediate
Dieses optionale Argument unterstützt nur den Wert immediate. Dabei wird der Host-Page-Cache für Schreib- und Lesevorgänge verwendet. Die Schreibbestätigungen werden aber nur zum Gast-System gesendet, wenn das Storage-Subsystem den Schreibvorgang erfolgreich bestätigt haben.
     readonly
Der 9P-Share-Folder wird für das Gast-System schreibgeschützt exportiert.

Die allgemeine Syntax zum Exportieren von Dateisystemen als virtuelle Dateisysteme ist -virtfs fsdriver[,options]. Je nach Art des Devices (fsdriver) sind bestimmte Optionen anzuwenden.

-virtfs fsdriver,path=path,mount_tag=mount_tag   \
     [,security_model=mapped|passthrough|none]   \
     [,writeout=immediate][,readonly]
     fsdriver
Mit dieser Option wird der Datei-System-Treiber des Backends spezifiziert. Derzeit werden local und handle unterstützt.
     path
Definiert den zu exportierenden Pfad. Diese Angabe ist zwingend.
     security_model=[mapped|passthrough|none]
Definiert das zu verwendende Sicherheitsmodell. Diese Angabe ist zwingend bei dem Datei-System-Treiber local. Andere Datei-System-Treiber, wie zum Beispiel handle, unterstützen diesen Parameter nicht.
     security_model=mapped
Der VirtFS-Server (QEMU) fängt alle Anfragen zum Anlegen von Datei-Objekten ab und generiert die Dateien auf dem File-Server mit den Rechten des QEMU-Benutzers. Die Rechte des Clients werden stattdessen in erweiterte Attribute gespeichert. Mit getattr() extrahiert der Server die Datei-Rechte des Clients und sendet diese zum Client. Da nur die erweiterten Attribute im User Space für reguläre Dateien verfügbar sind, werden Special-Dateien als reguläre Dateien auf dem File-Server abgelegt. Die entsprechenden Mode-Bits werden als xattrs gespeichert und mit getattr wieder extrahiert. Wenn die erweiterten Attribute fehlen, sendet der Server unverändert das stat() des Datei-Systems. Damit werden die Rechte der Dateien für den Client bestimmt. Dabei ist folgendes zu beachten: Das Datei-System wird entsprechend VirtFS verwendet. Andere Datei-Systeme verstehen möglicherweise diese Datei-Rechte nicht. Geläufige Werkzeuge, wie zum Beispiel df, geben falsche Informationen aus. Notwendig sind spezielle Werkzeuge, die dieses Sicherheits-Modell verstehen.
     security_model=passthrough
In diesem Sicherheits-Modell reicht der VirtFS-Server alle Anfragen zum Anlegen von Datei-Objekten an das darunterliegende Datei-System weiter. Die Dateien werden mit den Anmeldeinformationen des Clients angelegt. Dies erfolgt mit setuid()/setgid() während des Anlegens der Datei. Als Resultat erhalten diese Dateien die UID/GID des Clients. Dabei ist folgendes zu beachten: Der File-Server muss unter dem Benutzer root laufen. Root Squashing kann erforderlich sein. Dies wird in Zukunft realisiert. Es sind Konflikte zwischen den User Space IDs des Gastes und den User Space IDs des Hosts möglich. Weiterhin werden Attribute des Sicherheits-Modell zum -fsdev device und zum -virtfs shortcut hinzugefügt.
     writeout=immediate
Dieses optionale Argument unterstützt nur den Wert immediate. Dabei wird der Host-Page-Cache für Schreib- und Lesevorgänge verwendet. Die Schreibbestätigungen werden aber nur zum Gast-System gesendet, wenn das Storage-Subsystem den Schreibvorgang erfolgreich bestätigt haben.
     readonly
Der 9P-Share-Folder wird für das Gast-System schreibgeschützt exportiert.

[bearbeiten] Syntetische Datei-System-Images

Mit der Option -virtfs_synth generiert man ein synthetisches Datei-System-Image mit dem Mount-Tag v_synth.

Host ~$ qemu-system-x86_64 Platte.img -virtfs_synth

Im diesem Beispiel wird im Gast-System das synthetische Datei-System-Image unter /tmp/synth eingebunden.

Gast ~# mount -t 9p -oversion=9p2000.L,trans=virtio v_synth /tmp/synth/


<<<|###| >>>

Von „http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Virtuelle_Hardware/_Paravirtualisierte_Ger%C3%A4tetreiber

Diese Seite wurde bisher 49.385 mal abgerufen. Diese Seite wurde zuletzt am 29. Dezember 2012 um 13:31 Uhr geändert. Inhalt ist verfügbar unter der GNU Free Documentation License 1.2.


Finden

Blättern

News

Deutsch
Weitersagen
Bestellen
Tipps für Autoren
Autoren
Impressum


English
Order
Recommendation
The Authors
Contact



Letzte Änderungen
Twitter


Ändern
Seite bearbeiten
Bearbeitungshilfe
Seitenoptionen
Diskussion
Kommentar hinzufügen
Druckversion
Seitendaten
Versionen
Links auf diese Seite
Änderungen an verlinkten Seiten
Meine Seiten
Anmelden
Spezialseiten
Neue Seiten
Dateiliste
Statistik
Kontakt
Mehr …