Erik Nordmark writes:
> James Carlson wrote:
> > Erik Nordmark writes:
> >> But the key thing to me is the consistency between where things can be
> >> observed and where they can be modified.
> > We already have RFEs filed against other utilities because they don't
> > show non-global zone activity (see, for example, CR 6369726). I think
> > the lines here are pretty blurry.
> > In some usage models, the global zone administrator "owns"
> > everything. Even if he can't directly control things from the global
> > zone (and must log into the non-global zone to turn services on and
> > off), he wants to see a view of the system that includes everything.
> Do you have an example of that?
I'm not sure I understand the question. Is CR 6369726 a suitable
example? If not, then what are you asking?
> > Given that there are some networking things that must be administered
> > in the global zone alone even when exclusive stack instances are in
> > use, it doesn't seem unreasonable to me to say that the administrator
> > of the global zone should be able to list related information without
> > entering the non-global zone.
> ifconfig displays network interface names used by IP and IP addresses
> and related information.
> zoneadm list -l displays the datalink names assigned to an exclusive-IP
> Are you saying that the datalink names are insufficient for the
> administration the global zone would need to do for the exlusive-IP zone?
Yes, if the administrator of the global zone needs to know what
networks are involved in order to make a change.
For example, if the administrator of the global zone has Firewall-1
installed, he's going to need to configure IP details in the global
zone. I don't see how he can do that if he doesn't have access to
> There are things external to the system (such a firewalls) that might
> need to be configured with IP addresses, and I can see the same thing
> being true for the global zone (e.g. the global zone might run a
> firewall in front of the non-global zone down the road).
> But I don't see that particular type of configuration as an argument for
> being able to do ifconfig -a in the global zone and see the non-global
> information, any more than there being a requirement for a router
> outside the system being able to do ifconfig -a and see the IP
> configuration of other systems on the network.
It depends on the administrator's mental model for the system.
Seeing IP addresses for other systems on the same network would not be
a rational thing to expect out of ifconfig. Seeing IP addresses
configured inside the very same box on the very same running kernel,
though, may well be a rational expectation.
> Thus I am trying to understand what the architectural or design
> principle is that makes you conclude that showing IP address
> configuration for exclusive-IP zones in ifconfig in the global zone.
The design principle is that we have different tools for different
tasks, and those tools are expected to give you a coherent view of the
system. I do expect to use the resource control commands to control
resources that I'm going to delegate to zones. I do expect to be able
to view mount points and devices in use on the local system using
tools designed for those purposes, regardless of what zone is
I don't expect to use one tool to list datalinks and IP interfaces
when they're in my local zone (dladm, ifconfig) and a completely
different tool when they're in the same system but in some other
zone. That's not the model we had been using, which is why ifconfig
currently does show interfaces in non-global zones, even though you
can't "use" those interfaces in the global zone.
The exception is where zonecfg sets up boundary conditions for a given
zone, and thus must take on tasks from other subsystems, but even in
those cases, I expect the 'native' (non-zones) tools to work as well
with those resources as with ones in the global zone.
In fact, I don't see what it has to do with zoneadm. The question is
whether there's a single global view of the resources on the system.
If the answer is "no," then I suspect we'll end up needing to find a
way to provide that view, because that hasn't been a broadly accepted
answer in the past.
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
zones-discuss mailing list