VSA frequent spin-lock

[unsichtbarre]

Case #08193302

We are in the process of migrating several VBR Windows instances (on VMware) to the VSA (on Proxmox).
We have 2 nearly identical configurations now running on VSA/Proxmox (13.1.1.18):
1) VSA's are hosted centrally on the same Proxmox infrastructure
2) "local" backups run over IPsec VPN using a Windows VBR Proxy to a NTFS/REFS repo at remote location.
3) Backup Copy moves "local" backup data to immutable repository (SOBR) at central location
4) SOBR offloads data to Veeam Vault.
Both VSA's are configured identically (2X240GB disk, 32GB RAM, 8vCPU), job load on both is small: 15-45 VMs on 1 or 2 backup jobs, 1 backup copy job, one SOBR.

One VSA has spin-locked dozens of times and the other has run fine since migration from Windows/VMware.

The affected VSA hard-freezes: it becomes fully unresponsive (Web UI, network, and console all dead) with no clean shutdown, and can only be recovered by a forced power-off/power-on at the hypervisor. Multiple occurrences confirmed, and the failure has now been reproduced on a second, independent appliance (rebuilt and restored config backup for the affected VSA) at the same kernel code address — establishing it as a deterministic, image-level defect. A live capture during an active freeze shows a single-vCPU livelock / soft-lockup inside the guest (one CPU spinning, the rest halted, no disk I/O); journald goes completely silent with no kernel panic, OOM, or hung-task message.

The hypervisor is ruled out. Host node journal and kernel log for both incident windows show no OOM, no storage/ZFS errors, no kernel faults, and a healthy QEMU process. The VM scope terminated cleanly only on the operator-issued forced stop. From the host side the guest simply stopped answering ACPI. This is a guest-internal hang, not a hypervisor fault.

Any ideas or similar experiences?
-JB