All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ewan Mellor <ewan@xensource.com>
To: Molle Bestefich <molle.bestefich@gmail.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: No network device problem in -testing
Date: Mon, 6 Feb 2006 09:50:48 -0800	[thread overview]
Message-ID: <20060206175048.GC3180@localhost.localdomain> (raw)
In-Reply-To: <62b0912f0602060454o5d8b6e64l977143baa91c569f@mail.gmail.com>

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.

  reply	other threads:[~2006-02-06 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03  5:43 No network device problem in -testing NAHieu
2006-02-03 11:50 ` Christopher Clark
2006-02-03 13:51   ` NAHieu
2006-02-03 22:00     ` Ewan Mellor
2006-02-06 12:54       ` Molle Bestefich
2006-02-06 17:50         ` Ewan Mellor [this message]
2006-02-06 17:58           ` Molle Bestefich
2006-02-06 18:20             ` Ewan Mellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060206175048.GC3180@localhost.localdomain \
    --to=ewan@xensource.com \
    --cc=molle.bestefich@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.