Erstellen Sie die virtuelle Maschine

Im vorherigen Leitfaden haben Sie diesen einzelnen Proxmox-Knoten abgesichert, und zwar durch ein Nicht-Root-Konto mit Zwei-Faktor-Authentifizierung, eine Firewall und ein API-Token mit eingeschränktem Zugriffsbereich für die Automatisierung. In diesem Leitfaden werden alle drei Elemente genutzt, um die erste virtuelle Maschine zu erstellen, die die Plattform tatsächlich hosten wird – vom Abrufen eines Installations-Images bis hin zu einem laufenden Gast mit einem Betriebssystem.

Installationsimage abrufen

Eine neue Proxmox-Installation wird ohne Installationsmedien ausgeliefert. Bevor also eine virtuelle Maschine auf ein Betriebssystem verweisen kann, muss das Installationsprogramm dieses Betriebssystems an einem Ort vorhanden sein, auf den Proxmox zugreifen kann. Der Bereich „ISO-Images“ auf der Seite des jeweiligen Speichers dient als Speicherort für diese Medien und ist anfangs komplett leer.

Proxmox kann diese Medien selbst direkt auf dem Knoten abrufen, anstatt eine Datei von einem lokalen Rechner über eine langsame Verbindung hochzuladen. Die Schaltfläche „Von URL herunterladen“ im selben Fenster öffnet einen kleinen Dialog, in dem lediglich die Eingabe einer URL erforderlich ist.

In dieser Anleitung wird Debian in der VM installiert – dieselbe Distribution, auf der auch Proxmox selbst läuft –, wobei anstelle einer vollständigen DVD das kleine Netinst-Image verwendet wird: ein paar hundert Megabyte, die den Rest der Pakete, die für die Installation tatsächlich benötigt werden, während des Installationsvorgangs über das Netzwerk herunterladen.

Denn das Betriebssystem des Hypervisors und das, was in dessen virtuellen Maschinen läuft, sind zwei völlig getrennte Bereiche. Die Debian-Basis von Proxmox dient ausschließlich dazu, den Hypervisor-Stack auszuführen, während eine Gast-VM frei wählen kann, was auch immer eine bestimmte Arbeitslast tatsächlich benötigt – und auf einer realen Plattform ist das selten zweimal dieselbe Distribution.

Wenn man die echte Debian-Netinst-URL einfügt und auf „URL abfragen“ klickt, wird die Datei vor dem Herunterladen aufgelöst, wodurch sowohl die tatsächliche Größe als auch der tatsächliche Inhaltstyp bestätigt werden.

Wenn Sie auf „Herunterladen“ klicken, wird der Download auf dem Knoten selbst im Hintergrund ausgeführt – mit einem eigenen Echtzeit-Aufgabenprotokoll anstelle eines Browser-Fortschrittsbalkens, der an diesen einen Tab gebunden ist.

Diese Weiterleitung sollte man sich genauer ansehen, anstatt sie einfach zu überspringen: cdimage.debian.org Proxmox selbst stellt die Datei nie bereit, sondern entscheidet lediglich bei jeder einzelnen Anfrage, welcher echte Mirror am nächsten liegt oder am wenigsten ausgelastet ist, und leitet den Download dorthin weiter. Ein weiterer Versuch aus einem anderen Netzwerk kann auf einem völlig anderen Mirror landen, ohne dass sich auf der Proxmox-Seite etwas ändert.

Sobald der Vorgang abgeschlossen ist, zeigt dieselbe Liste der ISO-Images wie zuvor nun genau eine Datei an, mit einer tatsächlichen Größe und einem tatsächlichen Zeitstempel anstelle eines Platzhalters.

Die Schaltfläche „Von URL herunterladen“ ist im Grunde ein schlanker Wrapper für einen einzigen API-Aufruf. Dies sollte man direkt wissen, sobald dieser Schritt im Rahmen der Bereitstellung einer gesamten Plattform unbeaufsichtigt ausgeführt werden muss, anstatt dass eine Person jedes Mal durch einen Dialog klicken muss:

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/storage/local/download-url" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "content=iso" \
  --data-urlencode "filename=debian-13.7.0-amd64-netinst.iso" \
  --data-urlencode "url=https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.7.0-amd64-netinst.iso"

