Proxmox Virtual Environment 2.2 unter der Lupe

© Artem Merzlenko, 123RF

Virtualisierungswarte

Proxmox Virtual Environment wandelt sich mit jedem neuen Release mehr vom Geheimtipp zum kostenlosen VMware ESXi/vSphere-Konkurrenten. Wir werfen einen Blick auf die Neuerungen der Version 2.2.
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Proxmox Virtual Environment (PVE) [1] ist eine Open-Source-Virtualisierungslösung, die seit 2004 von der Wiener Proxmox Server Solutions GmbH entwickelt wird. Da Proxmox VE vollständig unter der GPLv2 lizensiert ist, bestehen auch hinsichtlich einer geschäftlichen Nutzung keine Einschränkungen – im Unterschied zu manchen Free- oder Personal-Lizenzen vergleichbarer Konkurrenzprodukte. Die Proxmox Server Solutions GmbH bietet allerdings für Unternehmenskunden auch ein Subskriptions-Modell [2] mit verschiedenen Support-Leveln zwischen 120 Euro und 800 Euro pro Jahr an.

Die Lösung war von Anfang an als einfach installierbare Appliance mit Bare-Metal-Installer konzipiert, die sich über eine Weboberfläche konfigurieren lässt und wahlweise KVM-basierte Gäste oder OpenVZ-Container bereitstellen kann. Diese relativ ungewöhnliche Kombination macht deutlich, dass PVE auf den Unternehmenseinsatz abzielt, wenngleich die frühen Versionen dafür noch die eine oder andere Funktion vermissen ließen.

Auch eine Cluster-Funktion war schon von Anfang an enthalten, mit deren Hilfe der Admin aus zwei oder mehr PVE-Rechnerknoten auch ohne SAN eine redundante Virtualisierungsumgebung erstellen konnte. Der Leistungsumgang steigerte sich von Version zu Version. Wenn es an früheren Versionen etwas auszusetzen gab, dann dass die Web-GUI Funktionen vorspiegelte, die sie allein nicht hatte. Stattdessen war oft eine vorherige manuelle Konfiguration auf der Kommandozeile nötig, etwa im Bereich der Cluster-Funktionen oder beim Befüllen eines Storages, sei das ein lokales Verzeichnis auf dem jeweiligen PVE-Node oder ein Netzwerkverzeichnis (NFS, CIFS) oder ein SAN (iSCSI, FC).

Funktionsumfang

Proxmox bezeichnet sich selbst als "Open Source-Virtualisierungsplattform mit Web-Oberfläche zum Betrieb und Management von Virtual Appliances mit integrierter VNC-Konsole". Proxmox spielte schon 2012 vor der Veröffentlichung der Version 2.0 in einer Liga mit dem (heute nicht mehr erhältlichen) VMware-Server und positioniert sich in der aktuellen Version 2.2 als direkter Konkurrent zu VMware ESXi und Citrix Xen Server. Laut einer Vergleichstabelle [5] der Proxmox-Entwickler kann PVE 2.2 sogar mehr als vSPhere, XenServer und MS Hyper V. In der Tat kam die Veröffentlichung der Version 2.0 im Frühjahr letzten Jahres mit komplett neuer JavaScript-Weboberfläche, auf dem Corosync-Cluster-Communication-Stack basierender HA-Unterstützung, Backup/Restore-Funktion via GUI und seinem RESTful Web API (Proxmox_VE_API) [6] einem Quantensprung in der Entwicklung gleich.

Dieser Beitrag soll neben den Neuerungen der Version 2.2 vorrangig zwei für Admins interessante Funktionen im Detail beschreiben, nämlich das Erstellen eines HA-Clusters und das individuelle Aufsetzen von Proxmox VE auf einem Debian-System.

Eine Besonderheit von Proxmox-VE besteht darin, dass das System im Kern auf Debian-GNU-Linux (aktuell Version 6.0.6) basiert. Das ist – gerade für Windows-Admins – nicht unbedingt ersichtlich, weil sich die Software mit ihrem Bare-Metal-Installer (ohne große Möglichkeiten der Einflussnahme) in knapp 5 Minuten installieren lässt und die weitere Konfiguration über das Webinterface erfolgt. Dank Debian-Fundament kann der Admin aber beliebige Komponenten aus dem Debian-Projekt nachinstallieren und seinen Proxmox-Node so nach Belieben zu einer kompletten Workstation oder zu einem Server ausbauen, der neben der Virtualisierung auch andere Aufgaben übernimmt. Das Installieren, sowie erste Konfigurationsschritte im neuen Web-GUI erläutert der Kasten "Installation und erste Schritte" .

