Red Hat Bugzilla – Bug 516022
virtio-net fails to transmit any packets, gives "Network is unreachable" errors
Last modified: 2009-08-07 05:57:28 EDT
Description of problem:
This is on Rawhide, booting an appliance like this:
-drive file=/tmp/test.img,cache=off,if=virtio \
-m 500 -no-reboot \
-kernel /tmp/libguestfsJMrUXK/kernel \
-initrd /tmp/libguestfsJMrUXK/initrd \
-append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off cgroup_disable=memory selinux=0 guestfs=10.0.2.4:6666 guestfs_verbose=1' \
-nographic -serial stdio \
-net channel,6666:unix:/tmp/libguestfsJMrUXK/sock,server,nowait \
-net user,vlan=0,net=10.0.2.0/8 \
-net nic,model=virtio,vlan=0 \ <===== NB
When the appliance boots, it does this inside the guest:
/sbin/ifconfig lo 127.0.0.1
/sbin/ifconfig eth0 10.0.2.10
/sbin/route add default gw 10.0.2.2
ping -n -v -c 5 10.0.2.2
Ping fails with:
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
From 10.0.2.10 icmp_seq=2 Destination Host Unreachable
From 10.0.2.10 icmp_seq=3 Destination Host Unreachable
From 10.0.2.10 icmp_seq=4 Destination Host Unreachable
Also connections from inside the guest fail with:
connect: Network is unreachable
Previously this was worked fine to set up the network.
However in Rawhide, this fails a lot of the time.
The virtio_net module is loaded, and there are no kernel
errors or other messages to indicate any problem.
If I change the line marked "NB" above to:
(and obviously load the ne2k-pci driver instead of virtio_net)
then the test *works*.
Note: The only change in the test is replacing virtio with ne2k-pci,
so it does appear to be a problem with virtio somewhere.
Version-Release number of selected component (if applicable):
kernel (in guest) 2.6.31-0.24.rc0.git18.fc11.x86_64
Not 100% of the time, but quite close to it.
Steps to Reproduce:
guestfish -v alloc /tmp/test.img 200M : run
Also tried the newest kernel, same problem:
First, I haven't been able to reproduce with a 'normal' guest - not using slirp, vmchannel, the same nic config commands libguestfs uses etc. etc.
But I can reproduce with libguestfs, so I bisected it
The first commit that causes this regression is:
That's MSI support. Okay, well using e.g. '-nic vectors=0' works around that
Well, not so easy as that, there's actually another regression. vectors=0 works right up until this commit:
That's some slirp re-factoring
i.e. we've two regressions to investigate here, which we've only managed to reproduce with libguestfs so far
Okay, this fixes the slirp regression:
* Fri Aug 7 2009 Mark McLoughlin <email@example.com> - 2:0.10.91-0.5.rc1
- Fix virtio_net with -net user (#516022)
Now it works with -net vectors=0, but broken otherwise - i.e. there's still something wrong with MSI
Okay, I can't reproduce the MSI issue now, perhaps I was confused and it has since been fixed
Closing for now
f12-alpha tag request: