proposed solution needs libvirt to program iptables, so cloning here:
http://www.spinics.net/lists/kvm/msg37660.html

iptables need to apply this upstream patch:
http://patchwork.ozlabs.org/patch/58525/

Then libvirt should add a rule when programming NAT
as explained in link above.

The libvirt part of this patch has been tested with the abovementioned iptables patch and test kernel, and found to properly remedy the problem.

I've posted it to rhvirt-patches:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg00350.html


The same patch has also been posted upstream, but not yet ACKed or committed:

https://www.redhat.com/archives/libvir-list/2010-July/msg00256.html

Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
In any release of RHEL that has vhost-net enabled (evidenced by the presence of /dev/vhost-net, and the string "vhost=on" in the output of "/usr/libexec/qemu-kvm --help"), and that does not have this patch (and the corresponding patches for iptables (see Bug 612587) and the kernel (see Bug 605555) applied, some older guest OSes will be unable to acquire an IP address from the DHCP server started up by libvirt on the host (in particular, RHEL5 and older will have this problem). To work around this problem, you will need to disable vhost-net in the host, by unloading the vhost-net module.

Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1,7 @@
-In any release of RHEL that has vhost-net enabled (evidenced by the presence of /dev/vhost-net, and the string "vhost=on" in the output of "/usr/libexec/qemu-kvm --help"), and that does not have this patch (and the corresponding patches for iptables (see Bug 612587) and the kernel (see Bug 605555) applied, some older guest OSes will be unable to acquire an IP address from the DHCP server started up by libvirt on the host (in particular, RHEL5 and older will have this problem). To work around this problem, you will need to disable vhost-net in the host, by unloading the vhost-net module.+In any release of RHEL that has vhost-net enabled (evidenced by the presence of /dev/vhost-net, and the string "vhost=on" in the output of "/usr/libexec/qemu-kvm --help"), and that does not have this patch (and the corresponding patches for iptables (see Bug 612587) and the kernel (see Bug 605555) applied, some older guest OSes will be unable to acquire an IP address from the DHCP server started up by libvirt on the host (in particular, RHEL5 and older will have this problem). To work around this problem, you will need to disable vhost-net in the host, by preventing the vhost-net module from being loaded at host boot time.
+
+To do this, create a file "/etc/modprobe.d/vhost-blacklist.conf" containing the following line:
+
+   install vhost_net /bin/true
+
+and reboot the host. Don't forget to remove this file once the patched binaries are installed.

libvirt-0_8_1-15_el6 has been built in RHEL-6-candidate with the fix.

Dave

Verified the bug with libvirt-0.8.1-15.el6.x86_64, kernel-2.6.32-52.el6.x86_64 and iptables-1.4.7-3.el6.x86_64, and PASSED.

The guest (RHEL5u5 and RHEL4u8) with virtio NIC + NAT network now can get IP successfully.

For the newest iptables packages - iptables-1.4.7-3.el6.x86_64, the following iptables rule is added:
Table: mangle
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    CHECKSUM   udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:68 CHECKSUM fill


For old iptables packages - iptables-1.4.7-2.el6.x86_64, a failure to add this
rule will results in a warning message in /var/log/message:
...
Jul 27 13:10:20 localhost libvirtd: 13:10:20.601: error : virRunWithHook:933 : internal error '/sbin/iptables --table mangle --delete POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.7: unknown option `--checksum-fill'#012Try `iptables -h' or 'iptables --help' for more information.#012
Jul 27 13:10:20 localhost libvirtd: 13:10:20.630: error : virRunWithHook:933 : internal error '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 69 --jump ACCEPT' exited with non-zero status 1 and signal 0: iptables: Bad rule (does a matching rule exist in that chain?).#012
Jul 27 13:10:20 localhost libvirtd: 13:10:20.670: error : virRunWithHook:933 : internal error '/sbin/iptables --table mangle --insert POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.7: unknown option `--checksum-fill'#012Try `iptables -h' or 'iptables --help' for more information.#012
Jul 27 13:10:20 localhost libvirtd: 13:10:20.670: warning : networkAddIptablesRules:851 : Could not add rule to fixup DHCP response checksums on network 'default'
....

This is expected.

The bug is fixed (although I recall seeing that vhost-net may be disabled for other reasons). Is the proper procedure to erase the contents of the Technical Notes field?

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.