Bug 612588 - Fail to install guest from net when specifying NIC model to "virtio".
Fail to install guest from net when specifying NIC model to "virtio".
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
All Linux
low Severity high
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On: 605555 612587
Blocks: 563347
  Show dependency treegraph
 
Reported: 2010-07-08 11:07 EDT by Michael S. Tsirkin
Modified: 2010-11-11 14:26 EST (History)
17 users (show)

See Also:
Fixed In Version: libvirt-0_8_1-15_el6
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: 605555
Environment:
Last Closed: 2010-11-11 09:50:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Michael S. Tsirkin 2010-07-08 11:09:02 EDT
proposed solution needs libvirt to program iptables, so cloning here:
http://www.spinics.net/lists/kvm/msg37660.html
Comment 4 Michael S. Tsirkin 2010-07-12 11:53:10 EDT
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.
Comment 6 Laine Stump 2010-07-13 03:11:19 EDT
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
Comment 7 Laine Stump 2010-07-13 11:21:53 EDT
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.
Comment 9 Laine Stump 2010-07-13 13:20:05 EDT
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.
Comment 11 Dave Allan 2010-07-14 03:13:22 EDT
libvirt-0_8_1-15_el6 has been built in RHEL-6-candidate with the fix.

Dave
Comment 13 Johnny Liu 2010-07-27 04:50:46 EDT
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.
Comment 14 Johnny Liu 2010-07-27 05:07:26 EDT
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.
Comment 16 Laine Stump 2010-09-01 23:24:22 EDT
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?
Comment 18 releng-rhel@redhat.com 2010-11-11 09:50:37 EST
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.

Note You need to log in before you can comment on or make changes to this bug.