Massenstart von VMs und Container

TErxleben · Sep 2, 2025

taucht in meiner Taskliste unregelmäßig auf. Gerne 10 mal in 4h. Gestartet wird aber nichts. Wo kann die Meldung herkommen? Auf dem 9.0.6-Host sind zwar 8 VMs/Container installiert aber alle sind standardmäßig ausgeschaltet.

dakralex · Sep 2, 2025

Hi!

Könntest du einen Auszug aus den Tasklogs hier posten und wie einer der VM/Container Configs aussieht? Wird in dem Cluster/auf der Node der HA Manager betrieben?

TErxleben · Sep 2, 2025

Ist ein Singlehost.

Code:

root@pve:~# cat /etc/pve/qemu-server/1
103.conf  107.conf  108.conf  109.conf  111.conf  112.conf 
root@pve:~# cat /etc/pve/qemu-server/109.conf
agent: 1
boot: order=virtio0
cores: 4
memory: 2048
meta: creation-qemu=7.0.0,ctime=1664274738
name: seafile
net0: virtio=DA:BE:26:4B:96:AE,bridge=vmbr0,firewall=1
numa: 0
onboot: 0
ostype: l26
scsihw: virtio-scsi-pci
smbios1: uuid=ddba3b22-05ba-42b2-a39e-1b05b1b46834
sockets: 1
startup: order=5
virtio0: local-lvm:vm-109-disk-0,size=32G
vmgenid: a268a199-bedd-401e-a591-13a46b35a83b

dakralex · Sep 2, 2025

Auf welcher Version befindet sich die Node und die packages darauf (pveversion -v)? Gibt es Auffälligkeiten im syslog (e.g. journalctl -xe)? Wie ist der Status von systemctl status pve-guests.service?

Der "Massenstart von VMs und Container" ist normalerweise nur über pvenode startall oder POST /api2/json/nodes/{node}/startall initierbar und nur der service pve-guests.service versucht beim Start der Node einmal alle Gäste zu starten, wo onboot=1 gesetzt ist.

dakralex · Sep 2, 2025

Hilfreich wäre auch noch einen dieser Tasklogs (per Doppelklick auf den Task) zu sehen.

TErxleben · Sep 2, 2025

Kein Node startet beim Boot. journalctl zeigt keine Auffälligkeiten.

Code:

root@pve:~# pveversion -v
proxmox-ve: 9.0.0 (running kernel: 6.14.11-1-pve)
pve-manager: 9.0.6 (running version: 9.0.6/49c767b70aeb6648)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.14.11-1-pve-signed: 6.14.11-1
proxmox-kernel-6.14: 6.14.11-1
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8: 6.8.12-13
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
ceph-fuse: 19.2.3-pve1
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx10
intel-microcode: 3.20250512.1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.3
libpve-apiclient-perl: 3.4.0
libpve-cluster-api-perl: 9.0.6
libpve-cluster-perl: 9.0.6
libpve-common-perl: 9.0.9
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.4
libpve-network-perl: 1.1.6
libpve-rs-perl: 0.10.10
libpve-storage-perl: 9.0.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.4-2
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.14-1
proxmox-backup-file-restore: 4.0.14-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.1.2
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.1
proxmox-widget-toolkit: 5.0.5
pve-cluster: 9.0.6
pve-container: 6.0.9
pve-docs: 9.0.8
pve-edk2-firmware: 4.2025.02-4
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.3
pve-firmware: 3.16-4
pve-ha-manager: 5.0.4
pve-i18n: 3.5.2
pve-qemu-kvm: 10.0.2-4
pve-xtermjs: 5.5.0-2
qemu-server: 9.0.19
smartmontools: 7.4-pve1
spiceterm: 3.4.0
swtpm: 0.8.0+pve2
vncterm: 1.9.0
zfsutils-linux: 2.3.4-pve1

Code:

