Description of problem: None of my 32 bit fullvirt guests detect any network card when they boot. (All paravirt guests work fine). Version-Release number of selected component (if applicable): virt-manager-0.5.0-1.fc8 libvirt-0.3.2-2.fc8 xen-3.1.0-5rich1.fc8 (Xen includes a patch to fix bug 279581). How reproducible: Always. Steps to Reproduce: 1.Boot 32 bit fullvirt guest 2.Go to the guest's console 3.Look at kernel messages and output of /sbin/ifconfig Actual results: No eth0 Expected results: Should be an eth0 Additional info: This is a real strange one because from the point of view of the dom0, the network seems to have been created just fine. For example, here is a 32 bit fullvirt guest with domid 2: vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:396 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) No indication of any error running the hotplug scripts: [2007-09-19 10:25:09 3112] DEBUG (DevController:558) hotplugStatusCallback /loca l/domain/0/backend/vif/2/0/hotplug-status. [2007-09-19 10:25:09 3112] DEBUG (DevController:558) hotplugStatusCallback /loca l/domain/0/backend/vif/2/0/hotplug-status. [2007-09-19 10:25:09 3112] DEBUG (DevController:572) hotplugStatusCallback 1. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices usb. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices vbd. [2007-09-19 10:25:09 3112] DEBUG (DevController:153) Waiting for 768. [2007-09-19 10:25:09 3112] DEBUG (DevController:558) hotplugStatusCallback /loca l/domain/0/backend/vbd/2/768/hotplug-status. [2007-09-19 10:25:09 3112] DEBUG (DevController:558) hotplugStatusCallback /loca l/domain/0/backend/vbd/2/768/hotplug-status. [2007-09-19 10:25:09 3112] DEBUG (DevController:572) hotplugStatusCallback 1. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices irq. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices vkbd. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices vfb. [2007-09-19 10:25:09 3112] DEBUG (vfbif:99) skip waiting for HVM vfb [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices console . [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices pci. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices ioports . [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices tap. [2007-09-19 10:25:09 3112] DEBUG (DevController:148) Waiting for devices vtpm. No obvious indication of error in the other log files either.
# /usr/sbin/brctl show bridge name bridge id STP enabled interfaces eth0 8000.00e081740228 no peth0 vif1.0 vif2.0 vif3.0 vif4.0 vif5.0 virbr0 8000.000000000000 no I'm using Xen networking. Some of those other vifX.0 devices belong to other working paravirt guests.
Created attachment 199491 [details] xm list --long Output of xm list --long. The domains debian32fv (domid 9) and gentoo32fv (domid 4) are the afflicted ones.
Created attachment 199511 [details] xend.log This is a section from xend.log which shows the domain debian32fv being shut down and then restarted.
These are the command lines of the qemu-dm processes. Paravirt (working) domains: /usr/lib64/xen/bin/qemu-dm -M xenpv -d 1 -domain-name fc6_0 -vnc 127.0.0.1:2 /usr/lib64/xen/bin/qemu-dm -M xenpv -d 3 -domain-name fc6_1 -vnc 127.0.0.1:3 /usr/lib64/xen/bin/qemu-dm -M xenpv -d 5 -domain-name f764pv -vnc 127.0.0.1:0 -vncunused Fullvirt (non-working) domains: /usr/lib64/xen/bin/qemu-dm -d 4 -vcpus 4 -boot c -serial pty -acpi -usb -domain-name gentoo32fv -vnc 127.0.0.1:0 -vncunused /usr/lib64/xen/bin/qemu-dm -d 9 -vcpus 1 -boot c -acpi -usb -domain-name debian32fv -vnc 127.0.0.1:0 -vncunused
I edited: /var/lib/xend/domains/<uuid>/config.sxp and changed: (device (vif (bridge eth0) (uuid eff1d1f0-2a91-e370-9afc-9f584db28948) (script vif-bridge) (mac 00:16:3e:36:61:80) (type ioemu) ^^^^^ was netfront, changed to ioemu (backend 0) ) ) which fixes the network.
Created attachment 199941 [details] Don't clobber 'type' field There are 3 possible values for the 'type' field in XenD vif devices - netfront - paravirt drivers - ioemu - QEMU emulation - None - paravirt & QEMU libvirt creates HVM guests with 'None' for type, so that they can easily be configured to use paravirt drivers post-install. This works initially when starting the guest. But at the time you start the first guest, XenD re-writes its config file out to disk, and in doing so converts 'None' into 'netfront'. This is clearly bogus - it should not change it. The attached patch removes the code which clobbers it.
With the patch in comment 6 it appears that a guest which starts with no (type ..) in its vif device gets rewritten as (type ioemu). I don't think that is what you intended, but at least it doesn't break the vif configuration as before. (I will also note for myself that xend does the rewriting just after the domain starts up).
Very strange, I just retested it and now it doesn't add (type ioemu) but leaves it with no (type ...). Not sure what was going on before.
Built into rawhide * Wed Sep 19 2007 Daniel P. Berrange <berrange> - 3.1.0-6.fc8 - Don't clobber the VIF type attribute in FV guests (rhbz #296061)
Thanks Daniel! This bug's been biting me lately on F7/x86_64 with a FC6/i386 guest. Thought I was losing my mind. :-)