58 Au s gA b e 0 5 -20 1 0 A d m i n

wenn auch die einzelnen virtuellen Ma-schinen im Proxmox-Cluster stets einem physischen Server zugewiesen sind. Das übersichtliche Webinterface ermöglicht das Erzeugen und Verwalten virtueller KVM-Maschinen oder von Open-VZ-Con-tainern sowie die Live-Migration virtuel-ler Maschinen von einem Node auf einen anderen (Abbildung 1).

Zwei Optionen

Die Idee, die beiden derzeit populärs-ten freien Virtualisierungstechnologien auf einem einzigen System als Super-Virtualisierungslösung anzubieten, hat Charme, kann doch damit jeder Admin fallabhängig stets die optimale Virtua-lisierungslösung zur Verfügung stellen. Dabei gehört Open VZ [2] zur Klasse der Ressource-Container, während KVM [3] im Zusammenspiel mit einer geeigneten CPU echte Hardwarevirtualisierung bie-tet. Beide Virtualisierungstechnologien ermöglichen für den jeweiligen Einsatz-zweck die zum gegenwärtigen Stand der Technik höchstmögliche Performance für das Gastsystem.

Der Ressource-Container Open VZ kommt in der Regel bei Hostern zum Einsatz, die ihren Kunden virtuelle Linux-Server (V-Server) anbieten. Sie gaukeln dem Gast keine Hardware vor, sondern beruhen auf dem Prinzip, dass jedes Betriebssystem aus Sicht seiner Anwendungen aus ak-tiven Prozessen, einem Dateisystem mit installierter Software, Speicherplatz für Daten sowie einer Reihe von Funktionen zum Zugriff auf Geräte besteht. Auf dem Open-VZ-Host (Node) existieren je nach

Das Proxmox Virtual Environment, kurz VE genannt, ist ein Open-Source-Projekt [1], das eine einfach zu handhabende, Web-basierte Virtualisierungsplattform zur Verfügung stellt, mit deren Hilfe sich Open-VZ-Container oder voll virtu-alisierte KVM-Maschinen aufsetzen und verwalten lassen. Die Entwickler ver-wirklichen nach eigenen Angaben mit Proxmox VE ihre Vision einer in wenigen Minuten aufsetzbaren Virtualisierungs-infrastruktur. Immerhin verwandelt der Bare-Metal-Installer von Proxmox nahezu jeden beliebigen PC in einen leistungs-fähigen Gastgeber für KVM und Open VZ, die beiden populären Open-Source-Virtualisierungstechnologien.Darüber hinaus erlaubt das System den Aufbau von Clustern, die mindestens aus zwei physischen Servern bestehen (siehe Kasten „Cluster-Setup“). Dabei arbeitet stets einer der Server als so genannter Cluster Master, dem sich andere Server als Nodes zuordnen lassen, was zwar streng genommen kein echtes Clustering mit Lastverteilung darstellt. Aber im-merhin erlaubt das Modell das zentrale Verwalten sämtlicher Knoten im Cluster,

Container- und Hardware-Virtualisierung unter einem Dach

Doppelt genähtProxmox ist eine auf Virtualisierung spezialisierte distribution, mit der sich virtuelle server mit Open VZ oder KVm gleichzeitig aufsetzen und verwalten lassen. damit ermöglicht es das komfortable management von Open-VZ-Containern und KVm-Hosts im browser. Thomas drilling

Cluster-setup

Zum Aufsetzen eines Clusters muss der Admin derzeit noch die Kommandozeile bemühen. Proxmox stellt dazu sein PVE Cluster Admi-nistration Toolkit »pveca« zur Verfügung. So lässt sich mitpveca ‑c

der lokale Server zum Cluster Master machen, dessen momentaner Status sich mitpveca ‑l

offenbart. Zum Hinzufügen eines zweiten phy-sischen Servers muss sich der Admin lokal oder via SSH anmelden und dortpveca ‑a ‑h IP des Cluster Master

eingeben, und schon ist der zweite Server Bestandteil des Clusters.

Andr

iy B

ezug

lov,

Fot

olia

Proxmox Virtual ApplianceV i rT uA l i s i e ru n g

59Au s gA b e 0 5 -20 1 0A d m i n

