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/
Home Products Support Community News


Re: [Xen-devel] No network device problem in -testing

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] No network device problem in -testing
From: Molle Bestefich <molle.bestefich@xxxxxxxxx>
Date: Mon, 6 Feb 2006 18:58:56 +0100
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Feb 2006 18:10:46 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ilphSgYRsaNEDf9tWCyLgdxw1coyj83c2dFvE+JC+6+/9ZXM1fSQdemOp/MYU8aCaWgAdnrootOmcWR9akBtY3XTOy3lU1zgz/47TB8Hv0Vnw+AelvM2B5odRP9KDW9zO6m580wx2Hr1BqZfm6eV7Sc7TvvhCwA7wm1OWGOQUKQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060206175048.GC3180@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d7aca950602022143m1f9b9e75y178228dcac53fbc7@xxxxxxxxxxxxxx> <eab087540602030350n4f4ceec0s1f488b4684ad8e76@xxxxxxxxxxxxxx> <5d7aca950602030551w3c2184afvbc90c0a8cfc289c7@xxxxxxxxxxxxxx> <20060203220011.GB3075@xxxxxxxxxxxxxxxxxxxxx> <62b0912f0602060454o5d8b6e64l977143baa91c569f@xxxxxxxxxxxxxx> <20060206175048.GC3180@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

 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.

Xen-devel mailing list