[SOLVED] Options Parameter "Start at boot = Yes" funktioniert nur in bestimmten Fällen.

[whecker]

Guten Tag,
zuächst möchte ich das Forum als Neuling mit mäßigen Erfahrungen in Linux und Proxmox begrüßen. Ich habe auf meiner Testmaschine Proxmox 7.0-8 installiert.
32 GB RAM, Intel i5 Prozessor mit 6 Kernen (12 Threads), Motherboard ist Asrock I590 mit 1GB M.2 Speicher

4 VMs sind auf einem Node installiert.
VM-ID OS
100 Windows10 (Start at Boot = Yes)
101 Windows10 (Start at Boot = Yes)
110 Debian Desktop (Start at Boot = No)
111 Debian Server (Start at Boot = No)

Die VMs laufen bisher mit guter Performance. Ich bin z. Zt. dabei, die Start und Stop Situationen für den Produktivbetrieb zu testen. Der shutdown des Nodes funktioniert gut. Alle VMs werden sicher heruntergefahren. Probleme bereitet mir der Start des Nodes mit den VMs, die ich mit den Option Parametern "Start at Boot = Yes" konfiguriert habe. Diese VMs booten nur, wenn sie zuvor beim Node Shutdown durch das System heruntergefahren wurden. Wenn ich die VMs vorher manuell heruntergefahren habe, entweder im OS oder im Proxmox GUI, funktioniert das automatische booten über den "Start at boot = Yes" Parameter nicht.
Ich weiß jetzt nicht, ob das ein normales Verhalten des Systems ist oder nicht. Ich hätte erwartet, das der Parameter die VMs bei allen boot-Aktionen startet. Möglicherweise hab ich auch unwissend andere Parameter für diese automatische Boot-Funktion falsch gesetzt. Kann mir da jemand helfen?

Grüße
Wilfried

 

[t.lamprecht]

Hi,

Ich weiß jetzt nicht, ob das ein normales Verhalten des Systems ist oder nicht.

Klingt nicht nach normalen Verhalten.

Nach dem Booten wird das starten aller Container und VMs mit einen eigenen Task gemacht, der heißt in etwa "Start all VMs and Container", kannst du so einen suchen und in den Tasklog (durch doppelklick öffnen) ansehen um zu schauen ob da ein Fehler geloggt wird?

Schaut in etwa so aus:


Ansonsten wäre es auch interessant im Syslog nach Fehlermeldungen knapp nach dem Booten zu suchen.

 

[whecker]

Ich habe mal einen Screenshot vor dem Reboot gemacht und nach dem Reboot. Darin ist zu sehen, dass immer nur die VMs wieder hochgefahren werden, die auch vor dem Reboot hochgefahren waren. Die Tasks sind alle mit OK beendet worden. Auffällig ist aber, das beim Hochfahren für die VM, die vor dem Reboot down war, kein Task zum Booten erstellt wurde.


Vor dem Reboot


Nach dem Reboot. Nur die VMs, die auf Start at Boot = Yes standen UND vor dem Reboot hochgefahren waren, sind auch gestartet worden.

Alle Tasks sind ohne Fehlermeldungen. Vm 100 hat keine Task zum Start bekommen.


Vor dem 2. Bootvorgang mit beiden Vms hochgefahren.


und nachher, ebenfall mit beiden VMs gestartet.

 

[whecker]

Hi,

Klingt nicht nach normalen Verhalten.

Nach dem Booten wird das starten aller Container und VMs mit einen eigenen Task gemacht, der heißt in etwa "Start all VMs and Container", kannst du so einen suchen und in den Tasklog (durch doppelklick öffnen) ansehen um zu schauen ob da ein Fehler geloggt wird?

Schaut in etwa so aus:
View attachment 28902

Ansonsten wäre es auch interessant im Syslog nach Fehlermeldungen knapp nach dem Booten zu suchen.

Ich habe mal einen Screenshot vor dem Reboot gemacht und nach dem Reboot. Darin ist zu sehen, dass immer nur die VMs wieder hochgefahren werden, die auch vor dem Reboot hochgefahren waren. Die Tasks sind alle mit OK beendet worden. Auffällig ist aber, das beim Hochfahren für die VM, die vor dem Reboot down war, kein Task zum Booten erstellt wurde.

Vor dem Reboot

Nach dem Reboot. Nur die VMs, die auf Start at Boot = Yes standen UND vor dem Reboot hochgefahren waren, sind auch gestartet worden.

Alle Tasks sind ohne Fehlermeldungen. Vm 100 hat keine Task zum Start bekommen.

Vor dem 2. Bootvorgang mit beiden Vms hochgefahren.

und nachher, ebenfall mit beiden VMs gestartet.

 

[BigBen]

Nach meinen Verständnis würde ich beim Parameter "Start at Boot" immer davon ausgehen, dass das betreffende System beim nächsten Boot von Proxmox automatisch gestartet wird.

Alles andere wäre widersinnig. Warum sollte PVE ein Booten vom Zustand das Systems vor dem Reboot vom PVE abhängig machen sollen?

Wie verhält sich denn PVE bei VMs, die vor dem Reboot aktiv waren, aber kein "Start at Boot" haben? Wird hier auch der letzte Zustand wieder hergestellt und die VM auch neu gestartet?

 

