Wer auf Proxmox VE mehrere virtuelle Maschinen betreibt, steht früher oder später vor einer simplen Frage: In welcher Reihenfolge sollen die VMs nach einem Neustart des Hosts hochfahren? Startet der Reverse Proxy nach den Webdiensten, sind diese kurzzeitig nicht erreichbar. Startet das Monitoring vor den Applikationsdiensten, laufen die ersten Checks sofort auf Fehler. Mit der richtigen Konfiguration lässt sich das vermeiden.

Was Proxmox kann – und was nicht

Proxmox VE unterstützt keine echten Abhängigkeiten zwischen VMs. Es gibt keine Möglichkeit zu sagen: „Starte VM B erst, wenn VM A vollständig gebootet und erreichbar ist." Was Proxmox stattdessen bietet, ist eine einfache Startreihenfolge mit einem optionalen Verzögerungswert.

Das Prinzip:

• VMs werden in aufsteigender Reihenfolge des order-Wertes gestartet
• Zwischen den Starts wartet Proxmox den konfigurierten up-Delay in Sekunden ab
• Beim Herunterfahren wird die Reihenfolge umgekehrt

Das reicht für die meisten Szenarien aus – solange die Delay-Werte großzügig genug gewählt werden.

Die Konfigurationsparameter

Jede VM hat unter Options → Start/Shutdown Order drei relevante Felder:

Zusätzlich muss Start at boot (onboot) aktiviert sein, damit die Einstellungen beim Hochfahren des Hosts überhaupt greifen.

Per CLI sieht das so aus:

1

qm set 100 --onboot 1 --startup order=1,up=60

Infrastruktur in Tiers einteilen

Der praktischste Ansatz ist es, die VMs in logische Startgruppen (Tiers) einzuteilen. Dienste, die von anderen abhängen, bekommen einen höheren order-Wert.

Beispielinfrastruktur

Angenommen, folgende VMs laufen auf dem Host:

Die Startreihenfolge

Tier 1 – Netzwerk

Ohne Netzwerk läuft gar nichts. Die Firewall muss als erstes hochkommen:

1

qm set 100 --onboot 1 --startup order=1,up=60

60 Sekunden Delay geben OPNsense genug Zeit, Routing-Tabellen und Firewall-Regeln zu initialisieren.

Tier 2 – Reverse Proxy

Ein häufiger Fehler: Den Reverse Proxy erst nach dem Auth-Dienst zu starten. Ohne Proxy ist aber keine einzige Webseite über HTTPS erreichbar – einschließlich der Login-Seite von Authentik selbst. Der Proxy kommt also vor allem anderen:

1

qm set 110 --onboot 1 --startup order=2,up=30

Tier 3 – Authentifizierung / SSO

Erst wenn der Proxy läuft, kann Authentik über seine Domain angesprochen werden. Viele nachgelagerte Dienste nutzen Authentik als Login-Provider – deshalb muss es früh verfügbar sein:

1

qm set 111 --onboot 1 --startup order=3,up=45

Tier 4 – Anwendungsdienste

Alle weiteren Dienste können dann gestaffelt folgen. Dienste ohne gegenseitige Abhängigkeiten bekommen denselben order-Wert:

1
2

qm set 113 --onboot 1 --startup order=4,up=30
qm set 114 --onboot 1 --startup order=4,up=20

Tier 5 – Monitoring

Monitoring-Dienste wie Icinga kommen bewusst ans Ende der Startreihenfolge. Würden sie zu früh starten, würden sie sofort Fehler und Alarme für alle noch nicht laufenden Dienste produzieren. Wenn Icinga als letztes hochfährt, sind alle anderen VMs bereits erreichbar und die ersten Checks laufen sauber durch:

1

qm set 112 --onboot 1 --startup order=5,up=15

Alles auf einmal mit einem Bash-Skript

Statt jede VM einzeln zu konfigurieren, lässt sich das bequem per Skript erledigen. Das Skript muss direkt auf dem Proxmox-Host als root ausgeführt werden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/bin/bash

# Proxmox VM Autostart + Boot Order Setup

declare -A startup=(
  # Tier 1 – Netzwerk
  [100]="order=1,up=60"

  # Tier 2 – Reverse Proxy
  [110]="order=2,up=30"

  # Tier 3 – Auth / SSO
  [111]="order=3,up=45"

  # Tier 4 – Anwendungsdienste
  [113]="order=4,up=30"   # synapse
  [114]="order=4,up=20"   # mastodon

  # Tier 5 – Monitoring
  [112]="order=5,up=15"   # icinga
)

for vmid in "${!startup[@]}"; do
  qm set "$vmid" --onboot 1 --startup "${startup[$vmid]}"
done

echo ""
echo "Fertig. ${#startup[@]} VMs konfiguriert."

Konfiguration prüfen

Nach dem Ausführen lässt sich die Konfiguration einzelner VMs einfach verifizieren:

1

qm config 100 | grep -E "onboot|startup"

Oder für einen Überblick über alle VMs auf einmal:

1
2
3
4
5

for vmid in $(qm list | awk 'NR>1 {print $1}'); do
  echo -n "VMID $vmid: "
  qm config "$vmid" | grep -E "onboot|startup" | tr '\n' ' '
  echo
done

Wichtige Hinweise

• Der up-Delay ist keine Garantie. Proxmox wartet die angegebene Zeit ab, bevor die nächste VM angestoßen wird – nicht bis die aktuelle VM vollständig gebootet ist. Bei langsamen Diensten oder storage-intensiven VMs die Werte großzügig wählen.
• Keine echten Abhängigkeiten. Wer wirklich sicherstellen will, dass Dienst A vollständig läuft, bevor Dienst B startet, braucht externe Lösungen – etwa systemd-Units auf den VMs selbst oder ein Ansible-Playbook nach dem Boot.
• Shutdown-Reihenfolge beachten. Beim Herunterfahren kehrt Proxmox die Reihenfolge automatisch um. Der Proxy fährt also als letztes herunter – das ist in der Regel gewünscht.
• Gleiche order-Werte sind erlaubt. VMs mit demselben order-Wert werden gleichzeitig angestoßen. Das ist nützlich für unabhängige Dienste, die parallel starten können.

Fazit

Die Boot-Order in Proxmox ist kein komplexes Feature, aber mit der richtigen Tier-Einteilung lässt sich eine stabile Startreihenfolge erreichen, die unnötige Fehler beim Hochfahren des Hosts vermeidet. Die wichtigste Regel: Netzwerk → Proxy → Auth → Anwendungen → Monitoring. Wer das als Skript pflegt, hat die Konfiguration versionierbar und jederzeit reproduzierbar.