QEMU 9.2 available on pvetest and pve-no-subscription as of now

[t.lamprecht]

There is a new QEMU 9.2 available in the pvetest and pve-no-subscription repository.

After internally testing QEMU 9.1 for a couple of months, and then 9.2 for a couple of weeks, we decided to skip a separate 9.1 update and move directly to QEMU 9.2 as the default version included in the next point release, which is scheduled for early spring 2025.
After over a month on the pvetest repository, we now (2025-03-12) made our QEMU 9.2 package available in the pve-no-subscription repository.
Our QEMU package version 9.2.0-1 includes some important stable fixes that have been developed since the original 9.1.0 and 9.2.0 releases.

Note: While some of our 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. As a reminder, we recommend using the most stable Enterprise repository for such production setups.

To upgrade, make sure you have configured either the Proxmox VE No-Subscription repository or the Proxmox VE Test repositories.
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:

apt update
apt full-upgrade

The output of pveversion -v (or the web-interface's Node Summary -> Packages versions) should then include something like pve-qemu-kvm: 9.2.0-2

Note, as with all QEMU updates: 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.

FYI, while we have decided not to push out QEMU 9.1 due to the timing of our last point release, we have uploaded a build of it anyway, so you can more easily narrow down when any potential differences or even regressions have been introduced. You can explicitly update to this interim version using apt install pve-qemu-kvm=9.1.2-3.

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:
Pass-through of integrated graphic card (iGPU) in legacy mode seems to be broken on i440fx (ref this thread).

EDIT 2025-03-12: The package has now been moved to pve-no-subscription.

 

[bbgeek17]

Thanks for the update!
We will get it into our QA cycle ASAP

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[Uturn]

Based on my issues with pve-qemu-kvm > 8.1.5-6, i gave this version a try, but unfortunately the unable to map registers message come up again and also PCIe passthrough doesn't work. For a short test, i only installed pve-qemu-kvm 9.2.0-1 from pvetest without any additional updates, powered off/on a VM and check dmesg. Nonetheless i guess that should be enough for testing.

@fiona do you know if the SeaBIOS changes made it into pve-qemu-kvm: 9.2.0-1 as discussed here: https://forum.proxmox.com/threads/qemu-9-0-available-as-of-now.149772/page-4#post-722931

 

[fiona]

Hi,

Based on my issues with pve-qemu-kvm > 8.1.5-6, i gave this version a try, but unfortunately the unable to map registers message come up again and also PCIe passthrough doesn't work. For a short test, i only installed pve-qemu-kvm 9.2.0-1 from pvetest without any additional updates, powered off/on a VM and check dmesg. Nonetheless i guess that should be enough for testing.

@fiona do you know if the SeaBIOS changes made it into pve-qemu-kvm: 9.2.0-1 as discussed here: https://forum.proxmox.com/threads/qemu-9-0-available-as-of-now.149772/page-4#post-722931

Unfortunately not, SeaBIOS hasn't seen a new release yet, so QEMU 9.2 still has SeaBIOS 1.16.3

 

[Ramalama]

It's funny, im using pvetest since forever and never had any issues or bugs.

Using qemu 9.2 since a week,
- changed all Windows-VM's to 9.2 / Linux-VM's are anyway automatically on 9.2
- Have some VM's with passthrough, for NICS's and GPU

And everything runs absolutely Perfect on all 11 PVE-Servers/Clusters, ranging from consumer hardware to Enterprise Genoa Servers. From Old to New Hardware...
Thanks for the work

 

[cRaZy-bisCuiT]

Hello @t.lamprecht,
QEMU 9.2 has support for Virtio-GPU Venus. Is it possible to test this with Proxmox already? Unfortunately VAAPI-Video-Encoding ist not yet supported with the current release, therefore Streaming from those VMs or using them as an encoding server would most likely not work. Still it should be possible to do compute task.

EDIT: Well, as far as I know you'll need Kernel 6.13 for it to work. So maybe we need to wait a little longer...

 

[mcpat]

I get this error on my 12th gen Alder Lake (Intel Pentium Gold 8505 processor), but this error does not accure on v9.0 and I didn't changed the conf file

kvm: -device vfio-pci,host=0000:00:02.0,id=hostpci0,bus=pci.0,addr=0x2,romfile=/usr/share/kvm/gen12_igd.rom: IGD device 0000:00:02.0 is unsupported in legacy mode, try SandyBridge or newer

 

[rfox]

Stupid question #354 - running latest PVE 8.3.4 - enabled pvetest and wanted to try qemu 9.2 - after update I see pve-qemu-kvm: 9.2.0-2 in pveversion -v
but qemu-server version says: qemu-server: 8.3.8 Is that right ??

 

[t.lamprecht]

but qemu-server version says: qemu-server: 8.3.8 Is that right ??

Yes, that's fine. qemu-server ships the management code we developed to integrate QEMU into Proxmox VE and its version is not tied to the actual lower-level QEMU version packaged as pve-qemu-kvm.

 

[t.lamprecht]

Hello @t.lamprecht,
QEMU 9.2 has support for Virtio-GPU Venus. Is it possible to test this with Proxmox already? Unfortunately VAAPI-Video-Encoding ist not yet supported with the current release, therefore Streaming from those VMs or using them as an encoding server would most likely not work. Still it should be possible to do compute task.

EDIT: Well, as far as I know you'll need Kernel 6.13 for it to work. So maybe we need to wait a little longer...

Yeah, probably rather something to try in PVE 9, which is due sometime later this year. Then distros running inside guests should have also caught up with their kernel and mesa versions.

 

[t.lamprecht]

I get this error on my 12th gen Alder Lake (Intel Pentium Gold 8505 processor), but this error does not accure on v9.0 and I didn't changed the conf file

kvm: -device vfio-pci,host=0000:00:02.0,id=hostpci0,bus=pci.0,addr=0x2,romfile=/usr/share/kvm/gen12_igd.rom: IGD device 0000:00:02.0 is unsupported in legacy mode, try SandyBridge or newer

As the ROM is not shipped by any of our packages, nor is it open source FWICT, this not something we can ensure to fix.

But just to be sure: is this a warning only or a hard error? Is the VM configured as q35 machine or as i440fx one?
For such a thing it might be better to open a new thread, potentially others of the community came up with, or stumbled upon, a solution.

 

[mcpat]

As the ROM is not shipped by any of our packages, nor is it open source FWICT, this not something we can ensure to fix.

But just to be sure: is this a warning only or a hard error? Is the VM configured as q35 machine or as i440fx one?
For such a thing it might be better to open a new thread, potentially others of the community came up with, or stumbled upon, a solution.

The rom is not the fault, because it's working on v9.0

Not sure if VM is starting or stopping. I downgraded to v9.0 again, but I can try if you want. What I remember, VM is starting without iGPU.
But with same configuration is working on v9.0. I can open a new thread, but I think there is something "wrong" with v9.2 and I thought this is the correct thread to report the feedback.

VM is configured as i440fx, if you are interested, this is the conf:

balloon: 8192
bios: ovmf
boot: order=scsi0;ide2;ide0;net0
cores: 5
cpu: host
efidisk0: local-lvm:vm-101-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
hostpci0: 0000:00:02.0,romfile=gen12_igd.rom,legacy-igd=1
hostpci1: 0000:00:1f.3,romfile=IntelGopDriver.rom
ide0: local:iso/virtio-win-0.1.266.iso,media=cdrom,size=707456K
ide2: local:iso/26100.1742.240906-0331.ge_release_svc_refresh_SERVER_EVAL_x64FRE_de-de.iso,media=cdrom,size=5916388K
machine: pc-i440fx-9.2
memory: 16384
meta: creation-qemu=9.0.2,ctime=1739926191
name: Windows
net0: virtio=BC:24:11:D8:F2:FD,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsi0: local-lvm:vm-101-disk-1,discard=on,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=7ff720da-6f49-4949-85b1-e5e5d5b3f3dc
sockets: 1
tpmstate0: local-lvm:vm-101-disk-2,size=4M,version=v2.0
usb0: host=3-6,usb3=1
usb1: host=3-8,usb3=1
vga: none
vmgenid: ff78921c-0d61-4886-b4a8-fd12b96888ff

 

[t.lamprecht]

The rom is not the fault, because it's working on v9.0

That's not how it necessarily works, if the ROM is using some old legacy features that get deprecated/changed in QEMU then the ROM would need updating, we cannot tell for sure as it's a black box; that's not your fault but neither ours, so even if a newly introduced bug in QEMU causes that what I said still applies in full:

As the ROM is not shipped by any of our packages, nor is it open source FWICT, this not something we can ensure to fix.

If you can reproduce this on a plain QEMU you could also ask on the QEMU upstream issue tracker, but please avoid entitlement or being all to sure that QEMU is at fault here, that might not result in a productive exchange, I'm sure you wouldn't, but I rather state such things explicitly nonetheless.

but I think there is something "wrong" with v9.2 and I thought this is the correct thread to report the feedback.

Wrong in general? No. Something specific to passthrough does not seem broken either, we recently tested vGPU passthrough quite a bit in light of this news, including with QEMU 9.2. Something that changed on which the iGPU passthrough and the ROM used relies on, yes, probably.
I also think it was a good call to report here in the community forum, I looked at it and did some light investigation, that did not result in anything obvious or known findings, and as iGPU is often rather brittle and not supported I wanted to set the expectations not to high.
I added this report as known issue to the post above for now.

Not sure if VM is starting or stopping

You can check the task log of that VM in the web UI, there you should see if it was a warning or error.

Two pointers I found:
First, there seems some work ongoing in this area to split out some quirks from legacy mode to make this work in more situations: https://lore.kernel.org/all/20250303175220.74917-1-tomitamoeko@gmail.com/

Second, this one is mostly for others reading this, as it's your thread after all, it might be an option to use non-legacy mode with a q35 machine: https://forum.proxmox.com/threads/ugreen-dxp4800-igpu-99-success-win-server-2025.163149/#post-753351

 

[fiona]

kvm: -device vfio-pci,host=0000:00:02.0,id=hostpci0,bus=pci.0,addr=0x2,romfile=/usr/share/kvm/gen12_igd.rom: IGD device 0000:00:02.0 is unsupported in legacy mode, try SandyBridge or newer

hostpci0: 0000:00:02.0,romfile=gen12_igd.rom,legacy-igd=1

Since the error says it's unsupported in legacy mode, what if you don't use the legacy-igd=1 flag?

 

[cRaZy-bisCuiT]

Yeah, probably rather something to try in PVE 9, which is due sometime later this year. Then distros running inside guests should have also caught up with their kernel and mesa versions.

Looking forward to official Virtio-GPU Venus and/or DRM native support soon(tm) then.

 

[mcpat]

Since the error says it's unsupported in legacy mode, what if you don't use the legacy-igd=1 flag?

So i finally retested it. It is not a stop, but the igd is not working, result is a blank screen (but VM is running).

Without legacy-igd I have to switch to q35 which is working if I add args line with opregion:

args: -set device.hostpci0.x-igd-opregion=on
...
hostpci0: 0000:00:02.0,romfile==gen12_igd.rom
...
machine: pc-q35-9.2
...

But with v9.0 I can start both, q35 and i440fx with x-legacy-igd. With i440fx everything is working fine including boot screen, with q35 it's only working after shutdown and start again. I openend therefore a second thread, but didn't find any solution until now (so this problem exists for me since v9.0.

So conclusio, with v9.2 i440fx is broken for alder lake with x-legacy-igd. I found out it was pachted in qemu git - see here. I tried to patch your git with this patches (10 in total), and now it starts without error, but hangs with other erros. I didn't ivenstigate further to find all patches to get the legacy work.

The stupid "bug", that I have to shutdown and start again in q35 to get rid of this blurry screen) is here since v9.0 up to v9.2 (older versions I didn't test, because I don't have my NAS that long time).

I can see progress on qemu git acc. vfio/igd, so hopefully with next version everyhing is working.

 

[Ramalama]

It's funny, im using pvetest since forever and never had any issues or bugs.

Using qemu 9.2 since a week,
- changed all Windows-VM's to 9.2 / Linux-VM's are anyway automatically on 9.2
- Have some VM's with passthrough, for NICS's and GPU

And everything runs absolutely Perfect on all 11 PVE-Servers/Clusters, ranging from consumer hardware to Enterprise Genoa Servers. From Old to New Hardware...
Thanks for the work

Oh just for the sake of completeness, everywhere i use passthrough, im using q35. Im using q35 even for almost everything, i think there may be 2-3 i440fx vms out of ~40-50.

That time i started to passthrough devices it wasnt possible with i440fx, there was at that time some bug on freebsd.
That bug was fixed with never freebsd versions, but i switched at that time everything to q35 and never looked back.

@mcpat you should use q35 as well, especially for passthrough. i440fx is pretty old and i believe it gets removed anyway at some point in the future.

Cheers

​

 

[t.lamprecht]

FYI: We now moved QEMU 9.2.0-2 to the no-subscription repository.

The only known issue is with pass through of iGPUs on VMs using the i440fx machine and legacy modes, here it's recommended to switch to using q35, see further above in this threads for more details.

 

[mcpat]

@mcpat you should use q35 as well, especially for passthrough. i440fx is pretty old and i believe it gets removed anyway at some point in the future.

Cheers

​

I really want to switch to q35, but please look at this topic, I get a "blurry" screen on first boot. This behaviour is also on v9.0. And with q35 there is also no startup/boot screen of windows, but I can live with it, the problem is the "blurry" screen.

 

[Neobin]

There are two reports of quite higher CPU utilization on Linux-VMs with/since the update to QEMU 9.2:

H

Thread 'plötzlich höhere CPU-Last bei allen Linux-VMs?!'

Mar 16, 2025

Hallo, seit dem letzten PVE-Update (bei mir am Mittwoch so um 18 Uhr eingespielt) wird bei allen Linux-VMs plötzlich eine deutlich höhere CPU-Auslastung angezeigt:

Linux:


Linux:


Linux:


Bei den Windows-VMs nicht:


Ich vermute, dass es durch das PVE-Update kam, weil auch meine Telefonanalgen-VM davon betroffen ist (ebenfalls Linux), die aber definitiv kein Update am Mittwoch bekam, weil sie aus dem Support ist (die anderen Linux-VMs wurden mit PVE geupdatet).

Ist das bekannt? Ist nervig, weil die Lärmbelästigung durch die lauteren Lüfter...

• HalloWelt
• Replies: 70
• Forum: Proxmox VE (Deutsch/German)