Re: No network device problem in -testing

[Ewan Mellor <ewan@xensource.com>]

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.