XEN 4.0

Aus Neobikers Wiki
Zur Navigation springen Zur Suche springen

XEN 4.0 Entwicklung

Xen 4.0 released mit vielen neuen Features, einige sind für SOHO interessant und viele weitere professionelle Features für Datacenter. Der wichtigste Meilenstein ist sicher der Pv-Ops Kernel, der erstmals den XEN Kernel wieder näher an die aktuelle Linux Kernel Entwicklung heranbringt. Die Integration in den Standardkernel sollte in einer der nächsten Version hoffentlich bald erfolgen. Damit wird der zwischenzeitlich entstandene Versionsmix bei der Konfiguration und den Funktionen dann endlich wieder reduziert.

XEN Konfigurations- und Funktionsübersicht
Kernel Version XEN Dom0 Disk / Console Features
XENlinux (XEN.org) 2.6.18 3.0 Ja hda / xvc0 Alle
Linux Standard (kernel.org) 2.6.23 3.0 Nein xvda / hvc0 Wenig
XENlinux Patches (SuSE) 2.6.27; 2.6.34 3.0 Ja xvda / xvc0 Alle
PV-Ops (XEN.org) 2.6.32 4.0.1 Ja xvda / hvc0 Viele (kein pvusb,pvscsi)
Linux Standard (kernel.org) 2.6.36 4.0.1 Nein xvda / hvc0 Viele (kein pvusb,pvscsi)
Linux Standard (kernel.org) 2.6.41 ? 4.2 ? Ja xvda / hvc0 Viele (pvusb?,pvscsi?)

Kurze Historie: Der XEN Kernel ist über 4 Jahre alt und basiert auf Version 2.6.18. Sämtliche XEN Funktionen mit dieser Version entwickelt und stehen als Patches zur Verfügung. Seit Version 2.6.23 unterstützt der Standard Linux Kernel den Betrieb als XEN Gastsystem (DomU), allerdings nur mit wenigen zum Betrieb erforderlichen Funktionen z.B. für Netzwerk, Storage und Console.

Pv-Ops ist eine im Kernel integrierte (Infrastruktur-) Schnittstelle, die dem Kernel den paravirtualisierten Betrieb des Linux Kernels auf entsprechendem Hypervisoren wie XEN oder KVM ermöglicht. Diese Schnittstelle ermöglicht seit Kernel 2.6.23 den Betrieb als XEN Gastsystem (DomU), nicht aber als Hostsystem (Dom0).

Der XEN Pv-Ops Kernel wird seither stetig erweitert, mit Version 2.6.32 standen erstmals die notwendigen Funktionen zur Verfügung, welche den Betrieb als Dom0 ermöglichten. Andere neue XEN Funktionen wie PV-USB und PV-SCSI wurden noch nicht portiert und stehen auf der weiterhin vorhandenen ToDo List zur Integration in den Standard Kernel.

Einige XEN Aspekte haben sich inzwischen geändert:

  • Die CPU muss PAE unterstützen (ab Pentium Pro, AMD Athlon)
  • 32-Bit Kernel müssen PAE enabled sein (64-Bit nicht) und HighPTE disabled
  • ACPI Support muss aktiviert sein
  • Die Console ist jetzt /dev/hvc0 anstatt /dev/xvc0
  • Virtuelle Disk devices sind jetzt /dev/xvdX
  • Pv-Ops Kernel kann man erst ab XEN Version 3.4.3 bzw. 4.0 als Dom0 starten
  • Pv-Ops Kernel neuer als 2.6.32.25 können erst ab Version 4.0.1 verwendet werden
  • Die Optionen CONFIG_SYSFS_DEPRECATED und CONFIG_SYSFS_DEPRECATED_V2 helfen, wenn der Bootprozess hängen bleibt (Redhat/Centos based Distributionen)

Grub Konfiguration für den Dom0 Betrieb: 

title        Xen 4.0.1, dom0 Linux kernel 2.6.32.25
root         (hd0,0)
kernel       /boot/xen-4.0.1.gz dom0_mem=512M
module       /boot/vmlinuz-2.6.32.25 root=/dev/sda1 ro nomodeset
module       /boot/initrd.img-2.6.32.25

Die Option nomodeset ist für die korrekte Funktion der Grafiktreiber unter XEN oftmals hilfreich, ebenso sollte mindestens die Version 4.0.1 von XEN verwendet werden, um Probleme mit älteren Kernelversion von vornherein zu vermeiden.