Installation und erste Schritte

Die Proxmox-Entwickler versprechen auf der Webseite, dass das System – eine jungfräuliche Festplatte voraussetzt – in weniger als 5 Minuten einsatzbereit ist ( Abbildung 5 ). Das können wir bestätigen, sofern die Hardwarevoraussetzungen erfüllt sind. Proxmox-VE ist ausschließlich in einer 64-Bit-Version verfügbar und kann als ISO-Datei von [18] heruntergeladen werden. Ferner muss der Prozessor des verwendeten Rechners für KVM die Virtualisierungserweiterung Intel VT oder AMD-V unterstützen. Andernfalls stellt Proxmox nur virtuelle OpenVZ-Container oder auf Qemu basierende virtuelle Appliances zur Verfügung. Das System lässt sich auf einem nahezu beliebigen leidlich aktuellen Rechner mit ausreichend RAM (8 GByte) installieren. Dass die Proxmox-Macher, neben den obligatorischen 8 GByte RAM, ein RAID mit schnellen Festplatten sowie einem durch Batterien geschützten Schreib-Cache (BBU) als Mindestvoraussetzung für den Produktiveinsatz nennen zeigt, welche Zielgruppe Proxmox anstrebt, zumal die in der Version 2.0 komplett überarbeitete Weboberfläche nach Aussage der Entwickler problemlos mit mehreren hundert bis tausend virtuellen Maschinen zurechtkommt. Laut Proxmox wurden die besten Ergebnisse mit SAS-Hardware (15.000 U/min) und einem RAID10 erzielt. Im Detail lassen sich die Hardware-Anforderungen hier [19] nachlesen. Das Installieren selbst ist nach Booten mit dem heruntergeladen ISO tatsächlich nach wenigen Schritten erledigt, denn das System möchte nicht mehr vom Admin wissen, als ein root- Password und die gewünschte IP-Konfiguration.

Abbildung 5: Dank Bare-Metal-Installer ist das System nach wenigen Eingaben einsatzbereit.

Benutzer anlegen

Das Anlegen eines ersten Benutzers kann nach dem Login als root im Webinterface unter der Adresse »https:// IP-Adresse :8006« erfolgen. Wer bereits eine Vorgänger-Version von Proxmox einsetzt, kann auch auf der Konsole ein Update über die Debian-Paketverwaltung vornehmen.

apt-get update && apt-get full-upgrade

Neues Rollenmodell

PVE-Kenner, die noch das alte Webinterface nutzen, werden möglicherweise etwas umdenken müssen. PVE bietet seit der Version 2.0 ein Rollen-basierte Benutzer/Berechtigungs-Modell, das den Zugriff auf sämtliche verwaltbaren Objekte, wie Nodes, Pools, Storages oder die virtuellen Maschinen regelt. Bei einem frisch installierten System besteht daher der erste Schritt darin, nach dem Anmelden als root im Reiter »Benutzer« mindestens einen Benutzer anzulegen. Benutzer- und Gruppen-Rechte lassen sich dagegen im Reiter »Rechte« einrichten. Ferner muss der Admin im Reiter »Storage« mit »Hinzufügen« mindestens ein Storage einrichten ( Abbildung 6 ), von denen PVE direkt über das GUI auf der lokalen Maschine wahlweise ein Verzeichnis oder eine LVM-Gruppe und im Netzwerk ebenfalls eine LVM-Gruppe, eine NFS-Freigabe oder ein iSCSI-Traget unterstützt. [20] .

Abbildung 6: Essenziell ist das Anlegen eines Storage, im einfachsten Fall ein lokales Verzeichnis.

Über das Auswahlfeld "Inhalt" im "Bearbeite"-Dialog oder beim erstmaligen Anlegen des Storage kann der Admin festlegen, ob der zur Aufnahme von ISOs, (KVM)-Images, OpenVZ-Ressource-Containern (CIT), OpenVZ-Templates oder Proxmox-Backups bestimmt ist.

Der Default-Pfad für ein lokales Verzeichnis als Storage ist »/var/lib/vz« . Musste der Admin einen ISO-Storage bei früheren Versionen manuell via »rsync« , »rcopy« oder mit anderen Methoden befüllen, bringt das neue GUI einen einfach zu handhabenden ISO-Uploader mit.

