UGREEN NAS: VM-Autostart einrichten und richtig prüfen

Eine VM, die den Router ersetzt, ein Testserver für Kunden oder ein Windows für die Buchhaltung: Solche VMs sollen nach einem Neustart der NAS von selbst wieder laufen. UGOS Pro bietet dafür den Schalter Automatischer Start. Diese Anleitung zeigt, wie er arbeitet, wie Sie per SSH nachweisen, dass er nach jedem Neustart gegriffen hat, und welche Stolperstellen es dabei gibt, von der irreführenden Anzeige in virsh bis zum Herunterfahren der VM.

Die Messwerte stammen von einer UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190, libvirt 9.0.0 und QEMU 7.2, ausgewertet über vier Neustarts der NAS zwischen dem 16.10. und dem 03.11.2026. Der Name der VM ist ersetzt.

Voraussetzungen

• Eine UGREEN NAS mit der App Virtuelle Maschine, siehe Teil 87
• Eine eingerichtete VM
• SSH-Zugang, siehe Teil 52
• Etwa 15 Minuten

Schritt 1: Den Automatischen Start einschalten

Fahren Sie die VM herunter, öffnen Sie in der Liste über die drei Punkte Bearbeiten und schalten Sie Automatischer Start ein.

Die Erklärung beim Info-Symbol lautet: Die VM wird nach dem Hochfahren des NAS automatisch eingeschaltet. Mehr verspricht der Schalter nicht. Für einen Absturz im laufenden Betrieb steht in der Konfiguration unserer VM on_crash mit dem Wert destroy, die VM bleibt dann also aus. Bestätigen Sie die Änderung.

Verifizieren: Beim erneuten Öffnen von Bearbeiten steht der Schalter auf an.

Schritt 2: Die erste Falle, virsh zeigt disable

Wer per SSH nachsieht, stutzt. Unter der Oberfläche arbeitet libvirt, und das meldet für die VM etwas anderes:

sudo virsh list --all
sudo virsh dominfo KENNUNG-DER-VM

Bei uns:

Name:           19f2ade1-d926-4ef9-bb84-52bb0dc47686
State:          shut off
Autostart:      disable

Zwei Dinge fallen auf. Die VM heißt in libvirt nicht wie in der App, sondern trägt eine lange Kennung. Und Autostart steht auf disable, obwohl der Schalter in der App an ist. Das ist kein Fehler. Auch der Dienst libvirt-guests ist ausgeschaltet, systemctl is-enabled libvirt-guests meldet disabled. Trotzdem startet die VM nach jedem Neustart. Den Start übernimmt also UGOS selbst, nicht der Autostart von libvirt. Stellen Sie ihn deshalb nicht mit virsh autostart um. Sonst startet libvirt die VM auch dann, wenn Sie den Schalter in der App ausschalten, und App und libvirt zeigen verschiedene Stände.

Bei nur einer VM ist es die einzige Zeile in virsh list --all. Bei mehreren VMs starten Sie eine davon in der App und rufen sudo virsh list --all erneut auf. Die Kennung mit dem Status running gehört zu dieser VM.

Verifizieren: sudo virsh dominfo KENNUNG zeigt Ihre VM, und Autostart steht weiter auf disable.

Schritt 3: Die zweite Falle, das Protokoll der App schweigt

Die App Virtuelle Maschine hat einen Bereich Protokolle. Die automatischen Starts nach einem Neustart stehen dort bei uns nicht.

Die automatischen Starts nach den Neustarts der NAS fehlen in der Liste. Wer dort nachsieht, ob der Autostart funktioniert hat, findet also nichts, auch wenn alles geklappt hat. Den Nachweis liefert das Protokoll von libvirt.

Verifizieren: Unter Protokolle steht zur Uhrzeit des letzten Neustarts der NAS kein Eintrag Successfully started, obwohl libvirt den Start zeigt.

Schritt 4: Den Autostart im libvirt-Protokoll nachweisen

Für jede VM schreibt libvirt eine eigene Protokolldatei. Die Zeilen zu Start und Ende filtern Sie so heraus:

sudo grep -E "starting up|shutting down" /var/log/libvirt/qemu/KENNUNG-DER-VM.log | cut -c1-70

Die Zeiten stehen in UTC. Daneben legen Sie die Zeitpunkte, zu denen die NAS hochgefahren ist:

last -x reboot | head -5

last zeigt Ortszeit. Bei uns ergab der Vergleich über vier Neustarts:

