Description of problem: I have configuration which went unchanged since a week ago when I had perfectly working laptop with four virtual machines (RHEL4, RHEL5, Rawhide, Fedora11), but something has changed and currently no virtual machine has network access. I have virtual network configured: bradford:~# virsh net-list Jméno Stav Automatické spuštění ----------------------------------------- default aktivní yes bradford:~# virsh net-dumpxml default <network> <name>default</name> <uuid>9d1d2bbf-458a-4eaf-97b4-96b5b333b73d</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0' /> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> </dhcp> </ip> </network> bradford:~# /usr/sbin/brctl show bridge name bridge id STP enabled interfaces pan0 8000.000000000000 no virbr0 8000.0a9abf8527c5 yes vnet0 bradford:~# Version-Release number of selected component (if applicable): bradford:jetpack$ uname -a Linux bradford 2.6.31.6-134.fc12.x86_64 #1 SMP Mon Nov 16 20:38:45 EST 2009 x86_64 x86_64 x86_64 GNU/Linux bradford:jetpack$ rpm -qa \*virt\* \*qemu\* \*kvm\* kernel dnsmasq|sort -u dnsmasq-2.51-1.fc12.x86_64 etherboot-zroms-kvm-5.4.4-17.fc12.noarch gpxe-roms-qemu-0.9.7-6.fc12.noarch kernel-2.6.31.5-122.fc12.x86_64 kernel-2.6.31.5-127.fc12.x86_64 kernel-2.6.31.6-134.fc12.x86_64 libvirt-client-0.7.1-15.fc12.x86_64 libvirt-python-0.7.1-15.fc12.x86_64 libvirt-0.7.1-15.fc12.x86_64 python-virtinst-0.500.0-5.fc12.noarch qemu-common-0.11.0-11.fc12.x86_64 qemu-img-0.11.0-11.fc12.x86_64 qemu-kvm-0.11.0-11.fc12.x86_64 qemu-system-x86-0.11.0-11.fc12.x86_64 virt-manager-0.8.0-7.fc12.noarch virt-mem-0.3.1-9.fc12.x86_64 virt-top-1.0.4-1.fc12.1.x86_64 virt-viewer-0.2.0-1.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.start a virtual machine 2. 3. Actual results: network doesn't start Expected results: it should as it was Additional info:
This is exactly what I have experienced, and problem appeared while system was running. I am not using libvirt so I think problem is kernel related. More info about my configuration at: https://bugzilla.redhat.com/show_bug.cgi?id=532710
Do you have any custom iptables rules? Does the problem persist with the update kernel-2.6.31.6-145.fc12
I have been hit by the same problem. It seems that the masquerade rules from networkAddMasqueradingIptablesRules do not get run always. I see the masquerade rule from bridge - tun/tap to eth0 gets created only at boot time if ever. My KVM guests don't get to network anymore. See the reproducal with output in attachements, here's the magick to trigger the bug: sudo service iptables status - right after boot I can see the masquerade rule sudo service libvirtd stop sudo service iptables stop sudo service iptables start sudo service libvirtd start sudo service iptables status -> masquerade rule is gone I attach output for those commands along with the debug log of libvirtd and config for nat interface. about the versions: rpm -q kernel libvirt qemu-kvm kernel-2.6.31.6-145.fc12.x86_64 libvirt-0.7.1-15.fc12.x86_64 qemu-kvm-0.11.0-11.fc12.x86_64 $ uname -a Linux whipper.mobile.fp.nsn-rdnet.net 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux And I can reproduce this also on my f12 i386 laptop. Actually I can not get network to work on either machine.
Created attachment 375696 [details] output of reproducal
Created attachment 375697 [details] nat network config
Created attachment 375698 [details] libvirt config, only logs changed
Created attachment 375703 [details] libvirtd debug log
Created attachment 375704 [details] "ip a" before starting libvirtd
Created attachment 375706 [details] "ip a" after starting libvirtd
(In reply to comment #2) > Do you have any custom iptables rules? Does the problem persist with the update > kernel-2.6.31.6-145.fc12 Actually, I cannot reproduce it anymore (not sure when it started to work) bradford:~$ uname -a Linux bradford 2.6.31.6-145.fc12.x86_64 #1 SMP Sat Nov 21 15:57:45 EST 2009 x86_64 x86_64 x86_64 GNU/Linux bradford:~$
Ikka, does libvirt from the virt-preview repository help your situation here? http://fedoraproject.org/wiki/Virtualization_Preview_Repository
Created attachment 376008 [details] libvirtd debug log - same problem updated from preview repo, problem still exists. Dec 04 08:13:02 Updated: libvirt-client-0.7.4-1.fc12.x86_64 Dec 04 08:13:03 Updated: libvirt-python-0.7.4-1.fc12.x86_64 Dec 04 08:13:03 Updated: 2:qemu-img-0.11.0-12.fc12.x86_64 Dec 04 08:13:05 Updated: 2:qemu-common-0.11.0-12.fc12.x86_64 Dec 04 08:13:06 Updated: 2:qemu-system-x86-0.11.0-12.fc12.x86_64 Dec 04 08:13:06 Installed: zbar-0.10-1.fc12.x86_64 Dec 04 08:13:08 Updated: gstreamer-plugins-bad-0.10.17-1.fc12.x86_64 Dec 04 08:13:08 Updated: 2:qemu-kvm-0.11.0-12.fc12.x86_64 Dec 04 08:13:09 Updated: libvirt-0.7.4-1.fc12.x86_64 Dec 04 08:13:15 Updated: virt-manager-0.8.1-1.fc12.noarch One thing I need to ask, I changed the eth0 config so that it is not controllable from network manager. But this is the way it worked still in F11.
FYI, kernel updated, still exists: 2.6.31.6-162.fc12.x86_64, also I changed back the network manager to control eth0. No difference.
Ilkka, what does brctl showmacs <bridge> report for your system? I think there is a problem with qemu setting up bridges. It doesn't seem to matter if virtio is used or not.
$ sudo brctl show bridge name bridge id STP enabled interfaces pan0 8000.000000000000 no virbr0 8000.000000000000 yes virbr1 8000.000000000000 yes [itengval@whipper ~]$ sudo brctl showmacs virbr0 port no mac addr is local? ageing timer [itengval@whipper ~]$ sudo brctl showmacs virbr1 port no mac addr is local? ageing timer
BTW, I have downloaded the libvirt debuginfo and can hit it with a debugger if you just give a hint what to check.
libvirt has no sane was of integrating with iptables We previously tried using lokkit, but if the user had configured iptables manually (i.e. without lokkit) we'd end up clobbering their rules We simply need a way to say to iptables "we've added these rules, please load them when you restart" without overwriting the current configuration. We also need lokkit/system-config-firewall to not overwrite these rules when the user modifies the configuration The whole sorry saga is well documented in bug #227011 *** This bug has been marked as a duplicate of bug 227011 ***