WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] dom0 networking disabled

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] dom0 networking disabled
From: jez <jez@xxxxxxxxxx>
Date: Sat, 17 Mar 2007 21:25:50 +0100
Delivery-date: Sat, 17 Mar 2007 12:21:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <BAY120-F7D06AA2E2197FBBD0141FD1700@xxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: xen-users@xxxxxxxxxxxxxxxxxxx
References: <20070317163732.GA23801@xxxxxxxxxxxxxxxxxx> <BAY120-F7D06AA2E2197FBBD0141FD1700@xxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
On Sat, Mar 17, 2007 at 02:09:24PM -0400, Greg Saunders wrote:
>
> >If eth0 is a PCI card, then just remove the allow-hotplug stuff. If
> >you've got a hotplug PCI system, you can always work out if/how to put
> >the allow-hotplug back in later.
> 
> To be honest, I don't know that eth0 is a PCI card, but I suspect it is.  I 
> do know that the computer is a laptop (Dell Inspiron 6400 with Core 2 Duo, 
> much like the one reviewed at 
> http://www.reghardware.co.uk/2006/12/06/review_dell_inspiron_6400/), and I 
> do know that eth0 is not a PCMCIA card - the computer doesn't even have a 
> PCMCIA slot.
> 

That sounds about right. I've got an  inspiron here, there will always be
an onboard nic on those things. I did a quick search on the oui part of
the MAC addreess below 00:15:C5 and I it appears to be registered to
Dell. 

> >
> >To summarize:
> > . Explain what eth0 is and what eth1 is (wireless, PCI, etc)
> 
> I am under impression that eth0 is my "not-wireless" network interface 
> card; not to be confused with wlan0, my wireless network interface card, 
> mention of which I had completely removed from /etc/network/interfaces.
> 
> As for what eth1 is - I hadn't noticed it before and I had assumed it was 
> something to do with the Xen installation.  Given that you're asking, 
> though, I wonder now if it's something to do with another foray I've 
> recently made into virtualisation: I have installed the Qemu and have had a 
> virtual machine running on that.  (That experiment is over now, though, and 
> I was going to remove Qemu.)
> 

I'd be very surprised if it was related to qemu. I'm messing around with
qemu and kvm at the moment and I don't see anything like that. Qemu's
user mode networking stack would not be allowed to create interfaces
like that on the host, and if your using tuntap interfaces, these 
will look like normal ethernet interfaces. Anyway, the good news is that 
eth1 is there - and still strange looking - when you run etch with a 
non-xen kernel. It's probably not something we need to worry about here.

> > . Try again using the timeout settings in interfaces.
> 
> Done.  No difference.  After making /etc/network/interfaces look like this 
> (note change from "xenbr0" to "xbr0" and lack of "allow-hotplug") :
> 
> auto lo
> iface lo inet loopback
> 
> iface xbr0 inet dhcp
>    bridge_fd 0
>    bridge_maxwait 0
>    bridge_helo 0
>    bridge_ports eth0
> 
> auto xbr0
>

That's a pity!

<snip/>
> And ifconfig -a returns
> 
> eth1      Link encap:UNSPEC  HWaddr 
> 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00
>          BROADCAST MULTICAST  MTU:1500  Metric:1
>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
<snip/>
> 
> For comparison, it might tell you something to see that when I run my 
> original Etch kernel and make my /etc/network/interfaces looks this:
> 
<snip/>
> So that ifconfig -a returns
> 
> eth0      Link encap:Ethernet  HWaddr 00:15:C5:C9:F6:E3
>          inet addr:192.168.0.102  Bcast:192.168.0.255  Mask:255.255.255.0
>          inet6 addr: fe80::215:c5ff:fec9:f6e3/64 Scope:Link
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:72 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:18210 (17.7 KiB)  TX bytes:5002 (4.8 KiB)
>          Interrupt:58
> 
> eth1      Link encap:UNSPEC  HWaddr 
> 32-4F-C0-00-18-E2-1D-61-00-00-00-00-00-00-00-00
>          BROADCAST MULTICAST  MTU:1500  Metric:1
>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 

Thanks Greg, this comparison was very helpful. The problem here is
clearly that eth0 does not exist when you boot into xen. It's not a
problem with bridging, or anything like that. If you were to use an
empty /etc/network/interfaces file and you were to prevent xend from
running at startup:

    # find /etc/rc*.d -name '*xend'
    /etc/rc0.d/K21xend
    /etc/rc1.d/K21xend
    /etc/rc2.d/S20xend
    /etc/rc3.d/S20xend
    /etc/rc4.d/S20xend
    /etc/rc5.d/S20xend
    /etc/rc6.d/K21xend
    # find /etc/rc*.d -name '*xend' | rename s/S20/K80/
    # find /etc/rc*.d -name '*xend'
    /etc/rc0.d/K21xend
    /etc/rc1.d/K21xend
    /etc/rc2.d/K80xend
    /etc/rc3.d/K80xend
    /etc/rc4.d/K80xend
    /etc/rc5.d/K80xend
    /etc/rc6.d/K21xend

And you rebooted. You would still not see eth0. You can try this if you
want (but remember to do a 'rename s/K80/S20/' afterwards).

If you can get eth0 to exist under xen then all that bridging stuff will
fall into place. So how do you do that? Well, I recommend you try the
following. 

Boot into etch with the none-xen kernel running. Now collect all the
information you can about you network card:

   $ udevinfo -ap /sys/class/net/eth0/ > eth0.notes

You are particularly interested in what driver is running for eth0:

   $ udevinfo -ap /sys/class/net/eth0/ | grep -i driver
   DRIVER=="b44"
   DRIVER==""
   DRIVER==""


Also run 'lspci' and collect the information you receive in case you
need to search google.

Then boot back into xen and try to load the driver manually.

   $ modprobe b44

Check the output of udevinfo here as well, and check log files and just
generally try to work out what has happened to eth0.

> 
> > . Also, do you have physical access to this machine or is it in a
> >   remote hosting center? If you've got physical access then we can step
> >   through creating a bridge manually - not something you really want to
> >   try when logged in remotely :-)
> 
> I do have physical access to the machine.
>

Good, but unfortunatly I can't step you through the manual creation 
of the bridge if eth0 does not exist. And if it did exist the bridge 
stuff would probably be working just fine anyway. Damn!

jez

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users