Das Token ist hier dasselbe opsadmin@pve!automation Das im vorherigen Leitfaden erstellte Token, dessen Geltungsbereich nach wie vor auf die tatsächlich benötigten Berechtigungen beschränkt ist.

Führen Sie den Assistenten zum Erstellen einer VM durch

Über „VM erstellen“ in der oberen rechten Ecke einer beliebigen Proxmox-Seite wird ein Assistent mit acht Registerkarten geöffnet. Dahinter verbirgt sich keine Geheimnisvolle Magie: Alle Felder auf allen acht Registerkarten werden zu einem einzigen Parametersatz zusammengefasst, der am Ende in einem einzigen API-Aufruf übermittelt wird. Wenn man beobachtet, wie jede Registerkarte diesen Aufruf Stück für Stück zusammenstellt, erscheint die API selbst weitaus weniger geheimnisvoll, sobald sie auf der letzten Registerkarte angezeigt wird.

Geben Sie einen Namen für die VM ein und wählen Sie eine VM-ID aus

Auf der Registerkarte „Allgemein“ werden zunächst die am wenigsten interessanten Angaben abgefragt: eine VM-ID, die Proxmox bereits mit der nächsten freien Nummer auf diesem Knoten vorbelegt, und ein Name, der rein kosmetischer Natur ist und das eigentliche Gastbetriebssystem nicht beeinflusst, es sei denn, er wird später manuell übernommen.

Richte es auf das Installationsimage

Auf der Registerkarte „Betriebssystem“ wird das zuvor heruntergeladene ISO-Image tatsächlich verwendet. Wenn man das Feld für das ISO-Image leer lässt und versucht, fortzufahren, wird ein echter Validierungsfehler angezeigt, anstatt dass der Assistent stillschweigend fortfährt.

Durch die Auswahl dieser Datei wird außerdem der „Gastbetriebssystemtyp“ auf „Linux“ gesetzt und die „Version“ auf eine Auswahlliste, die kleiner ist, als sie aussieht: Proxmox unterscheidet hier tatsächlich nur zwischen zwei Linux-Generationen.

Das hat keinerlei Auswirkungen auf das Verhalten. „7.x – 2.6-Kernel“ ist Proxmox’ eigene Kurzbezeichnung für jeden modernen Linux-Kernel ab der 2.6-Serie, was mittlerweile im Wesentlichen jede Distribution umfasst, die noch Updates erhält; „2.4-Kernel“ existiert ausschließlich für wirklich veraltete Gast-Systeme, die noch aus der Zeit vor dieser Version stammen. Debian 13 fällt eindeutig in die erste Kategorie, ungeachtet der Zahl „7“ in der Bezeichnung.

Behalten Sie die Systemstandardwerte bei und aktivieren Sie ein Kontrollkästchen

Die Standardeinstellungen auf der Registerkarte „System“ sind für eine erste VM bereits sinnvoll: „VirtIO SCSI single“ als Festplattencontroller, „Default (i440fx)“ als Maschinentyp und „SeaBIOS“ anstelle von UEFI. Das einzige Kontrollkästchen, das bewusst angekreuzt werden sollte, ist „Qemu Agent“, das standardmäßig nicht markiert ist.

Das Aktivieren dieses Kontrollkästchens führt an sich zu keiner Installation, sondern weist Proxmox lediglich an, mit einem Gast-Agenten zu rechnen, der über einen virtuellen seriellen Kanal kommuniziert. Ob dieser Agent tatsächlich im Gast läuft, ist eine andere Frage, auf die diese Anleitung zurückkommt, sobald das Betriebssystem selbst installiert ist.

Größe der virtuellen Festplatte festlegen