• 16.10., NAS hoch um 14:37 Uhr, VM gestartet um 12:37:57 UTC, also 14:37:57 Uhr
• 16.10., NAS hoch um 19:36 Uhr, VM gestartet um 17:37:33 UTC, also 19:37:33 Uhr
• 21.10., NAS hoch um 17:02 Uhr, VM gestartet um 15:02:58 UTC, also 17:02:58 Uhr
• 03.11., NAS hoch um 06:58 Uhr, VM gestartet um 05:59:12 UTC, also 06:59:12 Uhr

Im Oktober galt die Sommerzeit mit zwei Stunden Abstand zu UTC, im November die Winterzeit mit einer Stunde. Rechnet man das ein, startete UGOS die VM jedes Mal innerhalb von etwa ein bis zwei Minuten nach dem Hochfahren. UTC ist die Weltzeit, im Winter eine Stunde und im Sommer zwei Stunden hinter der deutschen Ortszeit. Der Autostart hat also bei jedem Neustart gegriffen.

Verifizieren: Zu jedem Neustart der NAS gibt es kurz danach eine Zeile starting up für Ihre VM.

Schritt 5: Die dritte Falle, von Hand ausgeschaltet bleibt aus

Der Automatische Start wirkt nur beim Hochfahren der NAS. Fahren Sie eine VM im laufenden Betrieb herunter, etwa für eine Wartung, bleibt sie aus, bis Sie sie selbst starten oder die NAS neu startet.

Bei uns sieht das so aus: Am 03.11. startete UGOS die VM etwa eine Minute nach dem Hochfahren der NAS. Drei Minuten später haben wir sie selbst heruntergefahren. Seitdem steht sie in der App auf Nicht in Betrieb, obwohl Automatischer Start an ist. Das libvirt-Protokoll zeigt beides, die Zeile starting up und kurz danach shutting down, reason=shutdown. Damit ist belegt, dass der Autostart gearbeitet hat und die VM danach regulär heruntergefahren wurde. Wer sie heruntergefahren hat, steht nicht in diesem Protokoll.

Für VMs, die immer laufen müssen, reicht der Schalter deshalb nicht. Lassen Sie sie zusätzlich überwachen, etwa mit einem Ping- oder TCP-Monitor in Uptime Kuma. Dann meldet Uptime Kuma, wenn eine VM nicht läuft, egal warum.

Verifizieren: Für jede wichtige VM gibt es einen Monitor, der einen Ausfall meldet.

Schritt 6: Sauber herunterfahren

Beim Herunterfahren der NAS fährt UGOS die VMs herunter. Im libvirt-Protokoll steht dabei bei uns terminating on signal 15 from libvirtd, gefolgt von shutting down, reason=shutdown. Die erste Zeile heißt nur, dass libvirt den QEMU-Prozess beendet hat. Sie steht auch dann im Protokoll, wenn Sie die VM in der App herunterfahren. Entscheidend ist der Wert hinter reason: shutdown bedeutet, dass das Gastsystem selbst heruntergefahren ist, destroyed, dass die VM hart ausgeschaltet wurde. Bei uns stand bei beiden Neustarts der NAS, bei denen die VM lief, reason=shutdown.

Als Gegenprobe im Gast zeigt unter Linux

sudo journalctl --list-boots

die letzten Starts, und mit sudo journalctl -b -1 -n 20 sehen Sie die letzten Zeilen vor dem Neustart. Zeigt --list-boots nur einen Eintrag, speichert das System das Journal nicht dauerhaft. Abhilfe schafft sudo mkdir -p /var/log/journal und ein Neustart des Gasts.

Zusätzlich empfiehlt sich der QEMU-Gastagent. Über ihn kann die NAS mit dem Gastsystem sprechen, auch wenn es nicht auf ACPI reagiert. Unsere VM hat den Kanal dafür, org.qemu.guest_agent.0, bereits in ihrer Konfiguration. Unter Debian und Ubuntu:

sudo apt install qemu-guest-agent
sudo systemctl start qemu-guest-agent
systemctl status qemu-guest-agent

Der Dienst startet künftig von selbst, sobald die VM den Kanal bereitstellt. Für Windows gibt es den Gastagenten in den virtio-win Guest Tools. Ob er antwortet, prüfen Sie auf der NAS:

sudo virsh qemu-agent-command KENNUNG '{"execute":"guest-ping"}'

Fahren Sie wichtige VMs vor einem geplanten Neustart der NAS am besten selbst herunter, aus dem Gastsystem heraus oder in der App.

