No network device problem in -testing

No network device problem in -testing

[NAHieu]

Hi,

I am running the latest Xen 3.0-testing tree, and have a trouble: my
virtual machine cannot find the network device. Network in Dom0 is OK,
but in DomU, "ifconfig -a" only shows the local interface. But here in
the dmesg content, I found these line:

^^^
...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Xen virtual console successfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
NET: Registered protocol family 2
Registering block device major 3
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
^^^

The above messages convice me that the network was succesfully
initialized, but why I dont see the "eth0" as normally? I am kinda
stuck now. Anybody knows how to fix the problem, or tell me how to
debug it myself?

I use the latest -testing tree, as below:
# hg tip
changeset:   8738:eff96462fde8
tag:         tip
user:        kaf24@firebug.cl.cam.ac.uk
date:        Tue Jan 31 12:04:12 2006 +0100
summary:     Remove dummy definitions of __gpfn_to_mfn/__mfn_to_gpfn.


And here is my configuration file:
^^^
kernel = "/boot/vmlinuz-2.6-xenU"
memory = 200
name = "ubuntu"
disk = ['file:/home/hieu/xen/rootfs.swap,hda1,w',
'file:/home/hieu/xen/rootfs.ubuntu,hda2,w']
root = "/dev/hda2 ro"
^^^

Many thanks.
Hieu

Re: No network device problem in -testing

[Christopher Clark]