ziellen Gastsystemen wie Windows er-laubt. KVM ist im Gegensatz zu anderen Lösungen wie VMware ESXi oder Citrix Xen Server kostenlos und außerdem seit der Kernelversion 2.6.20 offizieller Be-standteil des Linux-Kernels.

KVM intern

KVM beherrscht zwar für jedes Gastsys-tem – sozusagen als Worst Case Fall-back – das langsame, aber funktionie-rende Emulieren privilegierter Abläufe, bringt aber trotzdem für die meisten Gastsysteme echte Virt-I/O-Treiber mit (PCI Passthrough) und profitiert von den VT-Erweiterungen moderner CPUs. Die KVM-Treiber-CD [4] etwa bietet viele Virt-I/O-Treiber für Windows. Virt-I/O-Treiber für Linux sind in den meisten Distributionen enthalten. Auf dem Host besteht das gesamte KVM-Framework aus dem Gerät »/dev/kvm« sowie drei Kernelmodulen »kvm.ko«, »kvm-intel« beziehungsweise »kvm-amd« für das Ansprechen der VT-Befehlssätze von Intel und AMD. KVM erweitert die beiden Prozessorbetriebsarten User- und Kernel-Mode auf VT-fähigen CPUs um eine Dritte, den Guest-Mode, in dem KVM virtuelle Maschinen startet und ver-waltet, die ihrerseits einen privilegierten

dass privilegierte CPU-Funktionen auf den Hypervisor umgelenkt werden, wozu für das Gastsystem angepasste Treiber (Kernelpatches) erforderlich sind.Die Hardware-gestützte Virtualisierung, wie sie Linux mit KVM auf Kernelebene umsetzt, gaukelt dem Gastsystem eben-falls die Existenz einer vollständigen PC-Hardware-Umgebung vor, sodass sich ein beliebiges Betriebssystem samt eigenem Kernel installieren lässt. Die vollständige Virtualisierung ist für das Gastsystem jedoch transparent, sodass weder Modi-fikationen am Gastkernel noch das Ins-tallieren spezielle Treiber im Gastsystem erforderlich sind. Sie funktioniert allerdings nur mit einer CPU-VT-Erweiterung (Intel-VT/ Vander-pool beziehungsweise AMD-V/ Paci-fica), die dem Gastsystem vorgaukelt, es besäße die alleinige Kontrolle über die Hardware und dadurch privilegierten Zugriff, obwohl die Gastsysteme faktisch voneinander isoliert bleiben. Die eigent-liche Kontrolle sowie das Zuteilen der Ressourcen übernimmt entweder das Hostsystem oder ein Hypervisor. Ein wesentlicher Vorteil gegenüber der Paravirtualisierung ist, dass durch die Hardware-Erweiterung unmodifizierte Gastsysteme zum Einsatz kommen kön-nen, was auch den Betrieb von kommer-

Leistung beliebig viele Container parallel. Jeder Container ist so gestaltet, dass der Anwendung scheinbar ein vollständiges Betriebssystem samt Laufzeitumgebung zur Verfügung steht.Im Kontext des Hosts sind Container einfache Verzeichnisse. Sämtliche Con-tainer teilen sich damit den Kernel mit dem Hostsystem und können daher auch nur vom gleichen Typ sein wie das Host-Betriebssystem, also Linux. Eine Abstrak-tionsschicht im Hostkernel sorgt für das gegenseitige Isolieren der Container von-einander und verwaltet die benötigten Ressourcen, etwa CPU-Zeit, Speicherbe-darf und Festplattenkapazität. Da jeder Container stets nur so viel CPU-Zeit und Hauptspeicher verbraucht, wie die darin gerade aktive Anwendung, und die von der Abstraktionsschicht ver-brauchten Ressourcen kaum ins Gewicht fallen, ist eine Virtualisierung mit Open VZ konkurrenzlos effizient. Die Linux-Installation im Gast verbraucht lediglich Festplattenplatz. Open VZ ist daher stets dann die optimale Virtualisierungslösung, wenn keine Notwendigkeit besteht, aus dem Gast-Kontext heraus einen anderen Kernel oder Treiber zwecks Zugriff auf Hardwaregeräte zu laden.

Hardware-Virtualisierer

