Proxmox VE ist in aller Munde, seit VMware von Broadcom übernommen wurde und der neue Besitzer einschneidende Veränderungen am Produktportfolio und der Lizenzierung vorgenommen hat. Viele Testumgebungen wurden oftmals mit dem freien ESXi-Hypervisor aufgebaut. Den hat Broadcom aber jetzt eingestampft. Wir schauen uns deshalb in diesem Workshop im Detail an, wie Sie mit Proxmox VE eine Testumgebung aufbauen.
Gerade bei einem Hypervisor ist es gar nicht so einfach, sich einen schnellen und vor allem detaillierten Überblick bezüglich seiner Leistungsfähigkeit und Funktionalität zu verschaffen. Dazu kommt, dass diese Komponente das Kernelement in der Virtualisierung darstellt und dass alle Services von einem einwandfrei funktionierenden und einfach zu bedienenden Hypervisor abhängen. Deshalb ist es eine gute Idee, ein Test-Lab aufzubauen, in dem Sie ausprobieren können, was mit der GUI oder im CLI von Proxmox VE (PVE) so alles möglich ist, wie Sie PVE an welchen Storage bringen und wie intuitiv das Workload-Deployment vonstattengeht.
Grundlagen von PVE
Proxmox VE basiert auf Debian GNU/Linux mit einem modifizierten Linux-Kernel. Virtuelle Maschinen werden als so genannte QEMU/KVM-Gäste bezeichnet. Das Gastsystem wird in Proxmox VE unter Verwendung von QEMU und dem KVM-Kernelmodul virtualisiert. Hierbei steht QEMU für Quick Emulator und KVM für Kernel-Based Virtual Machine. QEMU selbst kann jede Menge CPU-Typen emulieren. Das Ganze geht von Intel- über AMD- und ARM- bis hin zu Sparc-CPUs. Von PVE werden allerdings ausschließlich 64-Bit-AMD- und Intel-CPUs unterstützt.
VirtIO-Treiber gibt es natürlich auch und die werden auch dringend benötigt. Alles für das Deployment eines Windows-Workloads steckt im Image "virtio-win-0.1.240.iso", das Sie unter [1] herunterladen können. Geht es hingegen um einen Linux-Workload als Gastsystem, dann sollten Sie den QEMU-Guest-Agent installieren. Das Paket "qemu-guest-agent" ist für die meisten Linux-Versionen verfügbar und lässt sich auf dem Gastsystem via CLI installieren.
Gerade bei einem Hypervisor ist es gar nicht so einfach, sich einen schnellen und vor allem detaillierten Überblick bezüglich seiner Leistungsfähigkeit und Funktionalität zu verschaffen. Dazu kommt, dass diese Komponente das Kernelement in der Virtualisierung darstellt und dass alle Services von einem einwandfrei funktionierenden und einfach zu bedienenden Hypervisor abhängen. Deshalb ist es eine gute Idee, ein Test-Lab aufzubauen, in dem Sie ausprobieren können, was mit der GUI oder im CLI von Proxmox VE (PVE) so alles möglich ist, wie Sie PVE an welchen Storage bringen und wie intuitiv das Workload-Deployment vonstattengeht.
Grundlagen von PVE
Proxmox VE basiert auf Debian GNU/Linux mit einem modifizierten Linux-Kernel. Virtuelle Maschinen werden als so genannte QEMU/KVM-Gäste bezeichnet. Das Gastsystem wird in Proxmox VE unter Verwendung von QEMU und dem KVM-Kernelmodul virtualisiert. Hierbei steht QEMU für Quick Emulator und KVM für Kernel-Based Virtual Machine. QEMU selbst kann jede Menge CPU-Typen emulieren. Das Ganze geht von Intel- über AMD- und ARM- bis hin zu Sparc-CPUs. Von PVE werden allerdings ausschließlich 64-Bit-AMD- und Intel-CPUs unterstützt.
VirtIO-Treiber gibt es natürlich auch und die werden auch dringend benötigt. Alles für das Deployment eines Windows-Workloads steckt im Image "virtio-win-0.1.240.iso", das Sie unter [1] herunterladen können. Geht es hingegen um einen Linux-Workload als Gastsystem, dann sollten Sie den QEMU-Guest-Agent installieren. Das Paket "qemu-guest-agent" ist für die meisten Linux-Versionen verfügbar und lässt sich auf dem Gastsystem via CLI installieren.
Den Umstieg üben
Auch wenn PVE eine solide Open-Source-Virtualisierung mit einer breiten Palette an Funktionalität ist, bedenken Sie: Je nachdem, was Sie bisher in Ihrer produktiven Virtualisierungsumgebung an Funktionalität genutzt haben, kann das eine oder andere Feature möglicherweise im Umfeld von PVE gar nicht mehr oder nur in Teilen vorhanden sein.
Gerade Umsteiger, die sich mit Proxmox VE beschäftigen möchten und bisher zum Beispiel ausschließlich an ESXi beziehungsweise vSphere gewöhnt waren, werden sich umgewöhnen müssen. Selbst wenn auf den ersten Blick alles recht ähnlich aussieht, ist vieles doch anders als gewohnt. Rechnen Sie, je nachdem wie erfahren Sie im Umfeld von Open Source sind, also damit, dass die Lernkurve steil werden kann. Deshalb ist ein Lab zum Ausprobieren das A und O, sollten Sie PVE effektiv nutzen und verwalten wollen.
In diesem Zusammenhang ist auch deutlich festzuhalten, dass die Community und der Herstellersupport bei PVE nicht so ausgeprägt sind, wie Sie es vielleicht von anderen Produkten gewohnt sind. Das ist auch kein Wunder bei einem Blick auf den Zeitraum, in dem sich andere Communities entwickelt haben. Die mit PVE verbundenen Kosten wiederum sind deutlich geringer gegenüber dem, was Sie beispielsweise von anderen Anbietern kennen. Aber genau an dieser Stelle müssen Sie mit Ihrem Wissen und Ihrer Zeit für entsprechende Kompensation sorgen.
Einstieg in die Installation
Die aktuelle PVE-Version 8.2-1, die Sie unter [2] downloaden können, basiert auf Debian 12.5, genannt Bookworm, das seit Ende November 2023 zur Verfügung steht. Momentan gibt es weder ein EOL-Datum für diese Debian- noch für die dazugehörige PVE-Version. Das Test-Lab, mit dem wir uns hier in diesem Workshop beschäftigen werden, wurde mit der proxmox-ve_8.2-1.iso-Datei aufgebaut.
Überlegen Sie sich zuerst einmal, welche Elemente Sie testen möchten. Soll Ihr Testaufbau aus einem Single- oder Multi-Node-Cluster bestehen? Werden Sie die im Node eingebauten Festplatten zum Beispiel mit dem ZFS-Dateisystem zur Speicherung Ihrer Workloads verwenden oder befinden sich Ihre Workloads vielleicht in einem entfernten NAS und Sie binden sie beispielsweise via NFS an die Nodes an? Oder möchten Sie den Speicherplatz für Ihre Workloads durch Nutzung sämtlicher Disks in den vorhandenen Nodes mittels Ceph als Software-defined Storage benutzen? Sie sehen, es ist einiges möglich, und hier sind noch lange nicht alle Variationen aufgeführt. Ihren Testphantasien sind also im Hinblick auf die Kombinationsmöglichkeiten gesehen fast keine Grenzen gesetzt.
Und wie sollte es anders sein, lässt sich PVE natürlich auch nested aufbauen. Sollten Sie noch über eine alternative Virtualisierungsumgebung verfügen, nutzen Sie sie einfach. Haben Sie zum Beispiel noch irgendwo einen ESXi laufen und soll dieser erst einmal als Träger einer PVE-Test-Umgebung dienen, ist das überhaupt kein Thema.
Wollen Sie hingegen PVE direkt auf der Hardware betreiben, ist dies ebenfalls problemlos möglich. Je nachdem, wie die zur Verfügung stehende Hardware ausgestattet ist, können Sie den Hypervisor auch auf einem USB-Stick installieren. Nehmen wir einmal den extremen Fall an, dass Sie lediglich über Nodes verfügen, die nicht einmal eine Disk enthalten und alle Test-Workloads nur via NFS erreichbar sein sollen – also eine sehr minimalistische Testumgebung. Hierbei hätten Sie dann auch gar nicht mehr so viele Optionen auf dem Tisch. Aber Vorsicht! Ein USB-Stick ist für so einen Einsatz eigentlich nicht gemacht. Der Hypervisor verursacht eine Menge an Schreib- und Lesevorgängen. Auf die Dauer ist so etwas für einen USB-Stick lebensgefährlich.
Wollen Sie diesen Weg dennoch gehen, dann benötigen Sie mehrere USB-Sticks für die Installation eines einzelnen Nodes. Ein USB-Stick wird für die Installation benötigt. Diesen Installationsstick können Sie, sollten Sie mehrere Nodes installieren wollen, natürlich immer wieder verwenden. Die weiteren Sticks sind die Installationsziele beziehungsweise die Boot-Devices für die zu installierenden Nodes. Am Ende, also im Anschluss an die Installation, bootet jeder Node von seinem eigenen Bootstick.
Der Bootstick darf durchaus etwas größer sein, da auf ihm auch die ISO-Images gespeichert werden, mit denen Sie Ihre VMs installieren, und auch das Image mit den VirtIO Treibern legen Sie möglicherweise darauf. Aber heutzutage liegen ja USB-Stick-Kapazitäten von 64 GByte oftmals ungenutzt in der Schublade.
Erstellen eines USB-Installationssticks
Was die Kapazität des USB-Sticks für die Installation von PVE-Hosts angeht, sind 32 GByte eigentlich völlig ausreichend. Für das Erzeugen eines bootfähigen USB-Sticks können Sie einen USB-Installer Ihrer Wahl nutzen. Wir verwenden für diesen Workshop das Tool Rufus [3]. Nehmen Sie nun die heruntergeladene proxmox-ve_8.2-1.iso-Datei (Bild 1) und erstellen Sie mit Ihrem USB-Speicher einen bootfähigen USB-PVE-Installationsstick.
Wird das Test-Lab allerdings virtuell, also nested, ist dieser Schritt nicht erforderlich, da Sie das PVE-Image ja direkt in der virtuellen Hardware mounten können. Natürlich ist auch kein PVE-Bootstick erforderlich, da Sie ja einfach virtuelle Disks als Installationsziele der VM hinzufügen.
Gerade für erste Gehversuche ist eine Nested-Umgebung natürlich recht gut geeignet, da Sie die Möglichkeit haben, Snapshots zu erstellen, und sich somit auch problemlos wagen können, den einen oder anderen Test zu machen, der sich je nach Resultat dann auch ganz schnell wieder ungeschehen machen lässt.
Sie haben nun die benötigte Software heruntergeladen. Es bleibt schlussendlich nach der Beantwortung der Frage "physisch oder virtuell" noch die Überlegung, ob die Testumgebung aus einem einzelnen Server bestehen soll oder aus einem Cluster mit mehreren Nodes. Egal, wofür Sie sich letztendlich entscheiden, prinzipiell läuft die Installation immer gleich ab.
Sie können die Installation auch automatisiert durchführen. Hierfür wurde kürzlich ein Verfahren implementiert, das auf dem initialen Erstellen eines Customize-Images basiert. Hierbei werden mittels einer minimalistisch aufgebauten Konfigurationsdatei im sogenannten TOML-Format die Informationen für die Konfiguration des Systems bereitgestellt.
Mit den Einträgen in dieser Datei erzeugen Sie dann ein entsprechendes ISO-File für die Installation. Solch ein Image können Sie dann ebenfalls auf einen USB-Stick bringen oder bei einer virtualisierten Installation entsprechend in das virtuelle Gerät einlegen. Wie Sie so eine Unattended-Bereitstellung umsetzen beziehungsweise wie sie funktioniert, können Sie sich im Internet unter [4] genauer anschauen.
Aufbau der Testumgebung
Damit Sie die Installation und Konfiguration Schritt für Schritt nachvollziehen können, stellen wir hier den gesamten Vorgang einmal manuell vor. In diesem Rahmen schauen wir uns genauer an, wie Sie einen virtuellen Drei-Node-Cluster im Homelab quasi als 3-Tier-Environment (Bild 2) aufbauen.
Klären wir zuerst einmal die Frage, was wir dazu alles an Ressourcen benötigen. Da es sich um den Aufbau einer Nested-Testumgebung im Lab handelt, bedarf es zuallererst einmal dreier Workloads, ausgestattet mit je 16 GByte Memory und 2 vCPUs. Weiterhin spendieren wir jeder VM eine vNIC und zwei 256-GByte-vDisks, dann noch ein vDVD-Laufwerk für das PVE-ISO – das war es dann auch schon. Alles andere an der VM bleibt einfach default. Als Shared Storage für den Cluster setzen wir ein NAS ein, das einen NFS-Share für die Workloads, die im Cluster laufen sollen, bereitstellt.
Damit die Installation Ihres Labs aber nicht ins Stocken gerät, empfehlen wir, sich im Vorfeld alle notwendigen Informationen bereitzulegen. Sie benötigen ein Passwort für jeden Host, einen DNS-Server und einen Default-Gateway. Weiter brauchen Sie für jeden Host beziehungsweise Node dann noch eine IP-Adresse nach der CIDR-Notation aus Ihrem Lab-Netzwerk und noch einen eindeutigen Hostnamen.
Bei der Angabe der IP-Adresse nach CIDR wird die IP-Adresse und die Netzwerkmaske kombiniert hinterlegt. Bei diesem Adressschema steht die IP-Adresse voran und dann folgt, durch einen Schrägstrich abgetrennt, eine Dezimalzahl, die die Größe der Subnetzmaske angibt. Sollten Sie diesbezüglich etwas umrechnen wollen, finden Sie CIDR- und Network-Range-Calculators haufenweise im Internet.
Da ja als VM-Speicherort ein Share dienen soll, brauchen Sie für den Nachbau des Labs auch noch eine ID beziehungsweise einen eindeutigen Namen für den Share sowie die IP-Adresse und den Namen des Exportverzeichnisses des NAS. Auch benötigen Sie eine E-Mail-Adresse für den Empfang von Systembenachrichtigungen, wie zum Beispiel Alarmierungen oder HA-Events. Es ist also sinnvoll, hier eine valide E-Mail-Adresse bereitzuhalten. Wollen Sie auch einen Cluster erstellten, benötigen Sie selbstverständlich auch noch einen Namen für diesen.
Vergessen Sie an dieser Stelle nicht, ein Windows- und Linux-OS-Image sowie das für Windows-VMs notwendige VirtIO-Treiber-Image schon einmal herauszusuchen. Denn Sie möchten ja sicherlich direkt nach der Fertigstellung Ihrer PVE-Umgebung zügig mit dem VM-Deployment beginnen.
Installation der drei PVE-Hosts
Nachdem Ihnen nun alle Informationen vorliegen, können Sie mit der Umsetzung des Labs beginnen. Noch ein Wort zu den zwei Disks, die sich in jedem der PVE-Host-VMs befinden: Sie werden der VM die beiden Disks nur spendieren, um demonstrativ daraus einmal ein lokales ZFS (RAID 1) zu erstellen. Das ist in der Nested-Lab-Welt natürlich nicht wirklich notwendig, aber wenn Sie die Testumgebung physisch aufbauen möchten und kein Hardware-RAID im Server haben, kann so ein Software-RAID durchaus eine sinnvolle Sache sein.
Damit wir nun endlich zur Praxis kommen können, loggen Sie sich nun in Ihre virtuelle Sphäre ein und erzeugen drei neue VMs, die mit den genannten Ressourcen ausgestattet sind, und hängen dann noch die heruntergeladene ISO-Datei "proxmox-ve_8.2-1.iso" ein. Nach dem Start der VMs geht die Installation auch schon los. Alles, was nun folgt, müssen Sie für alle drei VMs machen. Im ersten Dialog wählen Sie die graphische Installation aus. Anschließend konfigurieren Sie das RAID1 basierend auf dem ZFS. Hierfür wählen Sie innerhalb der Optionen das entsprechende Filesystem und bestätigen mit "OK".
Im nächsten Schritt wählen Sie Ihre bevorzugte Lokation, Zeitzone und das Tastaturlayout. Geben Sie dann im Folgedialogfenster das Passwort ein sowie die E-Mail-Adresse für die Benachrichtigung des PVE-Hosts. Jetzt entscheiden Sie noch auf der Übersichtsseite, ob nach der Installation ein Reboot stattfinden soll. Wenn Ihre Hardware etwas betagter ist und eine mittlere Leistung hat, dauert die Installation einer PVE-VM schätzungsweise zehn Minuten. Für unseren Workshop haben wir als Hypervisor ESXi genutzt, der auf einem Server läuft, der wiederum mit einer Intel-Xeon-CPU E5-2420, 1,90 GHz und 80 GByte Memory ausgestattet ist.
Sie könnten jetzt beispielsweise in Ihrer Virtualisierungsumgebung auf die Konsole der PVM-VMs gehen, sich mit root und dem bei der Installation von Ihnen vergebenen Passwort einloggen und erst einmal ein apt-get-Update durchführen, oder Sie machen es einmal direkt in der PVE-UI. Beides ist möglich, und da Sie sicherlich Ersteres bereits bei anderen Installationen beziehungsweise Updates schon einmal gemacht haben, können Sie es in diesem Lab auch gern einmal via UI ausprobieren.
Die GUI beherrschen
Nach der Fertigstellung der Installation meldet sich der PVE-Host mit der Angabe, wie Sie das UI erreichen können. Das Ganze sollte dann so aussehen: "https:// <Die von Ihnen bei der Installation angegebene IP-Adresse>:8006". Gehen Sie nun in Ihren Browser und geben diese Adresse ein. Erteilen Sie nun im nächsten Schritt die Erlaubnis, diese unsichere Seite aufzurufen. Die PVE-UI erscheint und Sie können nun Ihre bevorzugte Sprache für die UI einstellen. Dann geben Sie noch den Anmeldenamen root ein und das Passwort, das Sie bei der Installation des Host vergeben haben. Ob Sie den Benutzernamen speichern möchten, bleibt ganz Ihnen überlassen.
Das nächste Fenster macht Sie darauf aufmerksam, dass Sie keine Subskription haben. Klicken Sie einfach auf "OK" und Sie befinden sich auch schon auf dem PVE-UI (Bild 3). Die Meldung, dass Sie keine gültige Subskription haben, erscheint bei jeder Anmeldung. Wenn Sie das stört, dann gibt es zwei Möglichkeiten: Sie erwerben eine Subskription oder Sie googeln eine Anleitung, wie Sie die Meldung unterdrücken.
Melden Sie sich nun auf allen drei UIs an und schauen einmal nach, ob alle Hosts ordnungsgemäß funktionieren. Die GUI von Proxmox VE unterteilt sich grob in vier Bereiche: Im oberen Bereich, dem Header, wird die PVE-Version angezeigt. Außerdem finden Sie hier Schaltflächen für wichtige Aktionen wie "Create VM" et cetera. Der linke Bereich, der Ressource-Tree, ist selbsterklärend und zeigt den Baum, mit dem Sie Zugriff auf die einzelnen Objekte bekommen. Der mittlere Bereich, das Content-Panel, erlaubt es Ihnen, tiefer in die Objekte einzusteigen, und hält jede Menge an diesbezüglichen Konfigurationsoptionen und Status für Sie bereit. Das Log-Panel ganz unten beinhaltet den Task- und Log-Sektor. Hier sehen Sie die Protokolleinträge zu den letzten Tasks ein. Ein Doppelklick auf einen der Einträge bringt dann weiter Details zum Vorschein. Unter [5] finden Sie weitere Erklärugen zum grafischen Interface.
Gehen Sie nun auf dem ersten Host in den Resource-Tree hinein und klicken auf ">_ Shell". Nun öffnet sich das CLI des PVE-Hosts. Hier geben Sie nun apt-get update ein. Und sollte es sich tatsächlich um einen ESXi-Host handeln, auf dem Sie PVE nested installiert haben, könnten Sie hier via UI auch die VMware Tools mit apt-get install open-vm-tools aufspielen. Bevor apt-get update allerdings reibungslos funktioniert, müssen Sie noch einen zusätzlichen Konfigurationsschritt durchführen: Wenn Sie nämlich keinen Subscription-Key bei Proxmox erworben haben, haben Sie auch keinen Zugriff auf das Proxmox VE Enterprise Repository.
Es gibt aber eine Möglichkeit, in Test- und PoC-Umgebungen dennoch mit den entsprechenden Paketen updaten zu können – hier der Link [6] zur PVE-Doku. Entweder Sie arbeiten mit dem Proxmox-VE-No-Subscription-Repository oder mit dem Proxmox-VE-Test-Repository. Sie können beide Varianten verwenden, wobei Zweiteres in der Regel eher von Entwicklern genutzt wird. Erweitern Sie die Datei "/etc/apt/sources.list" um die Zeile "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription". Alles, was Sie nun in diesem PVE-Host gemacht haben, müssen Sie nun auch in den verbleibenden beiden PVE-Hosts durchführen.
Cluster erzeugen und NAS mounten
Jetzt erstellen Sie noch schnell einen Cluster aus den drei PVE-Nodes. Klicken Sie hierzu auf "Rechenzentrum" beziehungsweise "Datacenter", je nachdem, welches Sprachpaket Sie bei der Anmeldung geladen haben. Übrigens können Sie das Sprachpaket auch noch nach der Anmeldung im UI umstellen. Oben rechts im Header der GUI gibt es einen Button mit der Beschriftung "root@pam". Hier loggen Sie sich auch aus und nehmen jede Menge Einstellungen am System vor.
Begeben Sie sich nun in die Mittelregion der GUI in das sogenannte Content-Panel. Gehen Sie jetzt auf "Cluster" und klicken Sie auf "Erstelle Cluster". Nun können Sie mit dem integrierten Cluster-Management aus den drei Nodes Ihren Drei-Node-Cluster aufbauen. Geben Sie in das nun geöffnete Fenster Ihren Wunsch-Cluster-Namen ein. Der Einfachheit halber besteht das Cluster-Netzwerk hier in diesem Lab lediglich aus einem Link für die Cluster-Kommunikation. Beim Nachbau des Labs können Sie genau an dieser Stelle selbstverständlich auch noch weitere Links hinzufügen.
Nachdem Sie "Create" ausgeführt haben, läuft der Cluster-Erstellungs-Task durch und Sie können jetzt die Join-Information-Taste anklicken, um sich die Bei-trittsinfos zu kopieren. Klicken Sie hierzu einfach auf "Copy-Information". Jetzt melden Sie sich an der UI des zweiten Nodes beziehungsweise PVE-Hosts via "https:// <IP-Adresse von PVE-Node 2>:8006" an, gehen ebenfalls in den Cluster-Dialog und klicken auf "Cluster-Join". Kopieren Sie nun die Copy-Information, die Sie in der Zwischenablage haben, in das Information-Feld des Cluster-Beitrittsdialogs. Geben Sie noch das Kennwort für den root-User ein und klicken dann auf "Join '<Name Ihres Clusters>'".
Sie sehen nun im Task-Manager, dass der PVE-Host-2 dem Cluster hinzugefügt wurde. Schauen Sie sich die GUIs beider PVE-Hosts einmal an. In beiden sind jetzt beide PVE-Hosts zu erkennen. Als Nächstes binden Sie noch den dritten PVE-Host auf die gleiche Weise in den Cluster ein und Sie werden alle drei Nodes in jeder GUI gleichermaßen sehen können. Auch ist im Ressource-Tree hinter Datacenter nun auch in Klammer der Name des Clusters ablesbar. Wenn Sie jetzt auf "Datacenter" gehen, wird Ihnen innerhalb des Content-Panels der Health-Zustand des Clusters, die im Cluster befindlichen Ressourcen, die Auslastung der Cluster-Nodes und auch wie viele VMs ein- und ausgeschaltet sind angezeigt.
Im Anschluss mounten Sie noch den Share Ihres NAS. Hierzu klicken Sie wieder auf "Rechenzentrum" beziehungsweise "Datacenter", gehen wieder ins Content auf "Storage" und dann auf das Combo-Box-Steuerelement mit der Aufschrift "Hinzufügen". Hier wählen Sie nun "NFS" aus. Geben Sie nun in das Formularfenster die ID beziehungsweise den eindeutigen Namen für den Share, die IP-Adresse und den Namen des Exportverzeichnisses des NAS ein. Im Feld "Knoten" können Sie sehen, dass der Share an allen Nodes, die sich im Cluster befinden, gemounted wird. Wenn Sie es nicht schon gemacht haben, klicken Sie jetzt innerhalb des Resource-Tree die einzelnen PVE-Hosts an und lassen sich die Ressourcen der Nodes zur Anzeige bringen. Jetzt sollten Sie auch Ihren NFS-Share in den Ressourcen der einzelnen Nodes sehen können.
Die ersten Workloads planen
Für das Erstellen einer VM benötigen Sie natürlich ein OS-Image. Damit Sie neue VMs erzeugen können, sollten Sie zuerst einmal einige Images hochladen. Gehen Sie in der GUI auf den Storage mit der Bezeichnung "local" von einem Ihrer drei Nodes. Nutzen Sie die Schaltfläche "Hochladen", wählen Sie eine Datei von ihrer lokalen Workstation oder einer anderen bevorzugten Quelle aus und beginnen Sie den Upload oder laden Sie die Betriebssystem-Images durch Angabe einer URL über "Von URL herunterladen" in den Image-Store des PVE-Hosts. Während Sie ein ISO in das Repository hochladen, ist die Benutzeroberfläche für weitere Aktivitäten bis zum vollständigen Upload gesperrt. Dauert dieser Upload-Vorgang länger, weil ein Image beispielsweise sehr groß ist, kann über das Browserfenster keine Administration erfolgen. Öffnen Sie im Bedarfsfall eine weitere Browser-Session, um aktiv werden zu können oder auch um das nächste Image hochzuladen.
Vergessen Sie an dieser Stelle nicht, auch das VirtIO-Image upzuloaden. Haben Sie die benötigten Images hochgeladen, beginnen Sie mit dem Deployment eines Workloads. Im ersten Schritt erzeugen Sie eine neue VM. Dazu klicken Sie im Header des UIs auf "Erstelle VM". Ein Hinweis: Nutzen Sie möglichst immer die VirtIO-Devices, da sich hierbei die größtmögliche Leistung erzielen lässt. So etwa ist die Verwendung des generischen VirtIO-Disk-Controllers wesentlich performanter als ein emulierter Controller und auch der Einsatz einer VirtIO-NIC kann ein Vielfaches an Durchsatz gegenüber einer emulierten E1000-NIC liefern. Schauen Sie hierzu auch in die Doku [7].
Im VM-Erstellungsdialog wählen Sie nun als Erstes aus, auf welchem der drei Nodes Ihre erste VM laufen soll. Achten Sie darauf, dass das ISO-File, das Sie benötigen, ebenfalls auf diesem Node zur Verfügung steht. Vergeben Sie nun eine eindeutige VM-ID. Das System schlägt Ihnen in der Regel die 100 vor. Belassen wir es hier einfach dabei und geben einen Namen für die VM ein. Unter dem Reiter "OS" können Sie jetzt das gewünschte Image nebst Betriebssystem-Typ und -Version angeben. Für eine Windows-Installation benötigen Sie das VirtIO-Image und dafür auch ein vCD/vDVD-Laufwerk. Wenn Sie hier als OS "Windows" wählen, dann wird Ihnen angeboten, für das VirtIO-Image ein zusätzliches Laufwerk zu konfigurieren und das Image auszuwählen.
Unter System können Sie nun die VirtIO-Geräte angeben und den Qemu-Agenten aktivieren. Zur Vereinfachung der Konfiguration sind viele der Felder bereits vom Hersteller mit vernünftigen Parametern voreingestellt. Im Auswahlfeld "Maschinentyp" können Sie beispielsweise das Hardwarelayout festlegen. Default ist "Intel 440FX" als virtuelles Mainboard der VM eingestellt. Sie können allerdings auch auf den Q35-Chipsatz umstellen. Haben Sie vor, PCIe-Hardware durchzureichen, entscheiden Sie dies an dieser Stelle. Auch TPM für die VM lässt sich in diesem Formular manuell hinzufügen. Der Disks-Reiter erlaubt neben diversen Einstellungsmöglichkeiten eine Auswahlbox für den Storage, auf den Sie die VM deployen wollen. Alles an Storage, auf das der PVE-Node Zugriff hat, lässt sich im Auswahlfeld "Storage" als Target einstellen. Für unsere Testumgebung sollten Sie hier den lokalen ZFS-RAID-1-Storage, also die internen Disks sowie den NFS-Share, sehen können.
Unter "CPU" weisen Sie Ihrer neuen VM dann noch ihre Sockets und Cores zu. Selbstverständlich können Sie hier in diesem Fenster auch noch Einschränkungen beziehungsweise Limits vorgeben oder auch NUMA erlauben. Das sind allerdings To-Dos für später. Im Reiter "Speicher" tragen Sie die Größe des Memory für Ihren neuen Workload ein. Zuletzt erstellen sie noch den Netzwerkzugang der VM und schließen dann die Konfiguration ab. Bevor Sie die VM einschalten, checken Sie noch einmal die Konfiguration Ihrer VM. Im Content-Panel der VM finden Sie unter dem Punkt "Hardware" die entsprechende Konfiguration. Hier können Sie auch noch nachträgliche Anpassungen vornehmen. Wenn Sie etwa ein weiteres Gerät hinzufügen möchten, dann ist das hier der richtige Ort für Ergänzungen.
VMs installieren
Die virtuelle Hardware ist nun fertiggestellt. Als Image haben Sie ein Windows-Image genommen und das VirtIO-ISO ist ebenfalls im zweiten vCD/vDVD-Laufwerk virtuell eingelegt. Sie beginnen nun mit der Installation des Betriebssystems, indem Sie die VM einschalten. Zuerst einmal klicken Sie Ihre neu erstellte VM im Resource-Tree an. Dann klicken Sie auf den Button "Start" im Content-Panel. Gehen Sie nun auf ">_Konsole" ebenfalls innerhalb des Content-Panels und schon sehen Sie die Konsole der gerade startenden VM.
Folgen Sie nun dem Windows-Installationsdialog bis zu der Stelle, an der Ihr Windows keine Disks für die Installation findet. In diesem Microsoft-Windows-Setup-Fenster klicken Sie nun auf "Load driver" und dann auf "Browse". Im anschließenden Dialog wählen Sie das CD-Drive mit dem VirtIO-Image aus, klicken auf "amd64" und dann auf den für Ihr OS entsprechenden Ordner. Installieren Sie zum Beispiel Windows 10, wäre der richtige Ordner "w10". Nach dem "OK" sollten Sie nun den "Red Hat VirtIO SCSI controller" wählen und dann auch Ihre Windows-Installation fortführen können. Nach der Installation des OS spielen Sie dann noch abschließend die virtio-win-gt-x84-Tools auf, die Sie auf dem VirtIO-Image finden.
Wenn Sie hingegen eine Ubuntu-Linux-VM installieren möchten, dann benötigen Sie das zusätzliche Laufwerk mit dem VirtIO-Image nicht, da die benötigten Disk-Driver bereits vorhanden sind. Allerdings sollten Sie auf dem Linux-Gast nun noch den QEMU-Agenten aufbringen, damit eine optimierte Kommunikation zwischen PVE-Host und -Gast möglich wird. Auch steht erst mit der Installation des Agenten das sogenannte Ballooning zur Verfügung, sodass der Speicher der virtuellen Maschine dynamisch angepasst werden kann. Der Agent lässt sich auf dem Gastsystem ganz einfach über das CLI installieren. Wenn Sie als root installieren möchten, geben Sie sudo -s ein und wechseln zum root-User oder Sie arbeiten einfach mit sudo. Führen Sie erst einmal ein sudo apt-get update aus. Wenn dann alle Pakete aktualisiert sind, führen Sie apt-get install qemu-guest-agent aus. Jetz sollten Sie in der GUI unter "Summary" auch die IP-Adressen der VM sehen können.
Beginnen Sie nun mit Ihren ersten Tests – mit einem Rechtsklick auf einen Ihrer Workloads öffnen Sie ein Dialogfenster. Klicken Sie nun auf "Migrate", wählen den PVE-Zielknoten aus und schon beginnt das Cluster-System mit der Verlegung des Workloads auf den entsprechenden PVE-Node.
Fazit
Proxmox VE ist zweifellos eine interessante Hypervisor-Alternative. Sie können damit virtuelle Maschinen sowie Container laufen lassen und Livemigrationen durchführen. Auch unterschiedliche Arten von Hochverfügbarkeiten sind möglich, ebenso wie der Einsatz von Open vSwitch. Je nachdem, wie Ihre aktuelle Produktions-IT derzeit aufgestellt ist, müssen Sie sich aber auf jeden Fall darüber im Klaren sein, was ein Hypervisor-Wechsel für Sie bedeutet. Um PVE optimal zu nutzen, ist ein nicht zu unterschätzendes Linux-Wissen erforderlich. Ihr Betrieb sollte also mit der Linux-Shell per Du sein. Nehmen Sie sich also Zeit, um all diese Faktoren in der in diesem Workshop in Betrieb genommenen Testumgebung auf Herz und Nieren zu prüfen.