QEMU 11.0 Released: 32-Bit Hosts Dropped, VM Migration Improved, Breaking Changes to Know

Mohamed Magdy

Mohamed Magdy

— 6 min read
Share
QEMU 11.0 Released: 32-Bit Hosts Dropped, VM Migration Improved, Breaking Changes to Know

QEMU 11.0 arrived after a four-release candidate cycle with significant architecture drops, improved VM migration, and expanded CPU/architecture support. The headline: 32-bit host support is gone, and several deprecated machine types have been removed.

If you're running QEMU on legacy 32-bit hardware or managing VMs with old machine types, this release requires migration planning.

Breaking changes: what you need to know before upgrading

32-bit host support removed

QEMU 11.0 no longer supports running the QEMU hypervisor on 32-bit systems (i386, i686). Only 64-bit host systems (x86-64, ARM64, RISC-V64, etc.) are supported.

Who is affected: Very few people. 32-bit host systems are rare in 2026. If you're running:

  • A 32-bit Ubuntu/Debian system hosting VMs
  • QEMU on old ARM boards (Raspberry Pi, Cortex-A9, etc.) without 64-bit support
  • Legacy embedded systems

Then you need to stay on QEMU 10.2.x or use a 64-bit OS on the host.

Path forward: Upgrade the host OS to 64-bit. If the hardware doesn't support 64-bit, you've hit end-of-life anyway.

Deprecated machine types removed

Several old x86 machine types are gone:

Removed x86 machine types:
- pc-i440fx-2.6
- pc-i440fx-2.7
- pc-q35-2.6
- pc-q35-2.7

Removed ARM machine types:
- ast2700a0-evb (replaced by ast2700a1-evb)
- highbank
- midway

Who is affected: Anyone with old VM definitions using these machine types.

Check if you're affected:

# Look for machine type definitions in your VM configs
grep -r "machine type" /etc/libvirt/qemu/

# Or check running VMs
virsh list --all
virsh dumpxml <vm-name> | grep machine

What happens if you try to run an old machine type: QEMU 11.0 will refuse to start the VM.

Path forward: Before upgrading to 11.0, migrate VMs to newer machine types:

# For x86, migrate to pc-q35-9.1 or newer (q35 is the modern chipset model)
# For ARM, migrate to virt board or newer ast2700a1-evb

# In libvirt XML, change from:
# <machine type='pc-q35-2.7'>
# to:
# <machine type='pc-q35-9.1'>

# Then power off the VM, edit the XML, and boot
virsh shutdown <vm-name>
virsh edit <vm-name>  # Change machine type
virsh start <vm-name>

⚠️ Test the migration on a non-critical VM first. Some old machine types had quirks that newer ones don't replicate exactly.

What's actually useful in QEMU 11.0

VM migration improvements (the big win)

QEMU 11.0 improves live migration, especially for large memory VMs and unaligned RAM blocks.

What improved:

  1. Mapped RAM migration with x-ignore-shared: Fixes issues when migrating VMs with shared memory regions. Useful for multi-process VMs and complex setups.
  2. Dirty sync optimization for unaligned RAM blocks: KVM-backed VMs with non-aligned memory now migrate faster because dirty page tracking doesn't need to sync the entire block.
  3. COLO multifd support: Cluster-Oriented Live Migration (COLO) — where both source and destination VMs run simultaneously and stay in sync — now uses parallel migration streams for better throughput.
  4. New failing migration status: Gives you better visibility into migration problems (previously it would just hang or error out cryptically).

Practical impact: If you migrate large VMs (>100GB RAM) or run COLO setups, this release should be faster and more reliable.

Test before production:

# Test migration of a non-critical VM
virsh migrate --live --persist <vm-name> qemu+ssh://target-host/system

CPU model updates: Diamond Rapids for Intel

QEMU 11.0 adds emulation for Intel's Diamond Rapids CPU. If you're:

  • Running a cloud infrastructure and advertising specific CPU models to guests
  • Testing software that requires Xeon processor-specific features
  • Benchmarking Intel CPU-specific optimizations

Then you can now emulate Diamond Rapids:

qemu-system-x86_64 -cpu DiamondRapids

This is useful if you want guest VMs to report a newer CPU model to applications that check for specific instruction sets or features.

KVM virtualization improvements

CET virtualization support (Control-Flow Enforcement Technology): If you're running the very latest Intel processors with CET hardware support, QEMU 11.0 can expose this to guests. Mostly relevant for future-proofing; few applications require it today.