Hardware-Virtualisierer dagegen bieten gegenüber Ressource-Containern größere Flexibilität bei der Wahl des Gastsystems, die Performance hängt aber stark vom Zugriff auf die Hardware des Hostsys-tems ab. Die flexibelste, aber langsamste Lösung besteht in der vollständigen Emu-lation privilegierter Prozessor-Instruktio-nen und IO-Devices, wie es ein Emulator, etwa Qemu, ohne KVM tut.Hardwarevirtualisierung ohne CPU-Un-terstützung, wie sie VMware Server oder Parallels umsetzen, kostet etwa 30 Pro-zent Leistung gegenüber der Hardware-gestützten Virtualisierung. Paravirtuali-sierer wie VMware ESX oder Xen imple-mentieren zwischen Host- und Gastsys-tem eine spezielle Softwareschicht, die dem Gastsystem die am Host vorhande-nen Ressourcen über eine eigene Schnitt-stelle zugänglich macht. Allerdings laufen mit dieser Lösung keine unmodifizierten Gastsysteme. Solche Mo-difikationen am Gastsystem sorgen dafür,

Abbildung 1: Proxmox VE ermöglicht das Erstellen und Verwalten von Open-VZ-Containern (Ubuntu 8.04) und

virtualisierten KVM-Maschinen.

Abbildung 2: Fehlt dem Prozessor die Hardware-Unterstützung für Virtualisierung, meldet Proxmox dies und

erlaubt dann nur Open-VZ-Container.

V i rT uA l i s i e ru n gProxmox Virtual Appliance

60 Au s gA b e 0 5 -20 1 0 A d m i n

enten Einsatz von Open VZ oder KVM kann es sich aber lohnen, auch jüngere Kernel-Releases einzusetzen. So basiert etwa die offizielle Open-VZ-Betarelease auf einem Kernel 2.6.32. Daher bietet Proxmox auf den Download-Seiten auch Kernel-Updates für 2.6.24 und 2.6.32.2C (dieses mit KVM_0.12.4 und gPXE) an, die sich nach dem Installieren der VE ma-nuell einspielen lassen, sinnvollerweise erst nach einem System-Upgrade:

apt‑get update

apt‑get upgrade

apt‑get install proxmox‑ve‑2.6.32

Ein Proxmox Cluster Master kann übri-gens auch gemischte Kernelsetups ver-

walten, etwa zwei Nodes mit 2.6.24, einen mit 2.6.32 und einen mit 2.6.18. Wer vorrangig Open-VZ-Container be-treiben möchte, kann getrost bei Kernel 2.6.18 bleiben. Der Kernel 2.6.32 bietet zwar die jüngste KVM-Version mit KSM (Kernel Samepage Merging), allerdings derzeit noch keinen Open-VZ-Support. Auf der anderen Seite enthält der Kernel 2.6.18 zwar die offizielle Stable-Release von KVM, die bietet aber keine SCSI-Emulation für Gastsysteme, sondern nur IDE oder Virt-ID.

Ohne VT nur Open VZ

Proxmox gibt als minimale Hardware-Ausstattung eine 64-Bit-CPU mit Support für Intel (Vanderpool/ VT) oder AMD (Pacifica/ AMD-V) und 1 GByte Arbeits-speicher an. Die Hardwarevirtualisierung mittels KVM ermöglicht jedem Gast den vollständigen Zugriff auf die CPU (Ring 0) in maximaler Geschwindigkeit und allen verfügbaren Erweiterungen (MMX, ET64, 3DNow). Das Vorhandensein einer CPU mit VT-Erweiterung lässt sich nach erfolgreicher Installation von Proxmox VE durch Ein-gabe von »pveversion -v« an der Prox-mox-Konsole leicht prüfen. Mit nachge-rüstetem Kernel 2.6.24 sollte die Ausgabe etwa so aussehen wie Listing 1.Alternativ kann der versierte Admin auch in »/proc/cpuinfo« unter »flags« nach den Einträgen wie »vmx« oder »svm« fahn-den. Fehlende KVM-Kernelunterstützung zeigt sich übrigens im Webinterface auch ganz banal dadurch, dass sich im »VM Manager« unter »virtuelle Maschinen«

