Proxmox: perché un container e una VM non ripartono (e perché non era colpa del backup)

Nel mio homelab Proxmox c’è un problema che si ripete: un container LXC (Jellyfin) e una VM (NethServer) risultano spesso spenti. Avevo un sospetto preciso: succede dopo il backup notturno. Questa è la cronaca di come ho verificato l’ipotesi, perché era sbagliata e che cosa ho trovato davvero.

Il contesto

  • Host Proxmox singolo, 6 container LXC e 1 VM, dischi su local-lvm (LVM-thin).
  • Un NAS in rete che serve due share: una CIFS con i media e una NFS per i backup.
  • Backup con uno script che gira da cron alle 08:00: chiama vzdump per tutti i guest e poi archivia con Borg sul NAS.
  • Nessun UPS.

Prima ipotesi: il backup lascia i guest spenti

L’ipotesi era ragionevole: un job di backup che fallisce a metà può lasciare un lock sul guest o non riavviarlo. Ho controllato tre cose.

1. Lock sui guest. Nessuno.

grep -H '^lock:' /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf

2. Modalità e log di vzdump. I container vengono salvati a caldo, in modalità snapshot, senza mai essere fermati. La VM era già stopped prima che il backup partisse: vzdump l’ha accesa per il dump e rispenta.

INFO: status = stopped
INFO: backup mode: stop

3. Orari. Il backup parte alle 08:00. Come vedremo, i blocchi dell’host non coincidono con quell’orario.

Conclusione: il backup non spegne nulla. Bisognava cercare altrove.

Cosa mi ha messo sulla strada giusta

Lo storico dei task Proxmox

Lo storico dei task è in /var/log/pve/tasks/index. È un file binario, quindi serve grep -a, altrimenti risponde solo “binary file matches”.

grep -a -E "vzstart:101|startall" /var/log/pve/tasks/index | tail -30

Il risultato: in ogni startall (l’avvio automatico dei guest al boot dell’host) il container 101 fallisce con startup for container '101' failed, mentre gli altri partono. Poi lo riavvio a mano e parte sempre.

I riavvii dell’host

last -x reboot shutdown | head

Ogni riga reboot finiva con crash e non c’era nessun record di shutdown. Quindi l’host non si spegneva in modo pulito: veniva interrotto bruscamente. Ho controllato anche il journal:

for b in $(seq -11 -1); do
  journalctl -b $b --no-pager | grep -q "Journal stopped" \
    && echo "boot $b: pulito" || echo "boot $b: INTERROTTO"
done

Su undici boot, uno solo si era chiuso correttamente. Prima delle interruzioni, nei log, nessun errore: niente panic, MCE, errori di I/O, thermal o watchdog. E l’orario dell’ultima riga di ogni boot non è mai attorno alle 08:00.

Il disco NVMe

smartctl -a /dev/nvme0n1 | grep -Ei "unsafe|power cycles|critical|media|percentage|temperature"

Power Cycles:                       470
Unsafe Shutdowns:                   46
Media and Data Integrity Errors:    0
Percentage Used:                    11%

Il disco è sano, ma i 46 spegnimenti bruschi confermano che i tagli di corrente improvvisi sono ricorrenti. Il contatore è cumulativo e non permette di datare gli eventi, ma il quadro è coerente.

Perché il container 101 non parte

Il task log dice solo Failed to run lxc.hook.pre-start. Il motivo vero è nel journal del boot, filtrando attorno al fallimento:

journalctl -b 0 --since "2026-11-01 22:40:50" --until "2026-11-01 22:42:30" --no-pager \
  | grep -Ei "101|nas|cifs|automount|mnt-|network-online"

mnt-nas-media.automount: Got automount request for /mnt/nas/media, triggered by (lxc-pve-prestart)
CIFS: Attempting to mount //192.168.0.2/Multimedia
CIFS: VFS: Error connecting to socket. Aborting operation.
CIFS: VFS: cifs_mount failed w/return code = -111
Failed to mount mnt-nas-media.mount - /mnt/nas/media.
pve-guests: startup for container '101' failed

Il container ha un bind mount verso /mnt/nas/media, montata via autofs dalla share CIFS del NAS. Al boot dell’host il NAS risponde in rete ma il servizio SMB non è ancora attivo: il mount fallisce con -111 (connessione rifiutata), il container non parte e Proxmox non ritenta.

Perché il NAS è più lento dell’host? Perché in un blackout si spengono entrambi e quando torna la corrente ripartono insieme. Un NAS ha un boot molto più lungo di un mini-PC e ci mette qualche minuto in più ad avere i servizi di rete attivi.

