There is a new QEMU 11.0 package available in the
After internally testing QEMU 11.0 for over two weeks and having this version available on the
Version
Note: While some of our production workloads already use this version and run stable, we cannot test every possible hardware and configuration combination, so we recommend testing the upgrade before applying it to mission-critical setups.
To upgrade, make sure you have configured either the Proxmox VE No-Subscription repository or the Proxmox VE Test repository.
Either use the web-interface to refresh and then upgrade using the Node -> Updates panel, or use a console with the following standard
The output of the
Note, as with all QEMU updates: To run with the new QEMU version, a VM must either be completely restarted (shut it down and then start it again, or use the restart command via the CLI or web-interface) or, to avoid downtime, consider live-migrating to a host that has already been upgraded to the new QEMU package version.
While we have been successfully running our production and many test loads on this version for some time now, no software is bug-free, and often such issues are related to the specific setup. So if you encounter regressions that are definitely caused by installing the new QEMU version (and not some other change), please always include the affected VM configuration and some basic HW (e.g. CPU model) and memory details.
We welcome your feedback!
Known issues:
pve-test and pve-no-subscription repositories for Proxmox VE 9.After internally testing QEMU 11.0 for over two weeks and having this version available on the
pve-test repository for over a week, we now (2026-05-13) made our QEMU 11.0 package available in the pve-no-subscription repository.Version
11.0.0-2 of our QEMU package pve-qemu-kvm includes some important stable fixes that have been developed since the original QEMU 11.0 release.Note: While some of our production workloads already use this version and run stable, we cannot test every possible hardware and configuration combination, so we recommend testing the upgrade before applying it to mission-critical setups.
To upgrade, make sure you have configured either the Proxmox VE No-Subscription repository or the Proxmox VE Test repository.
Either use the web-interface to refresh and then upgrade using the Node -> Updates panel, or use a console with the following standard
apt commands:
Bash:
apt update
apt full-upgradeThe output of the
pveversion -v CLI command (or the web-interface's Node Summary -> Packages versions) should then include something like pve-qemu-kvm: 11.0.0-2.Note, as with all QEMU updates: To run with the new QEMU version, a VM must either be completely restarted (shut it down and then start it again, or use the restart command via the CLI or web-interface) or, to avoid downtime, consider live-migrating to a host that has already been upgraded to the new QEMU package version.
While we have been successfully running our production and many test loads on this version for some time now, no software is bug-free, and often such issues are related to the specific setup. So if you encounter regressions that are definitely caused by installing the new QEMU version (and not some other change), please always include the affected VM configuration and some basic HW (e.g. CPU model) and memory details.
We welcome your feedback!
Known issues:
- On a host with a recent Intel CPU, when using kernel 7.x, Windows server 2025 VMs with HVCI or RDS or Hyper-V with VM CPU type
hostor a recent Intel CPU model might fail to boot. This is caused by QEMU 11 automatically exposing thecet-ibtandcet-ssCPU flags, for which an issue in the KVM code in the Linux kernel exists. Potential workarounds are:- using a different, less recent virtual CPU model - one that's close to your physical model, with optionally the
nested-virtflag. Models that do not yet have the flag areSapphireRapids-v4,GraniteRapids-v3,SierraForest-v3, andClearwaterForest(without bumped version) - adding custom arguments with
qm set ID '-cpu host,level=30,-cet-ibt,-cet-ss' - using the 6.17 kernel
- using a different, less recent virtual CPU model - one that's close to your physical model, with optionally the
Last edited:
