On Tue, Oct 24, 2006 at 01:41:32PM -0700, Erik Nordmark wrote:
Edward Pilatowicz wrote:
- 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?
The same thing would happen as if you today did
echo 10.1.2.3 /etc/hostname.bge0
echo 10.1.1.1 /etc/defaultrouter
reboot
in a zone. This is silently ignored.
(Or, as I've seen some scripts do, put IP configuration into
$ZROOT/etc/sysidcfg; also silently ignored today.)
The way the smf methods are structured in S10 they skip the IP level
configuration. The only change introduced by IP instances is the
predicate used to test whether to skip.
For example, net-physical has these udiffs:
-smf_is_globalzone || exit $SMF_EXIT_OK
+smf_configure_ip || exit $SMF_EXIT_OK
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.
- 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
Aggregations can be configured using dladm in the global zone, and then
the aggrN datalink names can be given to exclusive-IP zones.
VLANs will be supported for GLDv3 devices. (We can't get e.g. the ce
driver to have a separate /dev/ceN entry per instance and per VLAN.)
IP tunnels work today, but they are not devices but a funny construct
using a tunneling streams module.
The clearview tunnel project will turn tunnels into GLDv3 links, and
they are aware of the implications of IP instances. (I use separate IP
Instances on the laptop punched into separate punchin points just for fun.)
good to know.
- 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.)
Yes.
The BrandZ merge was done recently, hence is not covered in the design
document.
One part is getting things like /dev/ip show up in the exclusive-IP
zones, and not in the shared-IP zones.
This is done by extensions to platform.xml in the form of
+ !-- Devices to create in exclusive IP zone only --
+ device match=ip iptype=exclusive /
The other part is e.g. /dev/bge33000, which is done with
di_prof_add_dev() as part of the vplat bringup.
Should we just limit that to certain brands for the time being? Or we
can disable the ability to setup exclusive-IP with certain brands.
Suggestions?
nit: in zonecfg it's ip-type were as above there's no dash.
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?
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 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.)
- 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.