Perché la VM non parte

La VM non aveva nessun onboot: 1. Controllo:

grep -H onboot /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf

Solo i container comparivano nell’output. Senza onboot la VM resta spenta dopo qualsiasi riavvio dell’host. Una riga di configurazione:

qm set 107 --onboot 1

Le contromisure

1. Far aspettare i guest finché il NAS è pronto

Uno script controlla le porte SMB (445) e NFS (2049) del NAS e blocca l’avvio dei guest per al massimo cinque minuti. Se il NAS è già su, esce subito.

cat > /usr/local/bin/wait-nas.sh <<'EOF'
#!/bin/bash
nas=192.168.0.2
for i in $(seq 1 60); do
  if timeout 2 bash -c "</dev/tcp/$nas/445" 2>/dev/null \
     && timeout 2 bash -c "</dev/tcp/$nas/2049" 2>/dev/null; then
    exit 0
  fi
  sleep 5
done
exit 0
EOF
chmod +x /usr/local/bin/wait-nas.sh

Lo aggancio all’avvio dei guest con un drop-in di systemd:

mkdir -p /etc/systemd/system/pve-guests.service.d
cat > /etc/systemd/system/pve-guests.service.d/wait-nas.conf <<'EOF'
[Service]
ExecStartPre=/usr/local/bin/wait-nas.sh
EOF
systemctl daemon-reload
systemctl cat pve-guests | grep -i timeout   # nessun timeout troppo corto?
time /usr/local/bin/wait-nas.sh              # col NAS acceso deve tornare subito

Il prezzo: se il NAS resta spento a lungo, anche i guest che non ne hanno bisogno (DNS, VPN) partono con fino a cinque minuti di ritardo. Nel mio caso è accettabile.

2. Riattivare l’avvio automatico della VM

qm set 107 --onboot 1

3. Il BIOS

Nel BIOS dell’host conviene che l’opzione di ripartenza dopo un’interruzione di corrente (Restore on AC power loss) sia su Power On, così l’host riparte da solo senza intervento.

4. L’UPS, la soluzione vera

I due script sono un cerotto. La causa è l’alimentazione, e un blackout senza UPS non è solo un fastidio: ogni spegnimento brusco mette a rischio il file system e il thin pool LVM. Il piano:

  • UPS line-interactive da 600–900 VA con porta USB, compatibile con NUT.
  • Dimensionamento: host, NAS, router e switch sono circa 100 W, quindi 10–20 minuti di autonomia.
  • L’UPS si collega in USB al NAS, che fa da server UPS di rete.
  • L’host Proxmox usa nut-client in modalità netclient, così al blackout spegne i guest e si spegne per primo, e il NAS per ultimo.

Da verificare ancora

Non sono ancora sicuro al 100% che la causa dei riavvii sia la corrente: lo stesso quadro (nessun errore nei log, spegnimenti bruschi) lo darebbero anche un reset hardware o un blocco totale della macchina. La verifica è semplice: confrontare gli orari di riavvio dell’host con il registro eventi del NAS. Se il NAS risulta riavviato negli stessi momenti, è un blackout; se non si è mosso, il problema è solo nell’host e il passo successivo è registrare le temperature.

Altri problemi emersi lungo la strada

  • Mount NFS soft per i backup. Per scritture di backup è meglio hard: un NAS lento con soft può restituire errori di I/O a metà scrittura dell’archivio.
  • nfsidmap che si lamenta ogni 10 minuti (root@localdomain non mappa nel dominio locale). Si risolve allineando il dominio idmap tra host e NAS, oppure montando con vers=3.
  • apparmor DENIED di rsyslog nel container. Rumore nei log ogni 5 minuti, non collegato agli avvii.

Cosa ho imparato

  1. Un’ipotesi che sembra ovvia va verificata sui log: il backup era innocente.
  2. grep -a sul task index di Proxmox. Lo storico dei task è la fonte più utile e si legge solo con quel flag.
  3. last -x reboot shutdown e journalctl --list-boots dicono se l’host si spegne in modo pulito. Se ogni boot finisce con crash, il problema è sotto Proxmox.
  4. Il contatore Unsafe Shutdowns dell’NVMe è un indicatore gratuito dei tagli di corrente.
  5. Chi dipende da un NAS al boot ha bisogno di un ordine di avvio. Proxmox non aspetta le share di rete da solo.
  6. Un UPS non è un lusso nemmeno in un homelab.
ProxmoxHomelabLXCBorgNASUPSTroubleshooting