Edward Pilatowicz wrote:

[You brought up an issue with /etc/hostname.* etc being ignored when a shared-IP zone is booted.]


perhaps some kind of warning message should be generated in this
scenario instead?

something like:
        Ignoring zone network configuration specified: /etc/hostname.bge0
        Current network configuration is dictated by the global zone.
        To use the network configuration specified within this zone it
        must have an exclusive-IP instance allocated to it by the global
        zone.

This is an issue in S10 at two levels:
1. The /etc/hostname.<ifname> and related files are ignored when a zone is booted. 2. Any IP configuration information in $ZROOT/etc/sysidcfg is ignored by sysidtool

It might be that IP Instances makes this more of an issue, although I'm not certain it will, but in any case the issue is with the original shared-IP stack. (Of course, this is far from the only issue with the shared-IP stack.)

I don't know what the best way is to proceed on this. One way is to just file CRs on the share-IP stack (smf scripts and sysidtool). But medium term it might make sense to instead spend our time on aggressively moving away from the shared-IP stack (and maybe even ripping out that code in our lifetimes) by making sure that the exclusive-IP stack can satisfy the same needs as the shared-IP stack. IP Instances is a bey building block for this, but we also need some additional pieces (some of which are under way) - vnic support to get the same type of sharing of the "wire" as with the shared-IP stack - security (perhaps in the form of GLD-level filtering) to contain exclusive-IP zones towards the network (prevent ARP spoofing, redirect spoofing, RIP spoofing, etc) since ARP spoofing is prevented for shared-IP zones - think about scalable/centralizable configuration of IP parameters for zones. I think the answer is related to DHCP; perhaps having easy configurations where the global zone can be a DHCP server (and NAT?) for the non-global zones on the same machine. We have the building blocks for this, but we need to better understand the identity of a zone as it relates to DHCP before we proceed.

So long answer to a short question. Adding warning messages doesn't seem to help us get to where we need to go.


nit: in zonecfg it's "ip-type" were as above there's no dash.

I realized that. We'll make them consistent.

i looked into it a bit more and as it turns out in linux network devices
don't actually have any /dev entries.  but we can't simply tell non-native
brands not to map exclusive-IP network devices because this could break
other zones.  (think sn1, belinix, nexenta, etc.)

so here's a question.  in an exclusive-IP zone, do we have to have
network /dev entries in to be able to configure network interfaces?
or can all the necessary configuration be done via socket operations?

No.
sockets are implemented using devices (see /etc/sock2path), and ifconfig plumb is implemented using DLPI devices.

i guess if we need to have access to the device nodes then the easiest
thing to do will be to simply map them in and hopefully linux apps will
ignore them.  if linux apps don't ignore them then we'll have to
create /dev and /native/dev as seperate namespaces.  (currently
they are the same.)

If there is a /dev/bge1 in a lx zone, presumably it doesn't upset anything. Or are there applications which try to do something to everything the find in /dev?

if we don't need/want the nodes then we'll have to add some kind of
brand callback such that the lx brand can indicate this when you
attempt to add in the interfaces.

lastly, we'll probably have to add some kind or mechanism that will
allow a brand to iterate over all the network devices which have been
exclusively allocated to it.  (so when the linux brand does
"ifconfig eth0 plumb" we can look at all the available interfaces and
plumb one up.)

We have the system calls to do this. They are used by install which does an 'ifconfig -a plumb'. ifconfig uses the zone_get_iflist() call.
I think that would be sufficient to build something for lx.
But I don't understand how lx handles multiple Ethernet interfaces; how it decides which one is eth0 and which one is eth1.

We can certainly disable IP instances with non-native brands in zonecfg.
But I assume we'd want to support sn-1, thus "non-native" might not be
the right test.


then this seems like something that should be controlled via
the brand configuration verification callback.  currently the lx
brand already looks for unsupported zonecfg options and reports
errors if there are any.  it seems like it should be enhanced to
detect an exclusive-IP config and not allow it.  (see the verify
subcommand to lx_support.c.)

I'll take a look at the implementation.


hm.  i spend most my time thinking about the NAT case so i hadn't
considered dhcp.  i guess that will require running the dhcp daemon
inside the linux zone which will require supporting whatever
daemon/kernel interfaces they use.  (probably socket operations.)
ugh.

But isn't it just a wad of ioctls?


currently we just disable them by moving them aside.

i guess we could patch them up by adding a line to the top like:
        /native/usr/lib/brand/lx/lx_configure_ip || exit 0

where lx_configure_ip is a script that runs a native binary and
tells us if we're configured with an exclusive-IP stack or not.

That would be more flexible I think.

    Erik
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to