Das automatische Starten von VMs in Proxmox ist eine häufige Aufgabe, insbesondere wenn die gesamte Umgebung nach einem Neustart nahtlos wieder online sein soll. Ehrlich gesagt ist es aber ziemlich knifflig, alles perfekt einzustellen, vor allem, wenn man mehrere VMs verwaltet, die voneinander abhängig sind oder in einer bestimmten Reihenfolge starten müssen. Normalerweise aktivieren Benutzer einfach die Option „Beim Systemstart starten“ in der Web-Oberfläche. Das reicht aber oft nicht aus, wenn man benutzerdefinierte Verzögerungen, bestimmte Startprioritäten oder eine skriptgesteuerte Reihenfolge wünscht. Außerdem funktioniert der standardmäßige automatische Start in manchen Umgebungen nicht reibungslos, insbesondere bei Netzwerkspeicher oder Clusterumgebungen. Dieser Artikel beschreibt, wie man dieses Problem behebt und sicherstellt, dass die VMs in der richtigen Reihenfolge starten – gegebenenfalls mit Verzögerungen – ohne dabei Probleme zu verursachen.
Wie man den automatischen VM-Start und die benutzerdefinierte Bootreihenfolge in Proxmox behebt
Methode 1: Aktivieren des automatischen Basisstarts über die grafische Benutzeroberfläche und Konfigurieren der Prioritäten
Dies eignet sich gut, wenn Sie lediglich eine einfache Funktion zum Starten beim Systemstart mit etwas Steuerung der Startreihenfolge benötigen. Sie ist besonders nützlich, wenn Ihre VMs nicht stark von komplexen Startsequenzen abhängen. Wenn Sie „ Beim Systemstart starten“ aktivieren, kümmert sich Proxmox automatisch um die VMs – praktisch, oder? Manchmal ist dies jedoch etwas ungenau, da die VMs in keiner bestimmten Reihenfolge gestartet oder Verzögerungen ignoriert werden. Um dies anzupassen, können Sie die Start-/Herunterfahrreihenfolge und die Startverzögerung im selben Menü festlegen.
- Gehen Sie zu Rechenzentrum -> Knoten -> wählen Sie Ihren Knoten aus -> VMs
- Klicken Sie auf Ihre VM und wechseln Sie dann zu Optionen.
- Beim Systemstart starten auf Ja setzen
- Stellen Sie die Start-/Abschaltreihenfolge ein : 1 bedeutet, dass das Gerät zuerst startet, höhere Zahlen später.
- Legen Sie die Startverzögerung (in Sekunden) fest, wenn Sie den Vorgang verlangsamen möchten, damit die Dienste ordnungsgemäß starten können.
Das ist eigentlich ganz einfach, aber denken Sie daran: Es funktioniert nur, wenn Ihr Cluster oder Ihre Konfiguration diese Einstellungen nicht überschreibt. Bei der Konfiguration mehrerer VMs ist die Reihenfolge wichtig: Wenn Ihr Datenbankserver vor den Anwendungen gestartet werden muss, geben Sie ihm eine niedrigere Nummer.
Methode 2: Mehr Kontrolle und Verzögerungen über die Befehlszeile
Manchmal reichen die Optionen der grafischen Benutzeroberfläche nicht aus, insbesondere für benutzerdefinierte Startsequenzen oder Verzögerungen bei der Initialisierung von Netzwerkdiensten. Hier spielt die Befehlszeile ihre Stärken aus. Sie können eine VM so konfigurieren, dass sie beim Systemstart mit einem kurzen Befehl automatisch gestartet wird:
# qm set <vmid> -onboot 1Dies ist die einfachste Methode, um sicherzustellen, dass die VM nach einem Neustart startet. Was aber, wenn Sie eine Verzögerung wünschen? Hier kommt die Einstellung „startall-onboot-delay“ in der Hostkonfiguration ins Spiel. Diese verzögert den Start aller VMs einheitlich, was hilfreich sein kann, wenn Sie warten, bis sich Speicher oder Netzwerk stabilisiert haben.
# pvenode config set --startall-onboot-delay 120In diesem Beispiel warten alle VMs 2 Minuten, bevor sie starten. Das ist praktisch für größere Setups, bei denen Abhängigkeiten etwas Vorlaufzeit benötigen.
Methode 3: Skripten Ihrer Startsequenz mit Bash
Immer noch nicht genug? Sie wollen eine präzise Reihenfolge mit benutzerdefinierten Pausen? Der Trick ist, ein Skript zu erstellen. Schreiben Sie ein Shell-Skript, das die VMs qm start <vmid>in der gewünschten Reihenfolge aufruft und sleepBefehle für Verzögerungen enthält. Speichern Sie dieses Skript an einem sicheren Ort, machen Sie es ausführbar und starten Sie es beim Systemstart über systemd. Funktioniert wie von Zauberhand – zumindest bei mir auf einer Konfiguration, die sich weigerte, VMs standardmäßig in der richtigen Reihenfolge zu starten.
# nano /root/start-vm-order.shDann im Inneren:
#!/bin/bash qm start 101 echo "Started VM 101" sleep 60 # wait 60 seconds for DNS, network, etc.qm start 102 echo "Started VM 102" sleep 120 # wait 2 minutes before next qm start 103 echo "Started VM 103"Speichern, ausführbar machen:
# chmod +x /root/start-vm-order.shErstellen Sie nun einen systemd-Dienst, der beim Systemstart ausgeführt wird:
# nano /etc/systemd/system/autostartvm.service [Unit] Description=Start Proxmox VMs in sequence After=network.target [Service] Type=oneshot ExecStart=/root/start-vm-order.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target Aktivieren:
# systemctl enable autostartvm.serviceStarten Sie den Host neu und überprüfen Sie den Status:
# journalctl -u autostartvm.service -bEs ist nicht perfekt, aber ziemlich flexibel. Und wer es etwas ausgefeilter mag, kann Netzwerkprüfungen oder andere Skripte hinzufügen, um vor dem Starten von VMs auf verfügbare Dienste zu warten.
Bonus: Überlegungen zu HA-Clustern
Wenn Sie einen Cluster mit aktivierter Hochverfügbarkeit (HA) verwenden, können Sie die Einstellungen für „Beim Systemstart starten“ oder die „Startreihenfolge“ einzelner VMs vergessen – diese werden vom HA-Manager verwaltet. Sie müssen die HA-Einstellungen anpassen oder die Skripte entsprechend ändern. Denn natürlich muss Proxmox es immer unnötig kompliziert machen, nicht wahr?
Noch ein Hinweis: Bei manchen Konfigurationen kann der automatische Start weiterhin unzuverlässig sein, wenn Netzwerk oder Speicher nicht verfügbar sind. In solchen Fällen ist die Skriptmethode wahrscheinlich die zuverlässigste, insbesondere in Kombination mit Prüfungen der Netzwerk- oder Serververfügbarkeit vor dem Start der VM.
Zusammenfassend lässt sich sagen, dass Sie mit einer Kombination aus GUI-Anpassungen, CLI-Befehlen und benutzerdefinierten Skripten das Startverhalten Ihrer VMs nach einem Serverneustart nahezu exakt steuern können. Die Einrichtung ist zwar etwas aufwendig, aber sobald alles konfiguriert ist, läuft es reibungslos – oder nahezu reibungslos.