Recent content by EugenMayer

@fiona all our affected instances are Debian12, all are memory restricted and all use/have swap. This fits your case i assume

Beside all the noice i created, i can fairly confident say, downgrading qemu to 10.1.2-7does fix the actual issue. I no longer have any segfaults on any of my proxmox servers, with qcow2 still in use.

@fever_wits we can disagree on this, fine with that and that is a fair POV you have. Please consider, that my issue with this move is rather, that it is done invisibly. This is not Proxmox 9.2, this is just a patch within 9.1. This makes it way harder for people to even understand something...

@PVasileff just wanted to assure, all of my vms that are affected are using qcow - so you might be onto something. For me converting the disks is not an option and this would IMHO just confirm that this is related to QEMU kvm (11) and maybe to the issue i linked above. This all makes more and...

Could it be that we all look for https://lists.nongnu.org/archive/html/qemu-stable/2026-04/msg00145.html ? IMHO this would explain both, how this might be an issue with the IO/disk interface and qemu at the same time. I have downgraded qemu and for now, not seen a segfault. Though, they did...

Thanks for all the informations and work already done above! I'am currently on the way to test the downgrade of pve-qemu-kvm to 10.1.2 to see if that helps. In my book, the kernel of the host is less likely the cause here (this is only a bet). I guess this aligns with the existing experiments...

Are you expected that 'non-host' / x86-64-v2-AES/x86-64-v3 should be less error prone than host? I would have suggested, that this is unexpected, but i follow your advice, if that is the case

@fabian we update our packages daily, within the VMs and on the proxmox server. So we updated to whatever was available to debian12 at this moment, including what is available for PVE. The reason that this is cleary proxmox and not 'vm software' related is, that we run the exact same VM, with...

We have the very same issue, while we rather use debian12 VMs in this regard. Segmentation faults are happening for different processes. What we have tried: latest PVE 7.x or 6.x kernel - happens on both - currently running 6.17.13-9-pve we have PVEs with and without enterprise subscription...

Thanks for the effort and information Stefan! I will try to replicate that in an office our and post the kernel exception here. there are no open kernel updates Running FreeBSD:12 on Opnsense 21.1.5 (latest) so I suppose it is the latest FreeBSD 12 kernel Why would I need nested virtualization...

Updated CPU in the original post (its an AMD) This is the non-bootable configuration due to cpu: host boot: dcn bootdisk: scsi0 cores: 2 ide2: none,media=cdrom memory: 6000 name: gateway net0: virtio=<redacted>,bridge=vmbr30 net1: virtio=<redacted>,bridge=vmbr0 net2...

Due to fixing nested virtualization issues I switch to the 5.11 kernel line using apt-get install pve-kernel-5.11 after that my freebsd/opnsense (21.1.5-amd64) box (FreeBSD 12), which is using cpu:host will no longer boot due to a kernel panic. Are there any hints or known issues on how to fix...

TLTR: When you have an AMD Ryzen CPU and want to use any nested virtualization (nonfancy, just packer builds with Virtualbox) it will freeze about 5-10 seconds after starting the VM. To fix this issue, you need to upgrade your PVE kernel to 5.11. My setup: - Proxmox 6 latest patch version...

i was writing FUD - removed it. In the end, the debian installer created a FQDN entry in hostname 127.0.0.1 with a vagrant domain, while the chef hostname recipe created one with <LANIP> real FQDN, the point is, since the hostname was the same in both cases, but not the FQDN, pve-cluster picks...

Ich versuche auf einem HP Gen8 (Xeon E3-1225) mit VTd aktiviert, natürlich auch mit vi /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on" cat /etc/modules vfio vfio_iommu_type1 vfio_pci vfio_virqfd lspci -nn | grep Eth 03:00.0 Ethernet controller [0200]: Broadcom...