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
You must log in or register to reply here.
Top Bottom
Back