Auf der Registerkarte „Disks“ ist standardmäßig eine 32-GiB-Festplatte auf „local-lvm“ voreingestellt – mehr, als diese erste VM benötigt, und mehr, als der im vorherigen Leitfaden festgelegte Thin-Pool allein bewältigen müsste. Wenn man die Größe auf 16 GiB reduziert, bleibt reichlich Platz für eine Debian-Basisinstallation und deren Protokolle, ohne mehr von diesem Pool zu beanspruchen, als eine erste Test-VM rechtfertigt.

CPU-Kerne zuweisen

Auf der Registerkarte „CPU“ sind standardmäßig ein Sockel, ein Kern und der CPU-Typ „x86-64-v2-AES“ eingestellt, anstatt des genauen Modells des Hosts. Durch die Erhöhung der Kernanzahl auf 2 verfügt diese VM über genügend Leistung, um tatsächlich parallele Aufgaben auszuführen.

Diese Voreinstellung steht in bewusstem Kontrast zu der Wahl in dem früheren Leitfaden, -cpu host Für den Betrieb von Proxmox selbst in einer Testumgebung: Eine Gast-VM auf einer realen Plattform muss möglicherweise eines Tages auf eine andere physische Hardware migriert werden, und ein CPU-Typ, der an den genauen Funktionsumfang dieses einen Hosts gebunden ist, würde dazu führen, dass diese Migration von vornherein fehlschlägt. Ein portabler Basistyp opfert einen geringen Teil der reinen Leistung zugunsten der Portabilität – was in der Regel der richtige Kompromiss für alles ist, was tatsächlich für Kunden eingesetzt wird.

Speicherobergrenze festlegen

Auf der Registerkarte „Speicher“ ist standardmäßig ein Wert von 2048 MiB voreingestellt. Wenn Sie „Erweitert“ aktivieren, werden dieselben Optionen „Ballooning-Gerät“ und „KSM zulassen“ angezeigt, die bereits im vorherigen Leitfaden behandelt wurden; beide sind standardmäßig bei jeder neuen VM aktiviert.

Der anfängliche Mindestspeicher entspricht zunächst dem Gesamtspeicher, was bedeutet, dass noch kein tatsächlicher Ballooning-Bereich vorhanden ist; dieser wird erst dann sinnvoll, wenn dieser Mindestwert gesenkt wird, sodass Proxmox die Differenz bei echtem Speicherbedarf von einer inaktivierten VM zurückgewinnen kann.

Befestige es an der Brücke

Auf der Registerkarte „Netzwerk“ wird die VM an vmbr0 angebunden – dieselbe Bridge, die bereits im vorherigen Leitfaden behandelt wurde –, wobei das VirtIO-Modell verwendet wird, um die bestmögliche Leistung zu erzielen, die ein paravirtualisierter Treiber bieten kann. Die Firewall ist standardmäßig auf der Netzwerkschnittstelle selbst aktiviert.

Dieses Kontrollkästchen ist ein anderer Schalter als die zuvor besprochene Aktivierung der Firewall auf Rechenzentrumsebene, die auf diesem Knoten nach wie vor deaktiviert ist. Das Aktivieren dieses Kontrollkästchens hat hier zwar noch keine sichtbaren Auswirkungen, bedeutet aber, dass der Datenverkehr dieser VM, sobald der Master-Switch später aktiviert wird, bereits durch die für sie geltenden Regeln abgedeckt ist, anstatt dass jede Schnittstelle einzeln neu überprüft werden muss.

Überprüfen und erstellen

Auf der Registerkarte „Bestätigen“ werden alle Werte aus den vorherigen Registerkarten als einfache Schlüssel-Wert-Tabelle dargestellt. Diese Tabelle ist keine für Menschen verständliche Zusammenfassung, sondern der tatsächliche Request-Body, den der Assistent gleich absenden wird.

