QEMU 11.0 available on pve-test and pve-no-subscription as of now

shanreich said:
Since this is a bond, what is the ethtool output for the other bond member? (eno1np0). Can you also post the VM configuration? qm config <VMID>? In our tests tx-checksum-ip-generic also seemed to be involved somehow and in your output it is turned off for the bond member, but turned on for the bond itself which is interesting to say the least...
Click to expand...
Thanks for response

As far as I understand bond0 interface is a virtual entity and traffic goes over physical interface anyway and being controlled by physical interface settings. But I'm not an expert here and my assumption could be wrong.

Attached a requested data:
- pve version
- cat /etc/network/interfaces
- ethtool -k bond0
- ethtool -k eno1np0
- ethtool -k eno2np1
- qm config 101

Thanks!
 

Attachments

Hello,

When was use a Q35 v10, v11, disk is 100% just at boot with last release driver virtio.
i think it possible bug. (VM freeze)


PVE Version:
pveversion --verbose | sort -n
amd64-microcode: 3.20251202.1~bpo13+1
ceph: 19.2.3-pve1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
dnsmasq: 2.91-1+deb13u1
frr-pythontools: 10.6.1-1+pve2
ifupdown2: 3.3.0-1+pmx12
ifupdown: residual config
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.16
libpve-guest-common-perl: 6.0.4
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.6
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxcfs: 7.0.0-pve1
lxc-pve: 7.0.0-2
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.2-1
proxmox-backup-file-restore: 4.2.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-6.8.12-18-pve-signed: 6.8.12-18
proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
proxmox-kernel-7.0.2-4-pve-signed: 7.0.2-4
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0: 7.0.12-1
proxmox-kernel-helper: 9.2.0
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
proxmox-widget-toolkit: 5.2.5
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: not correctly installed
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.8.0
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.17
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1
Click to expand...

Q35 9.2: OK
Q35 10.X: DISK IO (100%)
Q35 11.X: DISK IO (100%)
agent: 1
allow-ksm: 0
balloon: 0
bios: ovmf
boot: order=sata0;ide0
cores: 12
cpu: host
efidisk0: NVME:310/vm-310-disk-0.qcow2,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=528K
hostpci0: mapping=RTX_3060,pcie=1,x-vga=1
hotplug: usb
ide0: local:iso/virtio-win-0.1.285.iso,media=cdrom,size=771138K
machine: pc-q35-9.2
memory: 12288
meta: creation-qemu=11.0.0,ctime=1780662994
name: CloudGaming
net0: virtio=BC:24:11:54:47:D7,bridge=vmbr0
numa: 0
ostype: win10
sata0: NVME:310/vm-310-disk-1.qcow2,backup=0,cache=writeback,size=50G,ssd=1
sata1: NVME:310/vm-310-disk-2.qcow2,backup=0,cache=writeback,size=129G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=db89d1f4-8df0-4d71-8ce8-48c6a34169f4
sockets: 1
tablet: 0
usb0: mapping=Lenovo_Bluetooth_Mouse,usb3=1
usb1: mapping=Keyboard_Dell,usb3=1
usb2: mapping=Dongle_Bluetooth,usb3=1
vga: none
vmgenid: 8b78a611-8bd3-45fa-a291-9181a0686ea1
Click to expand...
 
Last edited:
Seems like I forgot to follow-up regarding the VirtIO networking issue here before my vacation (only did it in another thread and the bug tracker). The issue was caused by a bug in the virtio-net kernel driver. The guest kernel is outside of Proxmox VE's control, so we are thinking about disabling the host_tunnel feature by default for now. Proposed patches with all the details:
https://lore.proxmox.com/pve-devel/20260626120701.116793-1-f.ebner@proxmox.com/T/
 
Hello,

Not sure if this is the right post to ask but, any hint of when are going to be available a new Windows VirtIO driver version?

I read on QEMU 11 changelog that with the new guest agent version now it is possible to retrieve the routing table of a Windows guest and that they fixed the event 8194 when you backup a VM. It has been almost a year since the latest VirtIO driver release, and it is not recommended for production use.
 
