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

Blackclaws said:
I think it shows up only with Qemu 11.0
Click to expand...
Could you verify this? It would be interesting to know whether it occurs with either pve-qemu-kvm=10.2.1-2 and pve-qemu-kvm=10.1.2-7 too. You can downgrade the package, and then start a VM for testing (and then upgrade it again before starting other VMs if you would like to avoid them also using the older version).
 
fiona said:
Could you verify this? It would be interesting to know whether it occurs with either pve-qemu-kvm=10.2.1-2 and pve-qemu-kvm=10.1.2-7 too. You can downgrade the package, and then start a VM for testing (and then upgrade it again before starting other VMs if you would like to avoid them also using the older version).
Click to expand...
Not the person you replied too but I tested and it didn't work with 10.2.1-2 but did with 10.1.2-7, I have a realtek nic though and my problem was internal dns didn't work in my k3s node.
 
  • Like
Reactions: fiona
Between QEMU 10.1 and 10.2 support for negotiating extended VirtIO features was added.

Could you go to the VM monitor qm monitor ID with the numerical ID of the VM and run the following commands
Code: 
qm> info virtio
/machine/peripheral/net1/virtio-backend [virtio-net]
/machine/peripheral/virtio0/virtio-backend [virtio-blk]
/machine/peripheral/balloon0/virtio-backend [virtio-balloon]
qm> info virtio-status /machine/peripheral/net1/virtio-backend
/machine/peripheral/net1/virtio-backend:
  device_name:             virtio-net (vhost)
  device_id:               1
...
as well as ethtool -k bridge with your actual bridge name used for the VM interface. Both when it's working and when it's not working, so the outputs can be compared. Please indicate the used QEMU and host kernel versions each time.

Does using host kernel 6.17 work as well to mitigate the issue?
 
Last edited:
fiona said:
Between QEMU 10.1 and 10.2 support for negotiating extended VirtIO features was added.

Could you go to the VM monitor qm monitor ID with the numerical ID of the VM and run the following commands
Code: 
qm> info virtio
/machine/peripheral/net1/virtio-backend [virtio-net]
/machine/peripheral/virtio0/virtio-backend [virtio-blk]
/machine/peripheral/balloon0/virtio-backend [virtio-balloon]
qm> info virtio-status /machine/peripheral/net1/virtio-backend
/machine/peripheral/net1/virtio-backend:
  device_name:             virtio-net (vhost)
  device_id:               1
...
as well as ethtool -k bridge with your actual bridge name used for the VM interface. Both when it's working and when it's not working, so the outputs can be compared. Please indicate the used QEMU and host kernel versions each time.

Does using host kernel 6.17 work as well to mitigate the issue?
Click to expand...
Ive attached the output of those commands included the ethtool at the top.

Afaik I remember using 6.17 didn't help.
 

Attachments

Kernel 7.0.6-2, which will soon be on the pve-test repository, contains a fix for UDP offloading. Could you check if the issue also exists with that version (once it's available)?
 
In the VirtIO features I can see that
Code: 
VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO_CSUM: Device can receive GSO over UDP tunnel packets requiring checksum offload for the outer header,
VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO: Device can receive GSO over UDP tunnel packets,
VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO: Driver can receive GSO over UDP tunnel packets requiring checksum offload for the outer header,
VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO: Driver can receive GSO over UDP tunnel packets,
are new between your 10.1 and 10.2 output, so might be related.
 
You must log in or register to reply here.
Top Bottom
Back