Wenn man nach der Erstellung „Start“ markiert und auf „Fertigstellen“ klickt, wird genau diese Tabelle als einzelne echte API-Anfrage gesendet, die hier vollständig wiedergegeben und nicht nur vermutet wird:

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "vmid=100" \
  --data-urlencode "name=web01" \
  --data-urlencode "ostype=l26" \
  --data-urlencode "ide2=local:iso/debian-13.7.0-amd64-netinst.iso,media=cdrom" \
  --data-urlencode "scsihw=virtio-scsi-single" \
  --data-urlencode "scsi0=local-lvm:16,iothread=on" \
  --data-urlencode "agent=1" \
  --data-urlencode "sockets=1" \
  --data-urlencode "cores=2" \
  --data-urlencode "cpu=x86-64-v2-AES" \
  --data-urlencode "memory=2048" \
  --data-urlencode "net0=virtio,bridge=vmbr0,firewall=1" \
  --data-urlencode "start=1"

Dieser einzelne Aufruf erstellt und startet die VM zugleich, was durch zwei separate, tatsächliche Vorgänge im Protokoll anstelle von nur einem bestätigt wird: „VM 100 – Create“, unmittelbar gefolgt von „VM 100 – Start“.

Vom Installationsprogramm booten

Wenn Sie die Registerkarte „Konsole“ dieser VM öffnen, gelangen Sie direkt in dasselbe Debian-Installations-Bootmenü, das bereits in der vorherigen Anleitung auf dem physischen Host ausführlich beschrieben wurde – nur dass es diesmal in der Konsole einer VM statt auf einem physischen Rechner ausgeführt wird. Die folgenden Bildschirme sind in beiden Fällen identisch, daher geht diese Anleitung beim zweiten Mal schneller durch die einzelnen Schritte und geht nur auf die Punkte ein, die bei einer Gastinstallation wirklich neu oder anders sind.

Der Countdown unten ist es wert, gelesen statt ignoriert zu werden: Wenn man das Menü unverändert lässt, wird nicht einfach die markierte Standardeinstellung ausgewählt, sondern schließlich der Installationspfad für die Sprachausgabe aufgerufen – ein deutlich anderer Ablauf, der auf Audioansagen statt auf den üblichen Dialogfenstern basiert. Durch Drücken einer beliebigen Pfeiltaste wird der Countdown abgebrochen, sodass der normale Eintrag „Installieren“ bewusst ausgewählt werden kann.

Das Gastbetriebssystem installieren

Sprache, Standort und Tastaturlayout entsprechen den Einstellungen, die bereits bei der Proxmox-Installation selbst vorgenommen wurden. Die erste wirklich neue Abfrage betrifft den Hostnamen. Es empfiehlt sich, diesen so festzulegen, dass er mit dem Namen der VM in Proxmox übereinstimmt, anstatt den von Debian vorgegebenen Platzhalter zu übernehmen.

Beim Einrichten eines Nicht-Root-Benutzerkontos tritt ein echter, realer Validierungsfehler auf, über den man im Voraus Bescheid wissen sollte: Einige Benutzernamen sind vom System selbst reserviert und werden sofort abgelehnt, egal wie sinnvoll sie auch klingen mögen.

„operator“ kollidiert mit einem tatsächlichen Unix-Konto, das historisch für Systemoperationen verwendet wurde, auch wenn es wie ein durchaus sinnvoller Name für den Administrator-Benutzer einer Plattform erscheint. „opsadmin“, derselbe Name, der bereits im vorherigen Leitfaden für das Proxmox-Admin-Konto verwendet wurde, funktioniert ohne Konflikte und sorgt für eine einheitliche Namensgebung zwischen dem Hypervisor und den darauf laufenden VMs.

Die geführte Partitionierung unter Verwendung der gesamten virtuellen Festplatte erzeugt eine echte, funktionsfähige Partitionstabelle, ohne dass manuelle Berechnungen zur Festplattengröße erforderlich sind: ein ext4-Root-Dateisystem, dessen Größe den größten Teil der Festplatte einnimmt, und eine Swap-Partition, deren Größe sich nach dem Arbeitsspeicher der VM richtet.

Wiederherstellung nach einem fehlerhaften Archiv-Mirror

