Hi community and experts, We have recently attempted to upgrade OVS 2.12+DPDK 18.11 to OVS 2.13.11+DPDK 19.11.14. And then we encountered a state where some virtual machine network cards are down, and users were not able to start the network cards inside the guest VM. After investigating, we found that qemu reported errors (many many times) , which means virtIO feature negotiation failed: 2024-10-15T06:25:16.986398Z qemu-kvm: failed to init vhost_net for queue 0 vhost lacks feature mask 16384 for backend
Which means the backend of virtIO, aka vhostuser, does not support 16384 (the 14th in feature bits). Source code definition bit: #define VIRTIO_NET_F_HOST_UFO 14 /* Host can handle UFO in. */ In the same host, if the HOST_UFO bit of some virtual machines is set to 1, the network card cannot start. While some are 0, it can be started. We found some useful series of links: https://mail.openvswitch.org/pipermail/ovs-dev/2023-June/405829.html https://bugzilla.redhat.com/show_bug.cgi?id=1845488#c5 The conclusion seems to be that such hot upgrade is impossible to achieve. If the guest VM is not restarted or the network card is not redo hot unplug and plug, the user's network card will not be able to work properly. This situation is unacceptable for a cloud environment because we cannot require all user VMs to be restarted. Therefore, I'm asking here if there is a possible work around to achieve such an upgrade? Regards, LIU Yulong _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