Hi @jjimenez,
Proxmox developers are not directly involved with the development of the VirtIO-win drivers. Some are part of the surrounding community. The upstream project is here. Maybe @l.leahu-vladucu can give a rough estimate about how far off a release might be.
 
Hi @jjimenez! I also do not have a concrete date or a rough estimate about how far off a release of the new VirtIO Windows drivers could be. We are aware of the issue with event 8194, as reported upstream and in the QEMU changelog as well. The developers of the VirtIO Windows drivers mentioned here that there's a new release of the QEMU Guest Agent, but we haven't tested it yet, so we cannot recommend it yet for production purposes. Of course, feel free to test it on a test VM and report back. If you want to test it on a test VM, you can extract the RPM and install the qemu-ga-x86_64.msi that is available inside the RPM package.
 
  • Like
Reactions: fiona and Johannes S
l.leahu-vladucu said:
Hi @jjimenez! I also do not have a concrete date or a rough estimate about how far off a release of the new VirtIO Windows drivers could be. We are aware of the issue with event 8194, as reported upstream and in the QEMU changelog as well. The developers of the VirtIO Windows drivers mentioned here that there's a new release of the QEMU Guest Agent, but we haven't tested it yet, so we cannot recommend it yet for production purposes. Of course, feel free to test it on a test VM and report back. If you want to test it on a test VM, you can extract the RPM and install the qemu-ga-x86_64.msi that is available inside the RPM package.
Click to expand...
Hello @l.leahu-vladucu

Six days ago in the same Gitlab post that you quoted they mentioned that the new VirtIO driver release should be available in a month, https://gitlab.com/qemu-project/qemu/-/work_items/3286#note_3654337082

Many thanks to you and @fiona for taking the time to answer me.
 
  • Like
Reactions: Johannes S, l.leahu-vladucu and fiona
Due to multiple nested-virt security-related issues, I've disabled nested virt in my proxmox nodes and was surprised by some VMs not starting after this.
All VMs have this in common:
1. Host cpu is 2x Xeon Gold 6244
2. Nested-virt disabled in PVE (cat /etc/modprobe.d/kvm-nested.conf -> options kvm_intel nested=0)
3. VM CPU type x86-64-v3, default flags
4. Machine q35 11.0+pv2
5. OS type Windows 11/2022/2025

Error message when starting VMs:
Code: 
swtpm_setup: Not overwriting existing state file.
kvm: Hyper-V enlightened VMCS (hv-evmcs) is not supported by kernel
stopping swtpm instance (pid 11568) due to QEMU startup error
TASK ERROR: start failed: QEMU exited with code 1

Changing Machine to q35 10.2 solved this, all VMs started successfully.
 
santiagobiali said:
Error message when starting VMs:
Click to expand...
Try finding if the hv- flags are actually being passed at the time of VM start, with:
Code: 
qm showcmd <vmid> | grep --color "hv_"
Then you could probably remove them from the args (if present) or explicitly enter them in the args (with the - flag) to remove them from being silently passed to the VM startup command.
 
  • Like
Reactions: santiagobiali
gfngfn256 said:
Try finding if the hv- flags are actually being passed at the time of VM start, with:
Code: 
qm showcmd <vmid> | grep --color "hv_"
Then you could probably remove them from the args (if present) or explicitly enter them in the args (with the - flag) to remove them from being silently passed to the VM startup command.
Click to expand...
Code: 
# qm showcmd diff 10.2 -> 11+pve2:
< 'host,-cet-ibt,-cet-ss,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,-vmx-mbec'
> 'host,-cet-ibt,-cet-ss,hv_evmcs,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt'

# "-vmx-mbec" removed and "hv_evmcs" added.

Replacing "-cpu" in args is a no-go for production env, so I tested only cpu: host,flags=-hv-evmc, which succeeded with a warning:
Code: 
swtpm_setup: Not overwriting existing state file.
kvm: warning: Ambiguous CPU model string. Don't mix both "-hv-evmcs" and "hv-evmcs=on"
kvm: warning: Compatibility of ambiguous CPU model strings won't be kept on future QEMU versions
TASK OK
 
You must log in or register to reply here.
Top Bottom
Back