On 10/24/24 2:12 PM, Laine Stump wrote:
On 10/24/24 12:36 PM, Daniel P. Berrangé wrote:
[...]
AFAIR, it isn't actually a bug with virtio-net usage as this last bit suggests. Rather it is a result of feature negotiation with QEMU on the host, whereby the guest & QEMU mutually agree to turn off checksums because they are redundant when the "link" is just local memory not a physical cable.
IOW, packets don't arrive in the guest with a bad checksum. They arrive in the guest with no checksum *as requested* by the guest.
The DHCP client decides this is a bad checksum, as it wasn't aware of the checksum offload usage.
[...]
....and in Fedora/RHEL context it was fixed 18 years ago, as we first hit this when working on Xen integration in 2006 :-)
I think you would have to say "in Fedora/RHEL+Xen context it was fixed 18 years ago", since the specific test case that I recall working with was a RHEL5 guest that couldn't get an address from DHCP. So RHEL still had the problem, it just took switching to QEMU + virtio + vhost packet processing to make it visible :-)
A few quick tests proved that it was the same old "bad checksum" problem from 2010 come back to haunt us.
2006 :-)
Interesting - so my origin story is at least partially a false memory :-/
But if you had this problem with Xen in 2006, how was it fixed then (and why was it a surprised when it came up again in 2010 after vhost processing was turned on? Or maybe it wasn't a surprise, and I just thought so because I wasn't around in 2006 :-)
(The commit adding --checksum-fill rules to libvirt was fd5b15ff1, from July 2010)