root@pve:~# systemctl status pve-guests.service
● pve-guests.service - PVE guests
     Loaded: loaded (/usr/lib/systemd/system/pve-guests.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2025-09-02 08:14:30 CEST; 7h ago
 Invocation: 9d94e2d02e6a434fbf375a525b67c3b4
   Main PID: 1132 (code=exited, status=0/SUCCESS)
   Mem peak: 141.9M
        CPU: 1.238s

Sep 02 08:14:28 pve systemd[1]: Starting pve-guests.service - PVE guests...
Sep 02 08:14:30 pve pve-guests[1132]: <root@pam> starting task UPID:pve:00000470:0000051A:68B68B46:startall::root@pam:
Sep 02 08:14:30 pve pve-guests[1132]: <root@pam> end task UPID:pve:00000470:0000051A:68B68B46:startall::root@pam: OK
Sep 02 08:14:30 pve systemd[1]: Finished pve-guests.service - PVE guests.

dakralex · Sep 2, 2025

Könnte es sein, dass Skripte die oben genannten CLI Kommandos/API Endpunkte in scheinbar unregelmäßigen Intervallen ausführen? z.B. Hook scripts, externe Automatisierungstools, etc.

Scheinen in der Task Ausgabe bestimmte VMs/Container auf oder andere Information? Das könnte auch genauer hindeuten warum/von wem diese Kommandos/API Endpunkte augerufen werden.

TErxleben · Sep 2, 2025

Die Ausgabe der Tasks zeigen nur TASK OK

Es gibt nur zwei Scripte, die allerdings auf diversen anderen Hosts laufen, auf den es nicht die seltsamen Taskausgaben gibt:

Code:

root@pve:~# cat failover.sh
#!/bin/bash

# Failover für Proxmox-hosts.
# Script am besten als systemd-Service auf allen hosts integrieren, die ein Failover durchfüren sollen.
# Bei Hosts, die als Backup eines Failoverhosts dienen sollen, Sollte man die SLEEPTIME passend erhöhen.
# Vorraussetzung ist ein konfigurierter Postfix, um Benachrichtgungen zu versenden
# mutt als mailclient
# nmap um fehlende Dienste zu identifizieren
# sshpass falls man ohne public key authentication arbeiten möchte.
# Letzteres ist in lokalen Netzen m.E. durchaus vertretbar.

MAILTO="edv@backlog.de"
SLEEPTIME=30            # wir prüfen hier alle 30s solange kein DELAY-Wert die Spanne verlängert.
DELAY200=360            # wir warten VM-individuell sicherheitshalber x Sekunden bis die Master-VM wieder am Start sind.
DELAY400=120            # Die Werte sind wichtig, damit wir uns nicht selbst überholen.
DELAY107=30             # Die Werte sind wichtig, damit wir uns nicht selbst überholen.
                        # Lieber hoch einsteigen und ggfs. reduzieren.
while true; do
  sleep $SLEEPTIME
  RUNNING=`nmap -p 67 -sU pihole | grep open | wc -l`
  RUNNING1=`nmap -p 8080 gua | grep open | wc -l`
  RUNNING2=`nmap -p 8123 homeassistant | grep open | wc -l`
  MAYBESTOP400=`pct status 400 | grep running | wc -l`
  MAYBESTOP200=`pct status 200 | grep running | wc -l`
  MAYBESTOP107=`qm status 107 | grep running | wc -l`
  if [ $RUNNING == 0 ]; then
    echo "Dienst pihole ist im Netz nicht erreichbar."
    pct start 400
    echo "FAILOVER TES: pihole LXC400 wurde auf PVE gestartet. Bitte kontrollieren und ggf. manuell stoppen, sobald der Master wieder betriebsbereit ist." | mutt -s "FAILOVER TES Pihole TES von PVE auf PVE1" -- $MAILTO
  fi
  if [ $RUNNING1 == 0 ]; then
    echo "Dienst guacamole ist im Netz nicht erreichbar."
    pct start 200
    echo "FAILOVER TES: Guacamole LXC200 wurde auf PVE gestartet. Bitte kontrollieren und ggf. manuell stoppen, sobald der Master wieder betriebsbereit ist." | mutt -s "FAILOVER TES Guacamole TES von PVE auf PVE1" -- $MAILTO
  fi
  if [ $RUNNING2 == 0 ]; then
    echo "Dienst homeassistant ist im Netz nicht erreichbar."
    qm start 107
    echo "FAILOVER TES: Homeassistant VM107 wurde auf PVE gestartet. Bitte kontrollieren und ggf. manuell stoppen, sobald der Master wieder betriebsbereit ist." | mutt -s "FAILOVER TES Homeassistant TES von PVE auf PVE1" -- $MAILTO
  fi
  if [ $MAYBESTOP400 == 1 ]; then
    echo "Failover LXC400 (pihole) aktiv."
    # Wir prüfen ob der Master wieder läuft
    SHUTDOWN400=`sshpass -p 'lanzelot' ssh root@pve1 pct list | grep 400 | grep running | wc -l`
    if [ $SHUTDOWN400 == 1 ]; then
      echo "Master pihole wieder aktiv Failover wird deaktiviert."
      pct shutdown 400
      echo "FAILOVER TES beendet: Master pihole wieder aktiv." | mutt -s "FAILOVER TES beendet. pihole läuft wieder auf PVE1" -- $MAILTO
      sleep $DELAY400
    fi
  fi
  if [ $MAYBESTOP200 == 1 ]; then
    echo "Failover LXC200 (guacamole) aktiv."
    # Wir prüfen ob der Master wieder läuft
    SHUTDOWN200=`sshpass -p 'lanzelot' ssh root@pve1 pct list | grep 200 | grep running | wc -l`
    if [ $SHUTDOWN200 == 1 ]; then
      echo "Master guacamole wieder aktiv Failover wird deaktiviert."
      pct shutdown 200
      echo "FAILOVER TES beendet: Master guacamole wieder aktiv." | mutt -s "FAILOVER TES beendet. guacamole läuft wieder auf PVE1" -- $MAILTO
      sleep $DELAY200
    fi
  fi
  if [ $MAYBESTOP107 == 1 ]; then
    echo "Failover VM107 (homeassistant) aktiv."
    # Wir prüfen ob der Master wieder läuft
    SHUTDOWN107=`sshpass -p 'lanzelot' ssh root@pve1 qm list | grep 107 | grep running | wc -l`
    if [ $SHUTDOWN107 == 1 ]; then
      echo "Master homeassitant wieder aktiv Failover wird deaktiviert."
      qm shutdown 107
      echo "FAILOVER TES beendet: Master homeassistant wieder aktiv." | mutt -s "FAILOVER TES beendet. homeassistant läuft wieder auf PVE1" -- $MAILTO
      sleep $DELAY107
    fi
  fi
done

und

Code:

root@pve:~# cat refreshcoldstandby.s
cat: refreshcoldstandby.s: Datei oder Verzeichnis nicht gefunden
root@pve:~# cat refreshcoldstandby.sh
#!/usr/bin/env bash
set -euo pipefail


NODE="$(hostname)"                 # Lokaler PVE-Node, auf dem restored wird
PBS_STORE="pbs"                    # Name des eingebundenen PBS-Storage in PVE
TARGET_STORE="local-lvm"           # Ziel-Storage für Restore (anpassen)
VMIDS=("200" "400" "107" "109")            # IDs der Cold-Standby-Instanzen (VM & LXC gemischt möglich)
DRYRUN="${DRYRUN:-0}"              # DRYRUN=1 -> nur anzeigen, nichts ausführen
KEEP_CONFIG_BACKUP=0               # Legt vor dem Destroy ein qm/pct config-Backup an


need() { command -v "$1" >/dev/null || { echo "Fehlt: $1"; exit 1; }; }
need pvesh; need jq

log(){ echo "[$(date +'%F %T')] $*"; }

get_latest_volid() {
  local vmid="$1"
  # holt neueste Backup-VolID (volid wie: pbs:backup/vm/101/2025-08-15T19:01:23Z)
  pvesh get "/nodes/${NODE}/storage/${PBS_STORE}/content" \
    -content backup -vmid "${vmid}" --output-format json \
  | jq -r 'max_by(.ctime) | .volid'
}

detect_type_from_volid() {
  local volid="$1"
  if [[ "$volid" == *"/vm/"* ]]; then echo "qemu"; else echo "lxc"; fi
#  if [[ "$volid" == *"vzdump-qemu-"* ]]; then echo "qemu"; else echo "lxc"; fi
}

stop_and_destroy() {
  local type="$1" vmid="$2"
  if [[ "$type" == "qemu" ]]; then
    qm stop "$vmid" || true
    [[ "$KEEP_CONFIG_BACKUP" -eq 1 ]] && qm config "$vmid" >"/root/qm-${vmid}-$(date +%F-%H%M).conf" || true
    qm destroy "$vmid" --purge 1 --destroy-unreferenced-disks 1
  else
    pct stop "$vmid" || true
    [[ "$KEEP_CONFIG_BACKUP" -eq 1 ]] && pct config "$vmid" >"/root/pct-${vmid}-$(date +%F-%H%M).conf" || true
    pct destroy "$vmid" --purge 1
  fi
}

do_restore() {
  local type="$1" vmid="$2" volid="$3"
  if [[ "$type" == "qemu" ]]; then
    # Hinweis: --unique 0 -> behält MAC/SMBIOS wie im Backup (gut für echtes Failover)
    qmrestore "$volid" "$vmid" --storage "$TARGET_STORE" --force 1 --unique 0
    qm set "$vmid" --onboot 0 || true   # sicherheitshalber nicht automatisch starten
  else
    pct restore "$vmid" "$volid" --storage "$TARGET_STORE" --force 1
    pct set "$vmid" -onboot 0 || true
  fi
}

for VMID in "${VMIDS[@]}"; do
  log "== Bearbeite VMID ${VMID} =="
  VOLID="$(get_latest_volid "$VMID" || true)"
  if [[ -z "$VOLID" || "$VOLID" == "null" ]]; then
    log "!! Keine Backups im PBS für VMID ${VMID} gefunden – skip"
    continue
  fi

  TYPE="$(detect_type_from_volid "$VOLID")"

  log "Neueste Sicherung: ${VOLID} (Typ: ${TYPE})"

  if [[ "$DRYRUN" -eq 1 ]]; then
    log "[DRYRUN] Würde ${TYPE} ${VMID} zerstören und aus ${VOLID} nach ${TARGET_STORE} restoren."
    continue
  fi

  stop_and_destroy "$TYPE" "$VMID"
  do_restore "$TYPE" "$VMID" "$VOLID"
  log "✔ Restore fertig: ${TYPE} ${VMID} aus ${VOLID} → ${TARGET_STORE} (gestoppt belassen)"
done

log "Alle Jobs erledigt."

dakralex · Sep 2, 2025

Es wird jedoch ein Skript pvenode startall ausführen. Haben Gäste z.B. hookscripts aktiv, die das ausführen? Oder ein systemd unit?

TErxleben · Sep 2, 2025

Keine Hookscripts. Lediglich die vorhin geposteten Scripte mittels systemd. failover.sh läuft in einer Endlosschleife und refreshcoldstandby.sh zeitgesteuert um 15:30

TErxleben · Sep 9, 2025

Ein beherztes
journalctl --list-boots
zeigte dann tatsächlich 150 Neustarts in drei Tagen. Das erklärt natürlich die Einträge im Tasklog.
Es handelt sich um einen HP Elitedesk G800 G4 im Headless-Betrieb. Die Lösung gegen die willenlosen Reboots habe ich hier gefunden:

https://forum.proxmox.com/threads/p...ues-with-hardware-transcoding-in-plex.132187/

Ich bin nach Beitrag #60 vorgegangen und nun scheint Ruhe im Karton zu sein.

Search

Search

Massenstart von VMs und Container

TErxleben

Renowned Member

dakralex

Proxmox Staff Member

TErxleben

Renowned Member

dakralex

Proxmox Staff Member

dakralex

Proxmox Staff Member

TErxleben

Renowned Member

dakralex

Proxmox Staff Member

TErxleben

Renowned Member

dakralex

Proxmox Staff Member

TErxleben

Renowned Member

TErxleben

Renowned Member

We value your privacy