Verifizieren: guest-ping antwortet mit {"return":{}}, und im libvirt-Protokoll steht nach dem Herunterfahren reason=shutdown.

Typische Fehler

• Autostart mit virsh eingeschaltet: Dann startet libvirt die VM unabhängig vom Schalter in der App. Mit sudo virsh autostart --disable KENNUNG zurückstellen und nur den Schalter in der App nutzen.
• VM nach einem Neustart aus: Erst im libvirt-Protokoll nachsehen, ob sie gestartet und danach beendet wurde, und ob jemand sie heruntergefahren hat.
• VM startet nach dem Neustart gar nicht: Schalter Automatischer Start prüfen und ob das Volume mit der VM im Speicher-Manager den Status Normal hat.
• Uhrzeiten passen nicht zusammen: libvirt schreibt UTC, last und UGOS zeigen Ortszeit.
• Datenbank in der VM nach Neustart beschädigt: Prüfen Sie im libvirt-Protokoll den Wert hinter reason. Steht dort destroyed, wurde die VM hart ausgeschaltet. Fahren Sie wichtige VMs dann vor Neustarts selbst herunter.

Häufige Fragen

Kann ich die Reihenfolge der VMs beim Start festlegen?

Die App bietet dafür keine Einstellung, jede VM hat nur den Schalter Automatischer Start. Brauchen Sie eine feste Reihenfolge, starten Sie die abhängige VM von Hand oder warten im Gast auf den benötigten Dienst, etwa mit einer Bedingung in systemd.

Startet UGOS eine abgestürzte VM neu?

Laut Erklärung wirkt der Schalter beim Hochfahren der NAS. Die Konfiguration unserer VM sieht bei einem Absturz on_crash destroy vor, die VM bleibt dann aus. Das prüfen Sie mit sudo virsh dumpxml KENNUNG | grep on_crash. Hängt das Gastsystem nur, bleibt die VM für libvirt in Betrieb. Auch deshalb lohnt der Monitor in Uptime Kuma. Überwachen Sie wichtige VMs deshalb zusätzlich.

Wo finde ich die Kennung meiner VM?

Mit sudo virsh list --all sehen Sie alle Kennungen. Bei mehreren VMs starten Sie eine in der App, die Kennung mit dem Status running gehört zu ihr. Einen Überblick über alle Starts gibt sudo grep -H "starting up" /var/log/libvirt/qemu/*.log | tail.

Gilt der Autostart auch nach einem geplanten Einschalten?

Der Schalter knüpft an das Hochfahren der NAS an, egal ob Sie die NAS von Hand, per Wake-on-LAN oder über den Energie-Zeitplan einschalten, siehe Teil 10. Prüfen Sie nach dem ersten geplanten Einschalten trotzdem einmal im libvirt-Protokoll, ob die VM wie erwartet gestartet ist. Planen Sie umgekehrt ein Ausschalten nach Zeitplan, fahren Sie die VMs am besten vorher aus dem Gast heraus herunter, etwa mit einem Zeitplan im Gastsystem einige Minuten früher.

Wie lange dauert der Start nach dem Hochfahren?

Bei uns vergingen zwischen dem Eintrag von last und der Zeile starting up etwa ein bis zwei Minuten. last zeigt die Startzeit nur auf die Minute genau. Bis das Gastsystem selbst erreichbar ist, kommt dessen Startzeit hinzu. Setzen Sie Monitore in Uptime Kuma deshalb mit einigen Wiederholungen auf, damit ein Neustart der NAS keinen Fehlalarm auslöst.

Fazit

Der Automatische Start in UGOS Pro arbeitet zuverlässig, bei uns nach vier Neustarts jedes Mal innerhalb von etwa ein bis zwei Minuten. Die Fallen liegen in der Anzeige: virsh meldet disable, die App protokolliert automatische Starts nicht, und eine von Hand ausgeschaltete VM bleibt aus. Mit einem Blick ins libvirt-Protokoll, dem Gastagenten und einem Monitor in Uptime Kuma haben Sie Ihre VMs im Griff. Wie Netzwerke für VMs aufgebaut sind, zeigt der nächste Teil zur Netzwerk-Brücke.

Weiterführende Anleitungen und Quellen

• Teil 87: Die App Virtuelle Maschine
• Teil 52: SSH einrichten
• Teil 68: Uptime Kuma
• libvirt: virsh
• QEMU: Guest Agent