Comment 9 for bug 1244589

Checksums are generally *not* generated for virtual networking. QEMU participates in this - so:

- when a VM has hardware checksum offload turned on, the 'hardware' in QEMU will neither create nor check checksums. This works fine - checksums are wrong as they go over the brdge, but QEMU doesn't bother to check them at all and it's not a problem. You'll see a problem with this if you have software in the VM that sets offload *and* checks the checksum - the hardware validates the packet but the checksum is wrong when the software double-checks.

- when a VM disables hardware checksum offload then QEMU corrects the checksum on receipt

The (host) Linux kernel will fix checksums on packets that leave the machine.

This typically means that if your DHCP server is running on VLAN networking from a control or network node independent of your VMs it will have fixed checksums - and if it's running locally, the checksums will be wrong, but QEMU should either fix or ignore them and the DHCP agent software shouldn't care to look.

I think the problem is that your DHCP server or agent is taking it upon itself to check the checksum (note: nothing to do with the checksum being wrong, more to do with the checksum not being *ignored*), and you might want to find out what precisely is happening before you go further. (And, for what it's worth, there's no reason I know of why this behaviour would differ between LB and OVS.) That said, the targetted netns fix might well be the one we want - it's quite specific if it can truly be said to only be a DHCP issue.