[-- Attachment #1.1: Type: text/plain, Size: 1964 bytes --]

try adding this to your config:

vif = [ '' ]


Christopher

On 2/3/06, NAHieu <nahieu@gmail.com> wrote:
>
> Hi,
>
> I am running the latest Xen 3.0-testing tree, and have a trouble: my
> virtual machine cannot find the network device. Network in Dom0 is OK,
> but in DomU, "ifconfig -a" only shows the local interface. But here in
> the dmesg content, I found these line:
>
> ^^^
> ...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> Xen virtual console successfully installed as tty1
> Event-channel device installed.
> netfront: Initialising virtual ethernet driver.
> NET: Registered protocol family 2
> Registering block device major 3
> IP: routing cache hash table of 2048 buckets, 16Kbytes
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> ^^^
>
> The above messages convice me that the network was succesfully
> initialized, but why I dont see the "eth0" as normally? I am kinda
> stuck now. Anybody knows how to fix the problem, or tell me how to
> debug it myself?
>
> I use the latest -testing tree, as below:
> # hg tip
> changeset:   8738:eff96462fde8
> tag:         tip
> user:        kaf24@firebug.cl.cam.ac.uk
> date:        Tue Jan 31 12:04:12 2006 +0100
> summary:     Remove dummy definitions of __gpfn_to_mfn/__mfn_to_gpfn.
>
>
> And here is my configuration file:
> ^^^
> kernel = "/boot/vmlinuz-2.6-xenU"
> memory = 200
> name = "ubuntu"
> disk = ['file:/home/hieu/xen/rootfs.swap,hda1,w',
> 'file:/home/hieu/xen/rootfs.ubuntu,hda2,w']
> root = "/dev/hda2 ro"
> ^^^
>
> Many thanks.
> Hieu
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2616 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: No network device problem in -testing

[NAHieu]

On 2/3/06, Christopher Clark <christopher.clark@cl.cam.ac.uk> wrote:
> try adding this to your config:
>
> vif = [ '' ]
>

Thanks, Christopher. That works, but it surprises me: it seems that
previously I didnt need to specify this parameter. Something changes
recently in xend?

Probably it is better to leave this parameter "on" by default, so the
virtual domain always has NIC, by default.

Hieu


>
> Christopher
>
>
> On 2/3/06, NAHieu <nahieu@gmail.com> wrote:
> >
> > Hi,
> >
> > I am running the latest Xen 3.0-testing tree, and have a trouble: my
> > virtual machine cannot find the network device. Network in Dom0 is OK,
> > but in DomU, "ifconfig -a" only shows the local interface. But here in
> > the dmesg content, I found these line:
> >
> > ^^^
> > ...
> > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> > Xen virtual console successfully installed as tty1
> > Event-channel device installed.
> > netfront: Initialising virtual ethernet driver.
> > NET: Registered protocol family 2
> > Registering block device major 3
> > IP: routing cache hash table of 2048 buckets, 16Kbytes
> > TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> > TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> > TCP: Hash tables configured (established 8192 bind 8192)
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > ^^^
> >
> > The above messages convice me that the network was succesfully
> > initialized, but why I dont see the "eth0" as normally? I am kinda
> > stuck now. Anybody knows how to fix the problem, or tell me how to
> > debug it myself?
> >
> > I use the latest -testing tree, as below:
> > # hg tip
> > changeset:   8738:eff96462fde8
> > tag:         tip
> > user:        kaf24@firebug.cl.cam.ac.uk
> > date:        Tue Jan 31 12:04:12 2006 +0100
> > summary:     Remove dummy definitions of __gpfn_to_mfn/__mfn_to_gpfn.
> >
> >
> > And here is my configuration file:
> > ^^^
> > kernel = "/boot/vmlinuz-2.6-xenU"
> > memory = 200
> > name = "ubuntu"
> > disk = ['file:/home/hieu/xen/rootfs.swap,hda1,w',
> > 'file:/home/hieu/xen/rootfs.ubuntu,hda2,w']
> > root = "/dev/hda2 ro"
> > ^^^
> >
> > Many thanks.
> > Hieu
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>
>

Re: No network device problem in -testing

[Ewan Mellor]

On Fri, Feb 03, 2006 at 10:51:32PM +0900, NAHieu wrote:

> On 2/3/06, Christopher Clark <christopher.clark@cl.cam.ac.uk> wrote:
> > try adding this to your config:
> >
> > vif = [ '' ]
> >
> 
> Thanks, Christopher. That works, but it surprises me: it seems that
> previously I didnt need to specify this parameter. Something changes
> recently in xend?
> 
> Probably it is better to leave this parameter "on" by default, so the
> virtual domain always has NIC, by default.

This change was made on Dec 13.  Previously, the nics= option and the
vif option interacted in unexpected ways (nics=0 did not necessarily
mean 0 vifs, for example).  This way vif and vbd configuration behaves
the same, and there are no concealed defaults to confuse people.

Ewan.

Re: No network device problem in -testing

[Molle Bestefich]

Ewan Mellor wrote:
> This change was made on Dec 13.  Previously, the nics= option and the
> vif option interacted in unexpected ways (nics=0 did not necessarily
> mean 0 vifs, for example).  This way vif and vbd configuration behaves
> the same, and there are no concealed defaults to confuse people.

It seems that the options:
 ip="blah"
 netmask="blah"
 gateway="blah"

still work, but now they can also be specified within the vif=['']
list as vif=['ip=blah, etc'].

Is this a bug, or is there just supposed to be two ways to apply an IP
address etc. now?

Re: No network device problem in -testing

[Ewan Mellor]

On Mon, Feb 06, 2006 at 01:54:20PM +0100, Molle Bestefich wrote:

> Ewan Mellor wrote:
> > This change was made on Dec 13.  Previously, the nics= option and the
> > vif option interacted in unexpected ways (nics=0 did not necessarily
> > mean 0 vifs, for example).  This way vif and vbd configuration behaves
> > the same, and there are no concealed defaults to confuse people.
> 
> It seems that the options:
>  ip="blah"
>  netmask="blah"
>  gateway="blah"
> 
> still work, but now they can also be specified within the vif=['']
> list as vif=['ip=blah, etc'].
> 
> Is this a bug, or is there just supposed to be two ways to apply an IP
> address etc. now?

Those ip, netmask, and gateway parameters specify options for the Linux
kernel command line.  With these, you can persuade the guest to use the
specified details, without having the guest preconfigured, but in
general it's not a good way to work -- you can't specify addresses for
multiple interfaces this way, in particular.  The vif options specify
the details given to the hotplug scripts when the devices come up.
These details are used to configure DHCP, routing, or whatever inside
dom 0 -- they don't necessarily affect the guest.  You still need the
guest to configure itself appropriately.

The best thing to do is probably to use vif=, have a DHCP server inside
dom0 (dhcp=yes in a couple of places) and then preconfigure the guest to
expect their addresses via DHCP.

The kernel command line options are probably most useful for developers, who
just want to get things up and running quickly without configuring their guest
properly.

Ewan.

Re: No network device problem in -testing

[Molle Bestefich]

Ewan Mellor wrote:
> Those ip, netmask, and gateway parameters specify options for the Linux
> kernel command line.  With these, you can persuade the guest to use the
> specified details, without having the guest preconfigured, but in
> general it's not a good way to work -- you can't specify addresses for
> multiple interfaces this way, in particular.  The vif options specify
> the details given to the hotplug scripts when the devices come up.
> These details are used to configure DHCP, routing, or whatever inside
> dom 0 -- they don't necessarily affect the guest.  You still need the
> guest to configure itself appropriately.
>
> The best thing to do is probably to use vif=, have a DHCP server inside
> dom0 (dhcp=yes in a couple of places) and then preconfigure the guest to
> expect their addresses via DHCP.

Ah.  Super, thanks.  The above belongs in the Wiki if you ask me.
If it's ok with you, I'll add it when I get some free time.

> The kernel command line options are probably most useful for developers, who
> just want to get things up and running quickly without configuring their guest
> properly.

Personally I use it to assign domU IP addresses.
But then again, that's because I've never stumbled upon any
well-written documentation that told me not to - I just googled and
found something named 'ip=' which looked right, so I used that.

If you feel like doing more newbie tutoring (sorry....), another question:
It feels reasonable that Xen moves the physical ethernet interface to
peth0 and creates a virtual eth0 interface in dom0 - after all, dom0
is a virtual machine, it should have virtual interfaces that I can
play/do funky things with.

But:
 1.) Why doesn't Xen do the same for eth1 and upwards?
 2.) Why doesn't Xen do this when using the non-bridged setup?