SEV-SNP and TDX improvements: AMD and Intel confidential VMs get better reset handling and error reporting. If you're using AMD SEV-SNP (Secure Encrypted Virtualization) or Intel TDX (Trusted Domain eXtensions), these are meaningful updates for production deployments.

PSCI version negotiation: ARM KVM VMs can negotiate PSCI (Power State Coordination Interface) versions, improving compatibility with newer kernels.

ARM architecture updates

SMMUv3 acceleration: The ARM System Memory Management Unit v3 can now be accelerated with -device arm-smmuv3,accel=on. This speeds up IOMMU operations for ARM VMs with many I/O devices.

# Enable SMMUv3 acceleration on ARM virt board
qemu-system-aarch64 -M virt -device arm-smmuv3,accel=on

FEAT_ASID2 and FEAT_E2H0 support: Latest ARM FEAT tags for address space isolation and privileged execution level handling. Mostly relevant for ARM CPU emulation accuracy; guest OSes won't care unless they explicitly rely on these features.

WHPX support for virt board: On Windows hosts with WHPX (Windows Hypervisor Platform) enabled, you can now use it with the ARM virt board, not just x86.

Storage and graphics improvements

virtio-gpu context drivers: GPU acceleration improvements for guests using virtio-gpu. Per-output resolution settings improve display flexibility.

NFS block driver v6 support: The NFS block driver now supports libnfs v6, useful if you're serving VM disk images over NFS and the storage array requires the newer protocol.

curl force-range option: When using HTTP(S) for disk images, the force-range option lets you work around misconfigured servers that don't properly handle HTTP range requests. Useful for hosting VM images on restrictive CDNs.

FUSE asynchronous requests: FUSE block export (exporting a VM's disk as a FUSE filesystem on the host) now handles requests asynchronously and supports multiple I/O threads, improving throughput.

Upgrade checklist

Before upgrading to 11.0

  1. Test on non-critical VMs first: Upgrade QEMU on a dev/staging host and migrate a VM, verify it boots and works normally.

Plan machine type migrations:

# For x86 VMs: migrate to pc-q35-9.1 (modern chipset)
# For ARM VMs: migrate to virt board or ast2700a1-evb

Identify affected VMs (using removed machine types):

# If output includes pc-i440fx-2.6, pc-i440fx-2.7, pc-q35-2.6, pc-q35-2.7
# or ast2700a0-evb, highbank, midway, you need to migrate

Check which machine types your VMs use:

for vm in $(virsh list --all --name); do
  echo "VM: $vm"
  virsh dumpxml $vm | grep "machine type"
done

Migration steps

For each affected VM:

# 1. Shut down the VM
virsh shutdown <vm-name>

# 2. Edit the VM definition
virsh edit <vm-name>

# 3. Change the machine type from old to new
# For example: <machine type='pc-q35-9.1'>

# 4. Save and exit

# 5. Boot and test
virsh start <vm-name>

# 6. Verify it works
virsh console <vm-name>

Upgrade path for QEMU itself

On Debian/Ubuntu:

apt update && apt install --only-upgrade qemu

On RHEL/AlmaLinux:

dnf upgrade qemu

On Proxmox (if you're using PVE):

apt update && apt full-upgrade  # This brings in QEMU 11.0 when available

⚠️ On Proxmox, test migration thoroughly before upgrading production nodes. The machine type changes can affect running cluster migrations.

Who should upgrade and who should wait

Upgrade QEMU 11.0 now (if applicable):

  • New deployments and dev environments
  • Running large VMs (>100GB) that benefit from migration improvements
  • Using AMD SEV-SNP or Intel TDX (confidential VM improvements)
  • Using SMMUv3-accelerated ARM VMs
  • Running NFS or HTTP-backed VM images (driver improvements)

Wait 1-2 months:

  • Production Proxmox clusters (let others find edge cases first)
  • Running critical legacy VMs with old machine types (more time to plan migration)
  • Small single-host deployments (no urgency)

Stick with QEMU 10.2.x:

  • Running on 32-bit hosts (you need to stay until you upgrade the OS)
  • Lots of VMs with old machine types and no migration window (too risky)

Key takeaway

QEMU 11.0 is a solid release with real improvements for VM migration and modern CPUs. The breaking changes are manageable if you plan ahead. 32-bit host support is gone (accept it and upgrade the OS), and old machine types are removed (migrate on your schedule, not rushed).

For most sysadmins, upgrading after a month of others testing is the right call. The migration improvements are useful but not critical unless you're running very large VMs.

See the full changelog at wiki.qemu.org/ChangeLog/11.0 for exhaustive details.

Read more