VM's won't start on boot

[camjesus]

Hello @all,
sometimes (often) some of my vms won't start on boot. Manual start works flawlessly. Can't really reproduce it, so a little help as to how to troubleshoot would be nice.
Looked in the log files, but found nothing relevant. Guess I didn't look hard enough. Anyway:
1) My setup: Proxmox (recently upgraded to) 9.2.4 on an HP dl 380 G8 with 32 GB and 2 E5-2667 v3. 3 VM's (1 windows10 + 2 Linux Debian Trixie). All pretty standard really, no overcommitment, but I do use balooning and NUMA.
2) Errors:

kvm: warning: Spice: ../server/reds.cpp:2551:reds_init_socket: getaddrinfo(127.0.0.1,61002): Address family for hostname not supported
kvm: warning: Spice: ../server/reds.cpp:3441:do_spice_init: Failed to open SPICE sockets
kvm: failed to initialize spice server
TASK ERROR: start failed: QEMU exited with code 1

I don't know where port 61002 comes from. I don't see it listed on the docs but again, maybe I didn't look hard enough. Also, I dont use spice.

3) What I tried:
a) start/shutdown order (on/of with different ordering and delays).
b) Enable/disable "Spice enhancements". Was off by default, as Display=Virtio-GPU is on all of the VM's.
c) Reddit. Yeap, reddit. There's an old post mentioning something similar. Didn't tried it tough.

So, any ideas?


Best regards!

 

[g.fiore]

Root cause is that when PVE tries to autostart VMs early in boot, the network stack isn't fully up yet, and QEMU fails to bind the SPICE socket on 127.0.0.1. getaddrinfo() returns "address family not supported" because loopback isn't ready. Later, when you start manually, networking is up and it works.

You say you don't use SPICE, but Display: Virtio-GPU on all VMs is worth checking. Some Display/audio combinations in PVE still open a SPICE socket under the hood. Post the output of qm config <VMID> for one of the failing VMs — look for a vga: or args: line referencing spice, or an audio device with spice backend.

Fixes to try, in order:

1) Switch Display from Virtio-GPU to Default (std) on one test VM. If it starts on boot after that, SPICE is the trigger. You can probably drop Virtio-GPU on all of them unless you have a specific reason for it — headless VMs don't need it.

2) If you need to keep the current display config, add a startup delay: qm set <VMID> --startup order=1,up=60 to wait 60s after host boot before starting the VM. Boring but reliable.

3) Check /etc/hosts on the host — 127.0.0.1 localhost must be there. If it's missing or the file is malformed, getaddrinfo fails permanently, not just at boot.

 

[camjesus]

Root cause is that when PVE tries to autostart VMs early in boot, the network stack isn't fully up yet, and QEMU fails to bind the SPICE socket on 127.0.0.1. getaddrinfo() returns "address family not supported" because loopback isn't ready. Later, when you start manually, networking is up and it works.

You say you don't use SPICE, but Display: Virtio-GPU on all VMs is worth checking. Some Display/audio combinations in PVE still open a SPICE socket under the hood. Post the output of qm config <VMID> for one of the failing VMs — look for a vga: or args: line referencing spice, or an audio device with spice backend.

Fixes to try, in order:

1) Switch Display from Virtio-GPU to Default (std) on one test VM. If it starts on boot after that, SPICE is the trigger. You can probably drop Virtio-GPU on all of them unless you have a specific reason for it — headless VMs don't need it.

2) If you need to keep the current display config, add a startup delay: qm set <VMID> --startup order=1,up=60 to wait 60s after host boot before starting the VM. Boring but reliable.

3) Check /etc/hosts on the host — 127.0.0.1 localhost must be there. If it's missing or the file is malformed, getaddrinfo fails permanently, not just at boot.

Hey g.fiore,thanks for your help!
I RDP/ssh to the machines so I rarely use the console. Therefore, I can change display to std on all of them.
I'm actually more interested on the boot delay or, at least, boot order, for the VM's.
A such, I'll implement your 1 and 2 and see if it solves. As for 3, it was already there.

Anyway, here goes qm config 101 just in case.

agent: 1
balloon: 4096
boot: order=scsi0
cores: 12
cpu: host,flags=+pcid;+pdpe1gb;+aes
description: scsi2%3A /dev/disk/by-id/wwn-0x50014ee207a24309,backup=0,cache=writeback,iothread=1,size=1953514584K%0Ascsi1%3A /dev/disk/by-id/scsi-3600508b1001cb11608a0e5bc7b3ba4c8,backup=0,cache=writeback,iothread=1,size=3906985816K%0Ascsi1%3A /dev/disk/by-id/scsi-3600508b1001cb11608a0e5bc7b3ba4c8,backup=0,cache=writeback,iothread=1,size=3906985816K
memory: 6144
meta: creation-qemu=6.2.0,ctime=1650055405
name: EHFS2
net0: virtio=B2:AC:90:2C:E2:47,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
protection: 1
scsi0: VMPool:vm-101-disk-0,discard=on,iothread=1,size=32G,ssd=1
scsi2: /dev/disk/by-id/scsi-3600508b1001cb11608a0e5bc7b3ba4c8,backup=0,size=3906985816K
scsihw: virtio-scsi-single
smbios1: uuid=e6f54e96-e76c-493a-b104-024d92846bd2
sockets: 1
startup: order=2,up=30
vga: virtio
vmgenid: 095be52d-f086-4be8-8543-825ea7f68f80

 

[Neobin]

There also exists the "First Guest Boot Delay":
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#first_guest_boot_delay

 

[g.fiore]

Good, that confirms the theory. vga: virtio in the config generates a SPICE socket under the hood even without an explicit spice line, which is why you're hitting it. Steps 1 and 2 both address this in different ways.
One thing worth noting: you already have startup order=2, up=30. On an HP DL380 G8, 30 seconds is often not enough after boot — link negotiation and PVE service init can easily take 45-90s before the bridge is fully usable.
For your case, since your three VMs don't seem to have strict inter-dependencies, this is probably the right approach — set startall-onboot-delay to 60 or 90 node-wide and drop the per-VM up=30 tweak entirely.
Still curious to see if switching to vga: std alone fixes it though — that would be the cleanest fix because it removes the SPICE socket dependency at boot rather than working around it.