[whecker]

Hier ist ein Auszug aus dem Syslog nach dem node Boot-Vorgang bei dem einer der VMs nicht gebootet wurde.
Hier scheint mir bei VM 100 was nicht ok zu sein. Ich kann das Syslog aber nicht richtig deuten.

Aug 24 15:12:50 node1 pve-ha-crm[1801]: service 'vm:100': state changed from 'freeze' to 'request_stop'
Aug 24 15:12:50 node1 pve-ha-crm[1801]: service 'vm:101': state changed from 'freeze' to 'started'
Aug 24 15:12:50 node1 pve-ha-lrm[1811]: successfully acquired lock 'ha_agent_node1_lock'
Aug 24 15:12:50 node1 pve-ha-lrm[1811]: watchdog active
Aug 24 15:12:50 node1 pve-ha-lrm[1811]: status change wait_for_agent_lock => active
Aug 24 15:12:50 node1 pve-ha-lrm[1881]: starting service vm:101
Aug 24 15:12:50 node1 pve-ha-lrm[1882]: start VM 101: UPID:node1:0000075A:00000738:6124F052:qmstart:101:root@pam:
Aug 24 15:12:50 node1 pve-ha-lrm[1881]: <root@pam> starting task UPID:node1:0000075A:00000738:6124F052:qmstart:101:root@pam:
Aug 24 15:12:50 node1 systemd[1]: Created slice qemu.slice.
Aug 24 15:12:50 node1 systemd[1]: Started 101.scope.
Aug 24 15:12:51 node1 systemd-udevd[1910]: Using default interface naming scheme 'v247'.
Aug 24 15:12:51 node1 systemd-udevd[1910]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Aug 24 15:12:51 node1 kernel: device tap101i1 entered promiscuous mode
Aug 24 15:12:51 node1 kernel: vmbr0: port 2(tap101i1) entered blocking state
Aug 24 15:12:51 node1 kernel: vmbr0: port 2(tap101i1) entered disabled state
Aug 24 15:12:51 node1 kernel: vmbr0: port 2(tap101i1) entered blocking state
Aug 24 15:12:51 node1 kernel: vmbr0: port 2(tap101i1) entered forwarding state
Aug 24 15:12:51 node1 pve-ha-lrm[1881]: <root@pam> end task UPID:node1:0000075A:00000738:6124F052:qmstart:101:root@pam: OK
Aug 24 15:12:51 node1 pve-ha-lrm[1881]: service status vm:101 started
Aug 24 15:12:54 node1 pvedaemon[1796]: <root@pam> successful auth for user 'root@pam'
Aug 24 15:13:00 node1 pve-ha-crm[1801]: service 'vm:100': state changed from 'request_stop' to 'stopped'

 

[whecker]

Wie verhält sich denn PVE bei VMs, die vor dem Reboot aktiv waren, aber kein "Start at Boot" haben? Wird hier auch der letzte Zustand wieder hergestellt und die VM auch neu gestartet?

In diesem Fall läuft alles wie es soll. Die VM wird also NICHT gestartet. Ist oben im ersten Bild am Beispiel VM 110 vor dem Reboot und nach dem Reboot zu sehen.

 

[whecker]

Aug 24 15:12:51 node1 pve-ha-lrm[1881]: <root@pam> end task UPID:node1:0000075A:00000738:6124F052:qmstart:101:root@pam: OK
Aug 24 15:12:51 node1 pve-ha-lrm[1881]: service status vm:101 started
Aug 24 15:12:54 node1 pvedaemon[1796]: <root@pam> successful auth for user 'root@pam'
Aug 24 15:13:00 node1 pve-ha-crm[1801]: service 'vm:100': state changed from 'request_stop' to 'stopped'

Nur nochmal zur Klärung: Mein Request stop ist vor dem Reboot des Systems abgesetzt worden. Nach dem Reboot habe ich nur die screen shots gemacht. Dennoch kennt das System noch den Status vor dem Reboot und deutet den Status möglicherweise falsch.

 

[t.lamprecht]

Hier ist ein Auszug aus dem Syslog nach dem node Boot-Vorgang bei dem einer der VMs nicht gebootet wurde.
Hier scheint mir bei VM 100 was nicht ok zu sein. Ich kann das Syslog aber nicht richtig deuten.

Du hast den HA manager Aktiv, in dem Fall zählt für die VMs unter HA nur dass was du als "HA Request State" konfiguriert hast, "Start at boot" ist für diese VMs irrelevant. Könnte man im Webinterface etwas klarer abbilden fällt mir grad auf.

 

[whecker]

Du hast den HA manager Aktiv, in dem Fall zählt für die VMs unter HA nur dass was du als "HA Request State" konfiguriert hast, "Start at boot" ist für diese VMs irrelevant. Könnte man im Webinterface etwas klarer abbilden fällt mir grad auf.

 

[whecker]

Mir war das mit dem HA nicht klar. Ich habe die VMs jetzt aus dem HA entfernt und siehe da - sobald man es richtig macht - funktioniert's.
Die VMs werden jetzt schön nach den Vorgaben des "Start at Boot" hochgefahren oder auch nicht.
Vielen Dank für den kompetenten Lösungshinweis-