Proxmox 9.x: HAOS hangs at "Booting 'Slot X'" with CPU model kvm64 — fixed by x86-64-v2-AES

Describe the issue you are experiencing

Follow-up to #4656 (closed by its author and locked, so I could not comment there).

Same symptom, and I traced it on my hardware to the QEMU CPU model. Switching the VM from cpu: kvm64 to cpu: x86-64-v2-AES fixed it completely, with no change to the machine type.

Symptoms

HAOS 18.2 had been installed into slot B and was waiting for a reboot. The first boot attempt into that slot happened when I rebooted the Proxmox node, and it never completed:

• VGA console stops at Booting 'Slot B (OK=1 TRY=1)' and never moves.
• Exactly one vCPU pinned at 100% (25% of 4 cores), indefinitely.
• Only ~212 MiB of the 6 GiB of guest RAM ever touched, so it dies very early, before userspace.
• serial0 console: completely silent. Nothing at all, not even a kernel banner.
• QEMU guest agent never answers (qga command 'guest-ping' failed - got timeout), which is a consequence rather than the cause.
• The Proxmox host journal shows no QEMU/KVM error at all; from the hypervisor's point of view the VM is running normally.

Recovery each time: force stop, start, interrupt GRUB with the arrow keys, select Slot A. HAOS then marks slot B bad:

boot: A
boot_slots:
  A:  booted    good  "18.1"
  B:  inactive  bad   "18.2"

The fix

With the VM shut down:

qm set <vmid> -cpu x86-64-v2-AES

Nothing else changed — machine type stayed q35, BIOS stayed OVMF, same disks, same EFI disk.

Proxmox expands that CPU model to:

-cpu qemu64,+aes,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+pni,+popcnt,+sse4.1,+sse4.2,+ssse3

Note the enforce flag: QEMU refuses to start the VM if any of those features is unavailable on the host, so a successful start proves the guest really receives them. kvm64 exposes none of aes, sse4.1, sse4.2, ssse3, popcnt.

Result

After the CPU change, 18.1 -> 18.3 installed and booted into slot B with no hang:

boot: B
boot_slots:
  A:  inactive  good  "18.1"
  B:  booted    good  "18.3"
version: "18.3"

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

18.2 (failing), 18.3 after the fix

Did the problem occur after upgrading the Operating System?

Yes

Hardware details

Hypervisor: Proxmox VE — 9.2.11 when the problem appeared, 9.2.18 now.

• Kernel: 7.0.14-14-pve
• pve-qemu-kvm: 11.0.3-3
• pve-edk2-firmware: 4.2025.05-3
• Host CPU: Intel Core i5-9500 (Coffee Lake) — AES-NI and SSE4.2 both present on the host
• VM storage: ZFS (local-zfs), SSD

VM configuration (originally created by the community-scripts HAOS helper), as it was when it failed:

bios: ovmf
machine: q35            # running-machine: pc-q35-11.0+pve0, running-qemu: 11.0.3
cpu: kvm64              # <-- the culprit
cores: 4
sockets: 1
memory: 6144
ostype: l26
scsihw: virtio-scsi-pci
scsi0: local-zfs:vm-107-disk-0,discard=on,size=32G,ssd=1
efidisk0: local-zfs:vm-107-disk-1,efitype=4m,size=1M
net0: virtio,bridge=vmbr0
serial0: socket
agent: enabled=1

No PCI or USB passthrough, no USB devices attached. Secure Boot not in use.

Steps to reproduce the issue

1. On a Proxmox VE 9.2.x host, run HAOS in a VM configured with bios: ovmf, machine: q35 and cpu: kvm64 (the Proxmox default when no CPU type is explicitly set). HAOS 18.1 runs fine this way.
2. Install an OS update (18.2 in my case) so that it is written to the inactive slot.
3. Reboot the VM (in my case this happened implicitly when I rebooted the Proxmox node).
4. The VM hangs at Booting 'Slot B (OK=1 TRY=1)', with one vCPU pinned at 100%, ~212 MiB of RAM touched and nothing at all on the serial console.
5. Shut the VM down and run qm set <vmid> -cpu x86-64-v2-AES, changing nothing else.
6. Repeat the OS update and reboot — it now boots normally into the updated slot.

I ran steps 5 and 6 on a full clone of the VM first (booted alone, with a fresh MAC and HA Core stopped), then applied the same change to the production VM. Both behaved identically: hang before the CPU change, clean boot after.

Anything in the Supervisor logs that might be useful for us?

Not available — the VM never boots far enough for the Supervisor to start, so no Supervisor log is produced at all.

Anything in the Host logs that might be useful for us?

Not available from the guest — HAOS never boots, and the serial console (serial0) stays completely silent, so there is no kernel output to capture.

On the Proxmox host side, the journal contains no QEMU/KVM error for this VM. The only recurring entries are the guest agent timing out, which is a consequence of the hang:


pvedaemon[1528]: VM 107 qga command failed - VM 107 qga command 'guest-ping' failed - got timeout


A `qm reboot` also fails for the same reason:


QEMU Guest Agent is not running - VM 107 qga command 'guest-ping' failed - got timeout
TASK ERROR: VM quit/powerdown failed - got timeout

System information

ha os info after recovering on slot A, with cpu: kvm64 still in place:

board: ova
boot: A
boot_slots:
  A:
    state: booted
    status: good
    version: "18.1"
  B:
    state: inactive
    status: bad
    version: "18.2"
data_disk: QEMU-QEMU-HARDDISK-drive-scsi0
version: "18.1"

ha os info after switching to cpu: x86-64-v2-AES and updating to 18.3:

board: ova
boot: B
boot_slots:
  A:
    state: inactive
    status: good
    version: "18.1"
  B:
    state: booted
    status: good
    version: "18.3"
version: "18.3"

Guest kernel now reported as 6.18.52-haos. Home Assistant Core 2026.9.3.

Additional information

Why I think this also explains #4656

Four data points line up if the relevant factor is AES-NI actually reaching the guest:

The J1900 is Bay Trail: it has SSE4.1/SSE4.2 but no AES-NI. So cpu: host on that board does not expose AES to the guest — which would explain why "I'm already using host" did not help the reporter, while the working configuration posted by @agners in that thread is precisely cpu: x86-64-v2-AES.

If this holds, the trigger would be a missing CPU feature rather than the machine type, which would also explain why the problem reproduces on some hosts and not others. Cheap check on an affected host:

grep -c ' aes ' /proc/cpuinfo      # 0 means no AES-NI
grep -c ' sse4_2 ' /proc/cpuinfo

I would be curious whether the users for whom switching to i440fx fixed it also run a CPU without AES-NI — if so, that workaround may be coincidental, or a second, independent issue.

Caveats, so nobody over-reads this

• The hang is completely silent. I never captured a panic or any early kernel output, so I cannot point at the failing instruction. Someone able to add earlycon to the kernel command line would settle it.
• I went from 18.1 straight to 18.3 after the CPU change; I did not re-test 18.2. So strictly speaking I have shown "18.3 boots with x86-64-v2-AES where 18.2 did not boot with kvm64", not a proven causal link to the CPU model alone.
• Single host, single CPU family. Independent confirmation would be valuable.

I still have the clone VM available as a sandbox and am happy to run further tests, including a build with extra boot-time debugging.