Der PVE-Version 2.0 haben die Entwickler zudem einen Appliance-Downloader für OpenVZ spendiert, der ebenfalls über der Reiter " »Inhalt« des jeweiligen Storages erreichbar ist. Hier genügt ein Klick auf »Templates« .

Zum Anlegen einer virtuellen Maschine oder eines Containers markiert der Admin im Ressource-Baum der Server- oder Storage-Ansicht den gewünschten Knoten und klickt dann wahlweise auf eine der Schaltflächen »Erstelle VM« oder »Erstelle Container« . Die GUI stellt dann jeweils einen Unter-Dialog mit einer Reihe von Reitern zur Verfügung, die der Admin nur von links nach rechts abarbeitet. Die betreffenden Einstellungen dürften für den erfahrenen Admin selbsterklärend sein.

VM erzeugen

Im ersten Reiter »General« sind der betreffenden Knoten, sowie die ID der neuen virtuellen Appliance bereits vorgeben. Der Admin muss lediglich einen Namen vergeben und den zuständigen Ressource-Pool wählen ( Abbildung 7 ).

Abbildung 7: Im Reiter General sind der betreffende Knoten sowie die ID der virtuellen Appliance vorgegeben.

Der sollte zu diesem Zeitpunkt soweit vorbereitet sein, dass das benötigte Template (OpenVZ) oder ein Installations-ISO verfügbar sind. Während der Admin bei einem Container nach der Auswahl des gewünschten Templates nur noch die Netzwerkparameter der virtuellen Appliance festlegen muss, bietet der Sub-Dialog für eine virtuelle KVM-Maschine einige Reiter mehr, unterscheidet sich aber kaum von entsprechenden Assistenten bei VirtualBox oder KVM/Virt-Manager.

Insbesondere die im Zusammenhang mit KVM unterstützen Funktionen hängen primär von der verwendeten Kernel-Version ab. Die erlaubt es seit der PVE-Version 2.0, bei virtuellen KVM-Maschinen auch SCSI-Hardware auszuwählen. Ferner kann Proxmox seit der Version 2.0 im Zusammenhang mit KVM auch SATA-Geräte sowie bis zu 32 Netzwerk- oder 16 Virtio-Devices verwalten.

Clustern mit Proxmox

Wer einen Cluster-Verbund mit PVE aufbauen will, tut sich leichter, wenn ein externer Shared-Storage, etwa in Form eines SAN oder NFS-Servers zur Verfügung steht. PVE kennt die Storage-Technologien iSCSI, Fibre Channel, CIFS, NFS, DRBD und ATA over Ethernet (AoE).

PVE unterstützt schon von je Cluster. Dabei unterscheidet es zwischen gewöhnlichen Clustern und Hochverfügbarkeits-Clustern. Erstere sind ein Verbund von Rechnern einer PVE-Installation (Virtualisierungsknoten). Ein solcher Proxmox-VE-Cluster besteht stets aus einem Master und mindestens einem Node. Wie man ein solches Setup aufsetzt, ist im Proxmox-Wiki [7] beschrieben. Die dortigen Erläuterungen und Abbildungen zum Verwenden des Cluster-Setups beziehen sich jedoch auf die Version 1.9 mit alter GUI. Nach abgeschlossener Konfiguration über das GUI lassen sich virtuelle Maschinen zum Beispiel auf einen anderen Proxmox-Knoten migrieren. Seit der Version 2.0 ist das Produkt auch hoch verfügbar, was in Konkurrenz zu kommerziellen Lösungen wie VMware ESX essenziell ist. Zum Realisieren eines HA-Clusters mit PVE gibt es seit der Version 2.0 zwei Möglichkeiten. Die erste funktioniert auch mit älteren Versionen. Hat der Admin einen gewöhnlichen PVE-Cluster konfiguriert, kann er mithilfe von DRDB einen sogenannten Two-Node-HA-Cluster aufsetzen, was ebenfalls im Wiki [8] beschrieben ist. Das funktioniert, weil PVE wie erläutert (auch) ein ganz gewöhnliches Debian-System ist. Eine DRDB-Konfiguration beschränkt sich stets auf zwei Knoten und ist im Proxmox-Wiki ausführlich erläutert [9] . Da DRDB zwei PVE-Hosts synchronisieren hilft, die so als Basis für den HA-Cluster dienen, reduziert sich der Aufwand an benötigten Komponenten auf zwei PVE-Hosts.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023