Unmittelbar nach Abschluss der Installation des Basissystems versucht das Installationsprogramm, über das Netzwerk einen Debian-Paket-Mirror zu erreichen, um apt für den weiteren Verlauf der Installation zu konfigurieren. Diese Überprüfung kann tatsächlich fehlschlagen, und es lohnt sich, zu wissen, wie der Fehler konkret aussieht, anstatt einfach anzunehmen, dass etwas irreparabel kaputt ist.

Auf echter Hardware deutet dies in der Regel auf ein Problem hin, das spezifisch mit dem Internetzugang dieser VM zusammenhängt: einen DNS-Server, der vom Gast aus noch nicht erreichbar ist, eine Firewall-Regel, die ausgehenden HTTPS-Verkehr blockiert, oder einfach einen Mirror, der vorübergehend überlastet ist und bei dem es sich lohnt, es einen Moment später erneut zu versuchen. Aus genau diesem Grund gelingt es manchmal, wenn man zurückgeht und denselben Mirror erneut auswählt, beim zweiten Versuch eine Verbindung herzustellen.

Wenn es immer wieder fehlschlägt, bietet das Installationsprogramm selbst einen echten Ausweg statt einer Sackgasse: die Installation ganz ohne Netzwerk-Mirror abzuschließen.

Wenn Sie hier „Ja“ wählen, wird eine Installation mit vollem Funktionsumfang zugunsten einer funktionsfähigen Installation aufgegeben: Bei der späteren Softwareauswahl stehen nur die Komponenten zur Verfügung, die bereits auf dem Netinst-Image selbst enthalten sind, wobei ein SSH-Server oder der Gast-Agent nicht zur Auswahl stehen. Sobald das installierte System mit echtem, funktionierendem Netzwerkzugang hochfährt, erfolgt eine normale apt update vor einem richtigen Spiegel in /etc/apt/sources.list erfasst alles, was der Installateur überspringen musste.

Installation abschließen und neu starten

Ohne Spiegel werden bei der Aufgabenauswahl nur die bereits auf der ISO vorhandenen Standard-Systemdienstprogramme installiert, und das Installationsprogramm schreibt GRUB direkt auf die Festplatte, auf der es tatsächlich installiert wurde, anstatt zu raten.

Ein anschließender Neustart führt dann zum eigentlichen, installierten System und nicht mehr zum Installationsprogramm, wobei eine Anmeldeaufforderung als Beweis dafür dient, dass der gesamte Vorgang tatsächlich einen funktionsfähigen Gast-Rechner erzeugt hat.

Überprüfen Sie, ob der Guest Agent ausgeführt wird

Das erneute Aktivieren des Qemu-Agenten auf der Registerkarte „System“ hat Proxmox lediglich darauf hingewiesen, dass ein Agent erwartet wird; da während der Installation kein Netzwerk-Mirror vorhanden war, wurde dieser Agent im Gastbetriebssystem nie tatsächlich installiert, ebenso wenig wie ein SSH-Server. Beides lässt sich mit einem einzigen Befehl erledigen, sobald der Gast selbst über einen echten Internetzugang verfügt, sei es nun ein korrigierter /etc/apt/sources.list nach einem Spiegelausfall oder einer normalen Installation, bei der von Anfang an ein funktionierender Netzwerkzugang bestand:

apt update
apt install -y qemu-guest-agent openssh-server

Sobald dieser Agent gestartet ist und sich meldet, wird auf der Proxmox-Registerkarte „Zusammenfassung“ nicht mehr ein leeres IP-Feld angezeigt, sondern eine tatsächliche Adresse, die aus dem Gastbetriebssystem selbst abgerufen wird und nicht mehr auf der Grundlage der Netzwerkebene außerhalb des Gastbetriebssystems geschätzt wird.

Die gleichen Informationen sind über die API verfügbar. Ein Provisioning-Skript würde also tatsächlich diese Daten abfragen, anstatt darauf zu warten, dass jemand die Registerkarte „Zusammenfassung“ aufruft:

curl -k "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/agent/network-get-interfaces" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>"