Re: [Xen-devel] VLAN script

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Jul 07, 2006 at 06:15:54PM +0200, Molle Bestefich wrote:

> Hello
> 
> My domU's runs in each their VLAN.
> I'm revising my vif-vlan script.
> 
> I'd like to switch away from the ip="xyz", netmask="abc",
> gateway="def" syntax in /etc/xen/domU-config and
> instead use the new vif=['ip=1.2.3.4,etc'] syntax.
> 
> I'm stumbling into a few shortcomings.
> 
> A much harder problem to tackle is that there's also no apparent way to
> read out the ip=abc value when inside the domU - there's nothing relevant
> in /proc/cmdline, under /proc/xen, or under /sys/devices/xen/vif-*.
> 
> So how do I read out the values on the vif=[...] line from within each domU?

The ip=, netmask=, gateway= parameters are munged together to make the kernel
command line.  The vif=['ip='] is different -- that parameter is used inside
domain 0 to set up networking.

The problem with using the kernel command line is that you can only set the
IP parameters for the first interface in this way.  That's why we're trying to
move away from that -- you can only configure one interface like this.  That
doesn't make it wrong to do so, if it suits you better.

The vif parameters, as you've found out, are only available to domain 0 (in
the hotplug scripts).  The best way to get those parameters into the guest, if
that's what you need to do, is to run a DHCP server inside domain 0.  That
way, you can set up the guest's networking, using your distro's normal network
scripts, setting it up for DHCP, and then intercept those DHCP requests in
domain 0.  The tools/examples/vif-nat script in the Xen tree does exactly
that.

> There's no netmask=abc, no gateway=abc, no broadcast=abc when using
> the new syntax.  I'll have to hardcode those depending on the IP.  So
> be it.

I think that the vif-nat scripts use ip=1.2.3.4/24 rather than
netmask/broadcast, and use the address of the interface in dom0 for the
gateway.  If you need more flexibility than this, feel free to submit a patch
-- it sounds reasonable that the flexibility might be needed.

Ewan.

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