XEN 4.0 Features

SOHO:

  • Pv-Ops Domain 0 (use actual Linux kernels in Dom0)
  • PV-USB: Kernel Paravirtual high-performance USB passthru to both PV and HVM guests (XenLinux Kernel, Pv-Ops noch nicht)
  • Pygrub improvements
    • Support for PV guests using GRUB2
    • Support for guest /boot on ext4
  • VGA primary graphics card GPU passthru support to an HVM guest

Datacenter:

  • High availability (RAS: reliability, availability and serviceability)
    • physical cpu/memory hotplug
  • Fault toleranz (live transactional synchronization of VM states between physical servers)
  • Better performance and scalability
    • Blktap2 (vhd, live snapshots, cloning)
    • Netchannel2 (advancements in networking hardware such as SMART NICs with multi-queue and SR-IOV functionality)
    • Page sharing
    • Transcendent Memory
    • TMEM allows improved utilization of unused (for example page cache) PV guest memory
    • Improved IOMMU PCI passthru (Intel VT-d and AMD IOMMU)
  • Libxenlight (libxl): a new C library providing higher-level control of Xen that can be shared between various Xen management toolstacks.

XEN 4.0 bringt einige allgemeine Verbesserungen, z.B. für Performance und Skalierbarkeit. Hierzu zählt der neue Blktap2 Treiber für virtuelle Disks, welcher jetzt neben Copy-On-Write (QCow2) auch das VHD-Image Format mit Live-Snapshots und Disk Cloning unterstüzt. Im Netzwerkbereich ist das Pendant dazu der Netchannel2 Treiber mit besserer Performance und Support für neuere Netzwerkfunktionen wie Smart-NICs, Multi-Queues und SR-IOV. Mit Kernel Version 2.6.36 wurde der PV-On-HVM Treiber in den Standardkernel aufgenommen, der den performanten Gastbetrieb von Linux ohne die Qemu-Emulation von Netzwerk- und Disktreibern ermöglicht.

blktap2 und netchannel2 Konfiguration: 

disk = [ "tap2:tapdisk:aio:/path/images/disk.img,xvda,w" ]
disk = [ "tap2:tapdisk:vhd:/path/images/disk.vhd,xvda,w" ]
disk = [ "tap2:qcow2:/path/images/disk.qcow2,xvda,w" ] 
vif2 = [ 'bridge=eth1' ]

Das vhd-util tool kann verwendet werden, um VHD Images zu erzeugen: 

       vhd-util create -n MyVHDFile -s 1024

kreiert ein 1GB Sparse Image-File, während 

       vhd-util snapshot -n MyVHDFile -p SomeRawFile -m

mittels Copy-On-Write Technik die Nutzung von Master- oder auch Read-Only Images ermöglicht und alle Änderungen im VHD-Images speichert. Das Tool bietet noch weitere Möglichkeiten, wie z.B. den Live Snapshot von VHD-Image Files. Durch Anhalten (pausieren) von Gästen kann man mit Blktap2 ganz einfach und risikolos Snapshots erzeugen. Für Qcow-Image Files findet man ein Beispielscript xmsnap im Verzeichnis tools/blktap2/drivers.

Windows HVM Gastsysteme können jetzt den zertifizierten 64-Bit PV-Treiber von Citrix auch auf einem Standard XEN System nutzen. Dieser steht nur für den Xenserver (bzw. dessen Opensource Version XCP = XEN Cloud Projekt) zur Verfügung. Damit dieser unter Standard XEN läuft, muss in der Registry nach der Treiberinstallation vor dem Reboot folgender Registryschlüssel eingetragen werden [1]: 

HKLM\System\CurrentControlSet\Services\xenevtchn\Parameters\SetFlags = 0x10000000 (DWORD)

Der paravirtualisierte USB-Support mittels PVUSB unterstützt jetzt auch USB V2.0 und vollvirtualisierte Gäste (HVM). Leider ist diese Funktionalität aktuell noch nicht in die neuen Pv-Ops Kernel portiert worden und steht daher bisher nur in XenLinux Kerneln zur Verfügung. Die Konfiguration wurde durch den Befehl xm bzw. den neuen Parameter vusb im Konfigurationsfile vereinfacht und entspricht jetzt der bekannten Syntax. Der Gastkernel muss den PVUSB Frontend Treiber verwenden, die Dom0 den PVUSB Backend Treiber installiert haben. Die für Windows Gäste verfügbaren GPLPV Treiber von James Harper beinhalten einen (älteren?) PVUSB frontend Treiber.