Seems completely illogical to me.  Plus the incoherency makes it
really hard to write good documentation.

Re: No network device problem in -testing

[Ewan Mellor]

On Mon, Feb 06, 2006 at 06:58:56PM +0100, Molle Bestefich wrote:

> Ewan Mellor wrote:
> > Those ip, netmask, and gateway parameters specify options for the Linux
> > kernel command line.  With these, you can persuade the guest to use the
> > specified details, without having the guest preconfigured, but in
> > general it's not a good way to work -- you can't specify addresses for
> > multiple interfaces this way, in particular.  The vif options specify
> > the details given to the hotplug scripts when the devices come up.
> > These details are used to configure DHCP, routing, or whatever inside
> > dom 0 -- they don't necessarily affect the guest.  You still need the
> > guest to configure itself appropriately.
> >
> > The best thing to do is probably to use vif=, have a DHCP server inside
> > dom0 (dhcp=yes in a couple of places) and then preconfigure the guest to
> > expect their addresses via DHCP.
> 
> Ah.  Super, thanks.  The above belongs in the Wiki if you ask me.
> If it's ok with you, I'll add it when I get some free time.

Go for it.  We do have a manual as well -- if you added it to that too,
then we'd certainly appreciate it (everyone knows that developers don't
like to write docs ;-)

> If you feel like doing more newbie tutoring (sorry....), another question:
> It feels reasonable that Xen moves the physical ethernet interface to
> peth0 and creates a virtual eth0 interface in dom0 - after all, dom0
> is a virtual machine, it should have virtual interfaces that I can
> play/do funky things with.
> 
> But:
>  1.) Why doesn't Xen do the same for eth1 and upwards?

Have you tried running the network-bridge script with vifnum=1?  If that
doesn't do it, then that's a bug.  If you want to permanently configure
your system so that both eth0 and eth1 are bridged, then see the workaround
at the end of bug #332.

>  2.) Why doesn't Xen do this when using the non-bridged setup?
> 
> Seems completely illogical to me.  Plus the incoherency makes it
> really hard to write good documentation.

I'm not sure, but I guess for performance.  You don't want your packets
to be taking an extra hop through the kernel if you can avoid it.

Ewan.