On Fri 03 Nov 2006 at 09:42AM, Erik Nordmark wrote:
> Thus if instead of using zonecfg to configure the boundary of the zone,
> things were spread across different commands (use dladm to assign link
> names to zones, use some zpool command to assign pools to zones, use zfs
> commands to assign zfs filesystems to zones), the I can see the point.
This is not correct. Several major commands let you alter the boundary
of the zone at runtime, by design. The difference between these
commands and zonecfg is that only zonecfg lets you do that persistently.
> But given that zonecfg is used to specify the boundary of the zone
> (which link names, which pools, which file systems), it seems very
> unnatural that in order to look at what assignment was made one would
> have to use separate commands (be they dladm/pooladm/zfs). It seems
> natural to be able to look at that using a zone* command.
You can priocntl a zone, you can mount things into it, you
can ifconfig things into it, you can use poolbind to alter its
pool binding, etc. This is by design.
> Note that zoneadm list is a bit idiosyncratic. It displays some things
> that are properties of the running state of the zone, which can not be
> found elsewhere (the zoneid and the state), but zoneadm list also
> displays a bunch of properties of the zones that are fixed (the uuid,
> brand, zonepath, etc) do not change as zoneadm manipulates the zone.
>
> 'list -i' religiously follows this idiosyncratic approach ;-)
We have a plan to add 'zoneadm info' or some such to display all the
runtime attributes of running zones. Hopefully we'll get to that in the
next 12 months or so. I'd request that you hold off on adding list -l
until we design 'info'.
It's up to the network experts to decide whether dladm -z or some such
should exist to provide zone scoping.
The design principal is: If 'zone' is an important property of the object
being managed, then it should be considered for display, since
administrators may need to be aware of that information, or may need
an easy way to get it.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
