Peter Memishian wrote:
> > > With regard to the third bullet, please see my concerns above about the
> > > introduction of "list -l". I think this should be part of a general
> > > zone status/health facility or perhaps something that dladm(1M) can
> > > print about the link names and how their assignment zone-wise.
> > Displaying the zone with dladm show-link seems a nice approach to me.
> Which project is planning on making GLDv3 zone aware?
> IP Instances isn't.
Dunno. My comment was about the overall user experience, not about which
project does what.
Having layer N or subsystem X, which isn't otherwise aware of
virtualization, be the place to look for how virtualization is set up
seems quite odd to me.
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.
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.
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 ;-)
zones-discuss mailing list