CPU-Kontext sehen. Das Modul »kvm.ko« hat direkten Zugriff auf die archi-tekturabhängigen Module »kvm-intel« und »kvm-amd«, was eine zeitraubende MMU-Emulation obsolet macht.Das ISO der aktuellen Proxmox-VE-Version 1.5 vom Mai dieses Jahres steht unter [1] zum Download. Proxmox VE 1.5 basiert auf Debian 5.0 (Lenny) in der 64-Bit-Version. Der Proxmox-VE-Kernel ist ein Standard-64-Bit-Kernel mit Debian-Patches, Open-VZ-Patches für Debian und KVM-Support. Genau genommen sind derzeit drei ver-schiedene Proxmox-Kernel im Umlauf. Das ISO-Image der Proxmox-VE-Version 1.5 mit Build vom 03.02.2010 verwendet die Kernelversion 2.6.18. Für den effizi-

Listing 1: »pveversion -v«

01 # pveversion ‑v

02 pve‑manager: 1.5‑10 (pve‑manager/1.5/4822)

03 running kernel: 2.6.24‑11‑pve

04 proxmox‑ve‑2.6.24: 1.5‑23

05 pve‑kernel‑2.6.24‑11‑pve: 2.6.24‑23

06 qemu‑server: 1.1‑16

07 pve‑firmware: 1.0‑5

08 libpve‑storage‑perl: 1.0‑13

09 vncterm: 0.9‑2

10 vzctl: 3.0.23‑1pve11

11 vzdump: 1.2‑5

12 vzprocps: 2.0.11‑1dso2

13 vzquota: 3.0.11‑1

14 pve‑qemu‑kvm: 0.12.4‑1<C>

Abbildung 3: Mit Ausnahme der Netzwerkparameter hat der Admin nur wenig Einfluss auf die Einzelheiten bei

der Installation von Proxmox VE.

Abbildung 4: Proxmox stellt nach außen nur wenige Dienste zur Verfügung.

Proxmox Virtual ApplianceV i rT uA l i s i e ru n g

Webbrowser verwalten. Nach dem Ins-tallieren des Basissystems empfiehlt es

und lässt sich unter der während der Installation angegebenen IP-Adresse im

ausschließlich Open-VZ-Container anle-gen lassen. Außerdem gibt das Webinter-face dann die Meldung »Achtung: Diese CPU unterstützt keine KVM Maschinen (keine Intel VT / AMD-V Unterstützung)« aus (Abbildung 2).Der grafische Installer lässt sich mit weni-gen Mausklicks zum Aufspielen des Sys-tems bewegen und wirft keinerlei Fragen auf. Sämtliche Daten auf der im Installer unten angezeigten Festplatte gehen da-bei verloren. Ebenso wenig Einfluss hat der Admin beim Festlegen des Partitions-schemas, bei dem der Proxmox-Installer automatisch ein LVM-Schema (Logical Volume Manager) festlegt. Nach Auswahl von Land, Zeitzone und Tastaturlayout, der Eingabe eines Administrator-Kenn-worts und dem manuellen Festlegen der IPv4-Netzwerkparameter (Abbildung 3), entpackt und überträgt der Installer das Basissystem.Nach einem abschließenden Klick auf »Reboot« ist das System einsatzbereit

Abbildung 5: Proxmox bietet im GUI fertige Open-VZ-Templates an.

V i rT uA l i s i e ru n gProxmox Virtual Appliance

62 Au s gA b e 0 5 -20 1 0 A d m i n

Proxmox-Jargon »Vir-tual Appliances« ge-nannt) zu verwen-den, von denen es für Open VZ eine ganze Reihe gibt. Auch sie lassen sich bequem über das Webinter-face unter »VM Ma-nager | Appliance Templates« herunter-laden. Über den Rei-ter »Download« ste-hen viele zertifizierte Templates zur Verfü-gung, etwa im Ab-schnitt »www« ein fix und fertiges Joomla-System. In der Spalte »Typ« ist zu erkennen, dass es sich um Open-VZ-Tem-plates handelt (Abbildung 5).Ein Klick auf den Namen des Template führt zu einer Übersichtsseite mit detail-lierteren Informationen. Ein Klick auf »start download« leitet den Download ein. Anschließend genügt es, beim Erstellen der virtuellen Maschine den »Typ Contai-ner (OpenVZ)« und die eben installierte Vorlage »debian-5.0-joomla_1.5.15-1« auszuwählen und darunter einen Host-namen, ein Passwort und die gewünsch-ten Netzwerkparameter einzustellen. Mit einem Klick auf »create« steht nach weni-gen Minuten ein neuer virtueller Joomla-Server zur Verfügung. Beim Netzwerk empfiehlt es sich, vom Open-VZ-Default »virtuelles Netzwerk (venet)« auf Bridged-Ethernet zu wech-seln, weil viele Webdienste auf funktio-nierendes Broadcasting angewiesen sind. Zum Starten genügt dann ein Klick auf

