Virtuelle Maschinen (VMs)

Um eine VM erstellen zu können, benötigt man ein ISO-Image, von dem aus das Betriebssystem für die Basisinstallation gebootet werden kann. Ein solches muss man auf dem PVE zunächst bereitstellen. Dazu geht man auf der Web-GUI auf den Knoten und dort auf "local ({Knotenname})/ISO Images". Dort kann man auf den Button "Upload" klicken, um ein lokal bereitliegendes Imagefile hochzuladen oder man klickt auf "Download from URL", um ein Imagefile aus dem Netz zu laden. Für die letztere Option kopiert man einen Download-Link in das Feld "URL" und klickt auf "Query URL". Dann wird der Link geprüft und wenn unter dem Pfad ein ISO-Image gefunden wird, dann werden die restlichen Felder des Dialogfelds entsprechend befüllt. Wenn die Felder nicht befüllt werden, dann wurde unter dem eingetragenen Pfad kein ISO-Image gefunden.

Nach Klick auf "Download" startet der Download. 

Um eine neue VM zu erstellen, klickt man auf der Web-GUI des PVE auf den blauen Button "Create VM" der stets rechts oben verfügbar ist. Der erscheinende Dialog führt mit den Registern "General", "OS", System", "Disks", "CPU", "Memory", "Network" und "Confirm" komfortabel durch die Konfiguration der neuen VM.

Node ist voreingestellt und wenn man kein Cluster betreibt, dann lässt sich hier auch nichts ändern. Die VM ID ist ein Vorschlagswert. Das System zählt automatisch die IDs hoch, beginnend bei dem Wert, den man hierfür bei Einrichtung des PVE bzw. Clusters vorgegeben hat. Den Vorschlagswert kann man beliebig ändern. Die ID sollte aber im lokalen Netz eindeutig sein. Insbesondere, wenn man mehrere PVEs und einen PBS verwendet, kann es sonst zu Problemen kommen. Es könnte auch klug sein, IDs von Servern, die man in Rente geschickt hat, nicht zu recyclen.  Da man bis zu 1.000.000 IDs zur Auswahl hat, sollte es zunächst keinen Engpass geben. Der Name des Server ist für das Handling über die Web-GUI relevant, wird zumindest bei Linux-Servern bei der Einrichtung als Vorschlagswert für den Hostnamen verwendet und soweit unterstützt auch als Name im Netzwerk angezeigt. Das Häkchen bei "Start at boot" sollte man für Server grundsätzlich setzen. Es erscheint zweckmäßig, dass virtuelle Server mit dem Host hochfahren, wenn letzterer neu startet. Wenn man jedoch eine Einschaltreihenfolge verschiedener Systeme bei Neustarts einhalten muss, dann lässt man dieses Häkchen weg.

Neu uns schön ist die Möglichkeit, virtuellen Systemen Tags mitzugeben. So kann man sie mit verschiedenen Merkmalen lablen, die in Übersichten durch farbige Kreise dargestellt werden.   

Auf der Registerkarte "OS" kann man das Bootmedium auswählen. Hier wählt man in der Regel das zuvor hochgeladene ISO-Image aus. Man kann aber auch ein physikalisches CD- oder DVD-Laufwerk, das ggf. am PVE angeschlossen ist, verwenden. "Do not use any media" kann eine sinnvolle Option sein, wenn man z.B. eine VM aus der Sicherung neu aufbauen möchte. Unter "Guest OS" sind voreingestellt "Type:" "Linux" und "Version" "6.x...". Das kann man in der Regel so lassen.

Die Angaben unter "System" kann man für virtuelle Systeme in der Regel so lassen. Nur den Parameter "Qemu Agent" sollte man anhaken. Er ermöglicht eine bessere Kommunikation zwischen Host und Gast, z.B. beim Herunterfahren oder bei Snapshot-Sicherungen. TPM kann für Windows-Gäste wichtig sein, aber das interessiert hier nicht weiter.

Hier kann man dem Gast virtuelle Platten zuweisen. Die meisten voreingestellten Parameter kann man in der Regel übernehmen. Wenn mehrere Storages angebunden sind, die den Content "Container" zulassen, dann kann man hier den passenden auswählen. Die Diskgröße muss man natürlich passend wählen. Es ist möglich, eine Volumegröße über die Web-GUI des PVE nachträglich zu erhöhen, nicht aber zu verkleinern. Außerdem muss diese Größenänderung beim Gast auch umgesetzt werden, was schon komplizierter ist und eine hohe Chance auf Datenverlust mit sich bringt. Also besser vorher gut überlegen. Spannend ist hier der Haken bei "Backup", der standardmäßig gesetzt ist, aber entfern werden kann. Wenn der Haken fehlt, dann wird das entsprechende Laufwerk bei Sicherungen des Gastes nicht mit berücksichtigt. Bei durchgereichten Laufwerken kann es sinnvoll sein, den Haken zu entfernen. Das lässt sich aber auch später noch über die Web-GUI ändern.

Unter dem Register "CPU" kann man die Anzahl der Kerne und ein CPU-Limit vorgeben. Das Limit beschreibt in Prozent, welchen Anteil an der physikalischen CPU-Kapazität der LCX maximal belegen darf. Hier ist auch eine erhebliche Überprovisionierung möglich, was dann für die Priorisierung der CPU-Ressourcenzuweisung zwischen den Gästen genutzt werden kann. Durch sinnvolle Steuerung der CPU-Limit-Werte der Gäste kann man die maximale Auslastung des Hosts steuern. Der Wert unter "CPU Units" dient ebenfalls der Priorisierung der CPU-Ressourcenzuweisung.

Ich gebe meinen VMs in der Regel 2 oder 4 virtuelle Kerne auf einem Sockel. Den Typ sollte man nur ändern, wenn man für einen Gast spezielle Anforderungen hat.

Der Speicher wird im MiB angegeben. Ich gebe meinen VMs entweder 2 GiB (2048 MiB) oder 4 GiB (4096 MiB). Hier ist eine Überprovisionierung möglich. Man muss dann aber die Auslastung des Hosts im Blick behalten.

Unter Network werden die Netzwerkbrücken angeboten, die bei Einrichtung des PVE erstellt wurden. Soweit man hier keine speziellen Anforderungen hat, kann man die Vorschlagswerte für alle Parameter übernehmen.

Auf der letzten Registerkarte werden noch einmal alle gewählten Parameter angezeigt und man kan wählen, ob die VM nach Erstellung direkt gestartet werden soll.