Beim booten von Gastsystem werden die virtuellen USB-Hostcontroller und -ports jetzt anhand des Konfigurationsfiles automatisch angelegt. Konfigfile Eintrag für PVUSB: 

vusb= [ „usbver=2, numports=8, port_1=1-1, port_2=1-2‟ ]

   vusb                enable PVUSB
   usbver              USB Spec Version ( 1|2  default:2)
   numports            number of root ports
   port_1 to port_16   physical busidto be assigned (only use 15!)

Anzeige verfügbarer/verbundener USB-Devices 

xm usb-list-assignable-devices
xm usb-list <Domain>

Erzeugen/Entfernen eines virtuellen USB-Hostcontrollers 

xm usb-hc-create  <Domain>  <USBSpecVer>  <NumberOfPorts>
xm usb-hc-destroy <Domain>  <DevId>

Verbinden/Lösen eines USB Devices 

xm usb-attach <Domain> <DevId> <PortNumber> <BusId>
xm usb-detach <Domain> <DevId> <PortNumber>

    <Domain>        domain name
    <USBSpecVer>    2=USB2.0     1=USB1.1 
    <NumberOfPorts> number of root ports (1 bis 16)
    <PortNumber>    Port number of the virtual host controller (1 bis <NumberOfPorts>)
    <DevId>         Device Id of virtual host controller (normalerweise 0)
    <BusId>         Physical USB device path (Ausgabe von usb-list-assignalble-devices: 1-1)

Alternativ kann man natürlich auch den ganzen USB-Controller mit allen angeschlossenen USB-Geräten in einem Gassystem verwenden, indem das komplette PCI-Device mittels PCI passthrough in die virtuelle Maschine hineingereicht wird. Hierbei können sämtliche angeschlossenen USB-Devices nur in einer einzigen VM genutzt werden. PCI passthrough teilt sich genauso in einen Frontend Treiber im Gastsystem und einen Backend Treiber im Hostsystem auf.

Traditionell haben XEN Gastsysteme volle Kontrolle inklusive DMA Zugriff auf deren PCI-Devices. Neuere Hardware mit IOMMU Funktionalität (Intel VT-d oder AMD IOMMU) kann den sichereren IOMMU Modus verwenden. Für DMA Zugriff auf PCI Devices muss swiotlb in dem Gastsystem aktiviert werden. Man erreicht dies durch die Kernel Boot Option swiotlb=force, diese ist bei allen Gastkernelversionen (Xenlinux, Linux.org und Pv-Ops Kernel) zu verwenden. Pv-Ops Kernel müssen zusätzlich den Kernel Bootparameter iommu=soft setzen.

DMA Zugriff auf PCI Geräte im Gastsystem 

extra='swiotlb=force iommu=soft'

HVM Gastsysteme erfordern in jedem Fall Hardware mit IOMMU Funktion um PCI-Devices direkt ansprechen zu können. Seit Xen 4.0 ist IOMMU im Hostsystem standardmässig aktiviert. Mit xm dmesg kann man überprüfen, ob die eigene Hardware IOMMU ("IO virtualization enabled") unterstützt.

