hey erik, some questions after reading the interface document. (and i apologize in advance if some of the questions seem silly because i'm not a networking expert.)
- what will happen in zonecfg if the administrator sets ip-type=exclusive and then also configures networking parameters (address and netmask) for an interface? - how about the opposite scenario. a user configures a zone with without and an exclusive ip instance and sets up a bunch of network configuration inside that zone that would normally only apply to a zone with an exclusive ip instance. then the user boots the zone. does this result in any errors during boot? - you mention that no GLD or layer 2 changes will be supported inside zones. your example then mentions aggregations. i'm rusty on remembering all the layers so i'll just ask, are vlans and ip tunnels supported? - if an a zone is configured with an exclusive stack, will the /dev (and eventually /dev/net) devices associated with that stack also be automatically imported into that zone? if so, then how does this interact with non-native zones? (linux won't be expecting /dev/bge0 in it's namespace. linux uses network devices like /dev/net0.) - wrt to brandz, supporting an exclusive ip instance in an an lx branded zone will require the implementation of network configuration interfaces within the lx brand. it will probably involve translating a bunch of ioctls and socket operations. also, looking at a centos machine i see that it uses iptables instead of ipfilters. so all the iptables configuration system calls would need to be translated into their corresponding ipfilters commands. will this project do this work? if not it seems that users should be unable to create such a configuration in zonecfg. - have you considered providing a way to configure an ip instance assigned to a zone from the global zone? this would help with the situation above where the lx branded zone can't configure itself. another reason that i ask this is because currently you plan to make SMF startup scripts detect if a zone has an exclusive configuration or not. this becomes more complicated when it comes to modifying linux startup scripts. currently we disable most of them. if we take the same approach for non-native zones then we'll have to stop disabling the script and patch them to be stacked instances aware as well? - you mention that this will help us get NAT support for zones, then you also mention vSwitch. so i'm a little confused. after ip instances goes back will we be able to use the global zone as a NAT for local zones or not? (rfe 6338667) if so, could you provide an example configuration to illustrate how this might be setup using ip instances? if not, could you explain a little more what additional functionality is still required? - will dladm show-* subcommands work in a zone? will they display the interfaces associated with exclusive ip instances assigned to that zone? - clearview will allow interfaces to be renamed via dladm, so once an interface has been assigned exclusively to a zone will zone administrators be able to rename it via dladm? ed On Tue, Oct 10, 2006 at 02:23:35PM -0700, Erik Nordmark wrote: > > > -------- Original Message -------- > Subject: Reminder: Design review of IP Instances part of Crossbow] > Date: Tue, 10 Oct 2006 14:21:59 -0700 > From: Erik Nordmark <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > The deadline for design review comments is October 20th. > > Erik > > -------- Original Message -------- > Subject: [crossbow-discuss] Design review of IP Instances part of Crossbow > Date: Mon, 18 Sep 2006 16:53:02 -0700 > From: Erik Nordmark <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: networking-discuss@opensolaris.org, > "zones-discuss@opensolaris.org" <zones-discuss@opensolaris.org> > > > The IP instances (formerly known as "Stack Instances") piece of crossbow > is now ready for design review comments. > > There are two documents which describe the design > si-interfaces - a high-level design focusing on the problem the > project solves, and what the user-visible changes are > > si-design - the design of the code changes. Assumes the reader > has read si-interfaces already! > > These documents are available at > http://www.opensolaris.org/os/project/crossbow/Docs/pdf_filename_si-interfaces.pdf > and > http://www.opensolaris.org/os/project/crossbow/Docs/si-design.pdf > > Please send any comments to [EMAIL PROTECTED] > > Note that the design described in these documents differs slightly from > the bits that can be downloaded from opensolaris.org (e.g., "stacktype" > vs. "ip-type", and no IP addresses for the "net" resource in zonecfg). > Those changes will be available in the next version of bits we make > available on opensolaris.org. > > Erik > > _______________________________________________ > crossbow-discuss mailing list > [EMAIL PROTECTED] > http://opensolaris.org/mailman/listinfo/crossbow-discuss > _______________________________________________ > zones-discuss mailing list > zones-discuss@opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
