This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 296061 - No network in 32 bit fullvirt guests
No network in 32 bit fullvirt guests
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
8
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-19 06:05 EDT by Richard W.M. Jones
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-19 17:22:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
xm list --long (10.90 KB, text/plain)
2007-09-19 09:42 EDT, Richard W.M. Jones
no flags Details
xend.log (9.92 KB, text/plain)
2007-09-19 09:43 EDT, Richard W.M. Jones
no flags Details
Don't clobber 'type' field (877 bytes, patch)
2007-09-19 14:28 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Richard W.M. Jones 2007-09-19 06:05:58 EDT
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.
Comment 1 Richard W.M. Jones 2007-09-19 06:14:25 EDT
# /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.
Comment 2 Richard W.M. Jones 2007-09-19 09:42:52 EDT
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.
Comment 3 Richard W.M. Jones 2007-09-19 09:43:47 EDT
Created attachment 199511 [details]
xend.log

This is a section from xend.log which shows the
domain debian32fv being shut down and then restarted.
Comment 4 Richard W.M. Jones 2007-09-19 11:49:16 EDT
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
Comment 5 Richard W.M. Jones 2007-09-19 12:05:26 EDT
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.
Comment 6 Daniel Berrange 2007-09-19 14:28:41 EDT
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.
Comment 7 Richard W.M. Jones 2007-09-19 14:40:31 EDT
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).
Comment 8 Richard W.M. Jones 2007-09-19 16:02:06 EDT
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.
Comment 9 Daniel Berrange 2007-09-19 17:22:30 EDT
Built into rawhide

* Wed Sep 19 2007 Daniel P. Berrange <berrange@redhat.com> - 3.1.0-6.fc8
- Don't clobber the VIF type attribute in FV guests (rhbz #296061)

Comment 10 Jima 2007-10-04 15:29:12 EDT
Thanks Daniel!  This bug's been biting me lately on F7/x86_64 with a FC6/i386
guest.  Thought I was losing my mind. :-)

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