Leider unterstützen viele BIOS diese Funktion nicht fehlerfrei, sodass trotzdem nicht sichergestellt ist, dass diese Funktionalität tatsächlich genutzt werden kann. Das betrifft insbesondere auch die Möglichkeit die Grafikkarte eines XEN 4.0 Systems dediziert einem einzelnem Gastsystem zuzuordnen ('VGA passthrough). Die PCI-Devices dürfen hierbei nicht im Hostsystem aktiviert sein, das erreicht man z.B. über die Kernel Bootoptionen - die sich in der Syntax wiederum zwischen den verschieden XEN Kernelversionen unterscheiden:

PCI-passthrough Pv-Ops Kernel (xen-pciback): 

module       /boot/vmlinuz-2.6.32.25 root=/dev/sda1 ro nomodeset xen-pciback.hide=(08:05.0)

PCI-passthrough XenLinux Kernel (pciback): 

module       /boot/vmlinuz-2.6.32.25 root=/dev/sda1 ro nomodeset pciback.hide=(08:05.0)

Mit dem Befehl xm pci-list-assignable-devices kann man prüfen, ob und welche Devices man in Gastsystemen direkt verwenden kann. Bleibt zu erwähnen, dass bei Verwendung von PCI passthrough keine Gastsysteme gespeichert oder migriert werden können.

Xen 4.0 kann nur die primäre Grafikkarte einem HVM Gastsystem zur Verfügung stellen, das Hardware Virtualisierung (IOMMU) unterstützt. Vorausgesetzt Hardware und BIOS bereiten keine Probleme, steht damit volle 3D Funktionalität und Performance auf dem Gastsystem zur Verfügung. Die Konfigurationsdatei eines Gastsystems muss folgende Einträge verwenden:

VGA passthrough Konfiguration: 

gfx_passthru = 1
pci = ['yy:zz.n']

Für Maus- und Tastaturanbindung verwendet man in diesem Fall z.B. USB passthrough oder PCI passthrough für dieses Gastsystem. Ein Sharing von Maus/Tastatur der Dom0 wird zukünftig als Erweiterung aus dem XCI Projekt (XEN Client Initiative) einfliessen.

XEN konnte sich als Hypervisor am Markt vor allem beim Cloud Dienstleistern etablieren bzw. sogar durchsetzen, obwohl die Integration in den Kernel lange auf sich warten lies und noch immer nicht abgeschlossen wurde. Laut Ian Pratt's Ausführungen auf der XEN Summit im April 2010 basieren mehr als 80% der Public Clouds auf XEN. Als Grund hierfür ist sicher neben dem excellenten, schlanken, stabilen, performanten und sicheren Hypervisor selbst die Quelloffenheit und die aktive Community zu nennen.

Auf dieser Basis sind zahlreiche oftmals ebenfalls frei entwickelte Managementsysteme für Virtuelle Umgebungen entstanden. Sie sind in 3 Kategorien einzusortieren:

Neben dem Einsatzziel Servervirtualisierung oder Cloud Infrastruktur Management unterscheidet sich hier auch der Toolstack zur Konfiguration und Verwaltung von XEN. Der kommerzielle Xenserver verwendet nicht den Xend Daemon und den Befehl xm, sondern XenAPI mit dem viel mächtigeren Befehl xe zur Konfiguration von XEN.

Man versucht inzwischen durch Entwicklung einer neuen Bibliothek libxenlight eine Schnittstelle zu schaffen, auf der beide / beliebige Managementwerkzeuge aufbauen können. Libxenlight wird mit dem Befehl xl von der Kommadozeile aus bedient, welcher aktuell zu 99% kompatibel zum Befehl xm ist. Diese Bibliothek wird zukünftig auch von XenAPI genutzt, sodass alle Managementwerkzeuge über eine gemeinsam entwickelte und getestete Bibliothek mit XEN kommunizieren.

Ausblick

Neben den Funktionalitäten die für Servervirtualisierung und CloudComputing erforderlich sind, werden aktuell ebenfalls Virtualisierungsfunktionen für Endgeräte vorangetrieben. Hier sind nicht nur die klassischen Clients wie Notebook und Desktop zu nennen, sondern alle Geräte von Server über Appliances inkl. Embedded Devices.

XEN ist hier schon bei einigen Herstellen zum Einsatz gekommen. Hier ist spielt der Opensource Hypervisor XEN seine Stärken aus, da er kostenfrei für viele Platformen zur Verfügung steht, nicht nur für x86 CPUs. Auch wenn heute die Möglichkeiten der Hardwarevirtualisierung noch in den Anfängen stehen, und VGA passthrough heute nur auf sehr wenigen Geräten funktioniert, so werden vor allem im professionellen Bereich die Möglichkeiten der Desktop Virtualisierung zur Verbesserung der Sicherheit und zur Reduzierung der zentralen Administrationsaufwände für Unternehmen zeigen müssen, ob die hohen Erwartungen zu erfüllen sind. Die neuen Konzepte und Ideen sind jedenfalls allesamt interessant und eine schöne Spielwiese zum experimentieren.

Quellen
[1] http://xenbits.xen.org/xen-4.0-testing.hg?rev/be9b8be3c648
[2] http://wiki.xen.org/xenwiki/Xen4.0
Abgerufen von „http://neobiker.de/wiki/index.php?title=XEN_4.0&oldid=934“