On 6/26/06, Phil Freund <[EMAIL PROTECTED]> wrote:
I'm just trying to get my head around how to setup the whole pool/resource
capping arena for my server/zone configurations and am finding it a bit
confusing and arcane. Your proposal looks pretty good to me since most of what
I need would be covered by the defaults. It's certainly more understandable.
Unfortunately, I have to go ahead with what's available now and will have to
retrofit the changes based on this proposal if/when they get implemented.
I found Brendan Gregg's page
http://users.tpg.com.au/adsln4yb/zones.html very helpful. He
condensed dozens (hundreds?) of pages down to something digestable in
a few minutes.
One suggestion that may only be tangential to this effort is that a mechanism
be put in place to allow the global zone sysadmin to set the default pool and
resource values (such as cpu shares) for the global zone without having to
write a script to set them on boot. It doesn't look particularly hard but it is
one more thing to maintain that really should be handled by the OS.
I have created a replacement for svc:/system/zones and its associated
/lib/svc/method/* script to activate the appropriate pools during zone
booting. It does other things too - adds a default router if
necessary, allows an override for zone shutdown timeout, makes sure
that the zone's IP address isn't pingable, etc. You may want to
consider going this route if you have a similar set of concerns.
I also like the idea of activating FSS if the zone.cpu-shares parameter is set.
Given that activating FSS requires a reboot of the global zone, you should add
a check to see if FSS is already active and if it is not, put out a warning
message indicating that a reboot of the global is required to make FSS active.
For that matter, there should be a warning message on zone boot that FSS is not
active and the configured zone.cpu-shares value will be ignored.
No reboot is required. See poolbind in this example:
zones-discuss mailing list