Amol,
Thanks for your comments. I have some responses in-line.
Amol A Chiplunkar wrote:
These are very exciting features !!
Some comments.
If a dedicated-cpu (or eventually a dedicated-memory) resource is
configured for the zone, then when the zone boots zoneadmd will create
a temporary pool dedicated for the zones use.
The temp pool created is going to show up in pooladm output, right ?
If someone uses such a pool in a zone configuration done in traditional
style. ( set pool=SUNWzone{zoneid} ) is zonecfg going to reject it ?
If not, it won't be "dedicated" anymore.
That is a good point. We will make sure that zonecfg disallows that and I
will clarify that in the proposal. One thing I wanted to point out is that
the name of the pool/pset will actually change when you reboot the zone since
the zoneid will change at that time. There is no easy way to predict what
the name will be or if any particular name will exist, since the zoneid is
fairly dynamic. We are not going too far out of our way to try to prevent
you from using the temp. pool for something else but I will make sure zonecfg
doesn't allow that.
Also, is there something that's going to stop poolbind that may move
zones to and from temp pools to permanent pools ?
What if a zone was created as a result of which a temp pool was created,
and poolbind moves it to a permanent pool ? The temp pool is deleted ?
That is a good question. I need to think about what we should do there
but I am inclined to say that we should disallow that. Once you start
allowing stuff like that, then we are back to the problem of where the
configuration data is stored and managed and that is what we are trying to
avoid with the whole idea of the temporary pool.
Resource controls in zonecfg will be simplified.
Do you think we need prctl enhancements that will allow setting rctls
using the new aliases directly ? that would be good for consistency.
That is another good idea. I'd like to keep that separate for now but
we'll keep it on our plate.
Also you mention that the backword compatibility ensures the existing
tools that parse zonecfg info / export output are unaffected. It's true
to some extend. But some of them treat "unknown" resources as nop and
display them as is. Which means some tools will show the new resources
as unknown which is harmless but could be confusing sometimes.
We are continuing to add new resources. 'limitpriv' and 'bootargs' are
two recent ones. We won't stop adding new resources; that would be
too constraining, but we will continue to try to make sure we don't
break scripts that depend on resources that they know about.
May be having a command line option such as zonecfg info -legacy that
would
suppress the new resources could help.
I think it would be better to plan for new resources. Otherwise, what would
legacy be? Just the resources that were in the original S10 release?
We will enhance zoneadmd so that if the zone.cpu-shares rctl is set
and FSS is not already the default scheduling class, zoneadmd will set
the scheduling class to be FSS for processes in the zone.
On the fly ? i.e. If a zone didn't have zone.cpu-shares when it was
booted
and someone did prctl to set it, zoneadmd will change the sched class
of all
processes in the zone to FSS ? That's cool.
That is not what we plan on doing. What we are planning is to set
FSS when the zone boots, if it has cpu-shares. These enhancements are
really targeted at people who don't know a lot about the existing RM
features. If you know enough to use prctl to do this kind of thing, then
we will expect you to be able to fully manage your system using all of
the existing features.
Thanks again for your comments,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