den roten Pfeil in der VM-Liste im ers-ten Reiter »Liste« des VM-Managers. Wer Proxmox als Cluster betreibt, kann bereits beim Anlegen der virtuellen Maschine entscheiden, welcher Node im Cluster sie enthalten soll. Mehr zum Netzwerken verrät der Kasten „Ins Netz“.Zum Starten der VM steht im Kontext-menü der Liste virtueller Maschinen für die ausgewählte VM (roter Pfeil) der Ein-trag »Start« zur Verfügung. Außerdem gibt es im Bearbeiten-Dialog der virtuel-len Maschine den Link »Öffne VNC Kon-sole«, mit dessen Hilfe Proxmox einen Java-VNC-Client als Popup-Fenster im Browser öffnet, über das sich der Admin schnell und unkompliziert an der Kon-sole der virtuellen Maschine anmelden kann (Abbildung 6). Jetzt ist es ein Leichtes, das Netzwerk der virtuellen Maschine manuell an die eige-

sich, einzuloggen und das System mit »apt-get update && apt-get upgrade« auf den aktuellen Stand zu bringen. Nach dem ersten Login am Webinterface lässt sich dessen GUI unter »System« im Reiter »Options« auf Deutsch umstellen. Ach-tung: Der kleine rote Save-Schriftzug ist leicht zu übersehen.Proxmox setzt wegen der mit KVM im-plementierten Hardwarevirtualisierung wie beschrieben eigentlich zwingend eine 64-Bit-Intel- oder AMD-CPU voraus. Inoffiziell stellt der Hersteller auch eine auf einem 32-Bit-Lenny basierende Vari-ante zur Verfügung, die dann allerdings nur Open-VZ-Support bietet. Einzelheiten dazu finden sich unter [5]. Alternativ lässt sich Proxmox auch auf einem be-stehenden Lenny-System selbst aufset-zen. Eine passende Installationsanleitung steht unter [6] zur Verfügung.

Sparsame Dienste

