Red Hat Bugzilla – Bug 522994
KVM Fedora 11 guest networking fails with latest (220.127.116.11-43) kernel.
Last modified: 2009-10-06 23:12:48 EDT
Description of problem:
KVM Fedora 11 guest networking fails with latest (18.104.22.168-43) kernel. I have an x86_64 machine running Fedora 11, with the latest updates from yum. Using the KVM packages that come with the distribution, the machine is hosting a Windows virtual machine, four CentOS virtual machines, and one Fedora 11 virtual machine. The host machine has two active ethernet ports which are configured as two bridges. The Windows guest, the Fedora 11 guest, and two of the CentOS guests connect to one of the bridges; the other two CentOS guests connect to the to the other bridge. All the hosts have fixed IP addresses and are able to connect to the internet.
After loading the latest kernel on the Fedora 11 guest, its network functionality ceased completely, except for being able to ping its own IP address (and possibly the loopback interface; I didn't try that). While the Fedora 11 guest's network was not working, the network functions of all the other guests and that of the KVM host were working normally.
Restarting the network on the Fedora 11 guest
reported OK for stopping the network and OK for starting it again.
Rebooting the Fedora 11 guest with the privious kernel (22.214.171.124-217) caused the network functions of the Fedora 11 guest to work normally again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot Fedora 11 guest with 126.96.36.199-43 kernel.
No network connectivity to any other machine.
Network connectivity to other guests, KVM host, and the internet.
*** Bug 525348 has been marked as a duplicate of this bug. ***
Can you attach the output of virsh dumpxml <domain-id>?
Created attachment 362741 [details]
Output of "virsh dumpxml <domain>"
I submitted the duplicate of this bug, so not the original bug author, but have the exact same problem.
I create and run my virtual machines from the command line using qemu-img and qemu-kvm, so as far as I know, ther is no <domain-id>. Here is the command line I use to start the VM in question:
/usr/bin/qemu-kvm -M pc -smp 3 -m 2000 -k en-us -name yosemite -uuid 677e5aed-0eec-ddff-851d-c07a4a0275a2 -vga std -usb -usbdevice mouse -net nic,macaddr=54:52:00:6d:0d:2f,vlan=0,model=virtio -net tap,script=/etc/qemu-br0-ifup -parallel none -no-reboot -pidfile /var/run/libvirt/qemu/yosemite.pid -soundhw es1370 -smb /sata -cdrom /dev/sr0 -boot c -drive file=/opt/kvm/yosemite/yosemite.qcow2,index=0,if=ide,boot=on
Let me know what other information I can provide. I'm a beginner with VM's so please provide detailed instructions for anyting more I need to do.
Thanks for the report John!
I tried to reproduce this using libvirt and couldn't; it works fine if you use libvirt to start the guest
It turns out the reason for this that libvirt is failing to enable GSO support on the tap device, but using qemu-kvm directly *does* enable GSO support
So, the bug is likely related to GSO - some guest change between 2.6.29 and 2.6.30 broke GSO support; we'll need to figure out that change was and fix it
And we'll also need to figure out why libvirt isn't enabling GSO and fix that too
Okay, I found the problem - we need this commit on the stable-0.10 branch:
It seems the offending qemu.git change that this fixes got backported to the stable-0.10 branch.
Building this for F-11:
* Tue Sep 29 2009 Mark McLoughlin <firstname.lastname@example.org> - 2:0.10.6-6
- Fix broken virtio-net with 2.6.30 guests (#522994)
qemu-0.10.6-6.fc11 has been submitted as an update for Fedora 11.
qemu-0.10.6-6.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update qemu'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10147
qemu-0.10.6-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.