Der fertige Proxmox-Hypervisor bietet dank seiner wenigen offener Ports (443 für HTTPS, 5900 für VNC und optional 22 für SSH) nur minimale Angriffsflä-chen (Abbildung 4). Welche Dienste im Einzelnen laufen, kann der Administrator im Webinterface unter »Administration | Server« regeln.Das Anlegen und Verwalten von Cluster Mastern, Nodes und virtuellen Open-VZ-Containern oder KVM-Maschinen geht im Web-GUI recht einfach vonstatten. Eine virtuelle Maschine erstellt der Admin im Bereich »VM Manager« über das Menü »Virtuelle Maschinen«. Noch bequemer ist es allerdings, fertige Templates (im

Abbildung 6: Mit Hilfe des eingebauten Java-VNC-Clients lässt sich die

Funktionsfähigkeit jeder neuen virtuellen Maschine schnell mit einem

Konsolen-Login prüfen.

ins netz

Proxmox VE arbeitet mit Bridged Network De-vices (Abbildung 7). Damit haben alle virtuellen Maschinen ohne Einschränkungen physischen Zugriff auf das Host-Netzwerk. Außerdem sind auch VLANs (IEEE 802.1q) und Bonding-Konfi-gurationen möglich. Die gesamte Netzwerk-Konfiguration kann über das Webinterface erfol-gen. Etwaige Änderungen an der Konfiguration vermerkt Proxmox in »/etc/network/interfaces.new« und aktiviert neu definierte Geräte nach dem nächsten Reboot. Die jeweils aktuelle Kon-figuration steckt Debian-üblich unter »/etc/network/interfaces«.Der Installer erzeugt in jedem Fall zunächst ein Single Bridge Device (»vmbr0«), das physisch mit dem ersten Ethernet-Gerät (»eth0«) ver-

bunden ist. Die Bindung lässt sich im Webinter-face unter »Konfiguration | System | Netzwerk« mit einem manuellen Eintrag bei »Bridge Ports« auch ändern.Open VZ nutzt zur Netzwerk-Konfiguration entweder einfache Venet-Devices ohne MAC-Adresse oder flexiblere, durch das Kernelmodul »vzethdev« etablierte »veth«-Geräte, welche sich Host-seitig an die oben beschriebene Bridge binden lassen. Bridge und Venet-Gerät sind im Host-Kontext mit »ifconfig« normal sichtbar. Die Wahl des im Open-VZ-Container zu verwendenden Netzwerktyps (Bridge oder Venet) findet beim Anlegen der virtuellen Ma-schine beziehungsweise in der virtuellen Ma-schine selbst statt.

Infos

[1] Proxmox VE: [http:// www. proxmox. com/

downloads/ proxmox-ve]

[2] Thomas Drilling, „Container mit Open VZ“:

ADMIN 04/2010, S. 53

[3] KVM: [http:// www. linux-kvm. org/ page/

Main_Page]

[4] Virt-IO-KVM-Treiber für Windows: [http://

blog. famzah. net/ 2010/ 01/ 09/ kvm-qemu-vir

tio-storage-and-network-drivers-for-32-bit

64-bit-windows-7-windows-vista-windows-

xp-and-windows-2000/]

[5] Proxmox 32 Bit: [http:// pve. proxmox.

com/ wiki/ Install_Proxmox_VE_on_Debian_

Lenny_on_32-Bit_Processor]

[6] Proxmox in Debian Lenny installieren:

[http:// pve. proxmox. com/ wiki/ Install_

Proxmox_VE_on_Debian_Lenny]

Proxmox Virtual ApplianceV i rT uA l i s i e ru n g

nen Bedürfnisse anzupassen. Wer sich beim Anlegen der virtuellen Maschine für ein Bridge-Ethernet-Device entschie-den hat, muss in der virtuellen Maschine lediglich der virtuellen Netzwerkkarte »eth0« die gewünschte IP-Adresse zu-weisen und gegebenenfalls das Default-Gateway eintragen.Ab jetzt kann sich der Admin problemlos auch direkt an der virtuellen Maschine anmelden, beispielsweise via SSH über das lokale Netzwerk.

Fazit

Proxmox bietet dem Admin eine einfach zu handhabende Virtualisierungsplatt-form für Open-VZ- und KVM-Maschinen. Zwar lassen sich virtuelle Cluster, Server und Maschinen auch mit den Webwerk-zeugen von VMware (VSphere) oder Citrix (Xen) komfortabel verwalten, das kostet allerdings richtig Geld. Proxmox ist Open Source. Dabei beherrscht Prox-

mox auch das Aufsetzen von Clustern, bietet ein Backup-Werkzeug und kann unterschiedliche Speichertechnologien (LVM-Groups, I-SCSI oder NFS Sharing) anbinden. Gehen die unternehmensinternen Plan-spiele allerdings in Richtung Desktop-

Virtualisierung oder Cloud Computing und ist ein komfortables Deployment virtueller Desktops oder ISOs gefragt, sind die kommerziellen Lösungen lang-fristig möglicherweise die bessere Wahl. Proxmox VE bietet aber erstaunlich viel für nichts. (ofr) ■

NEU!Jetzt kostenlos downloaden:

www.SearchDataCenter.de/

Kompendium

Virtualisierung, Cloud-Computing, SaaS, PaaS und laaS

Was Sie schon immer über

Kompendium zur www.SearchDataCenter.de 2009 | € 6,90

VIRTUALISIERUNG

Cloud Computing

Investition in eine performante IT

Management von Cloud Services

Produktivitätstools für die CloudDesktopvirtualisierung

Zugri� auf Services in der Cloud

Eine Publikation von

wissen wollten ...

Abbildung 7: Das Host-Netzwerk des Proxmox Cluster Master arbeitet mit Bridge-Devices, die sich

automatisch an die erste gefundene Netzwerkkarte binden.

V i rT uA l i s i e ru n gProxmox Virtual Appliance