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.
Like many others, my biggest current need is to meet licensing restrictions on the number of CPUs. At the moment this is mostly limited to being needed in the global zone since I have to use Oracle 8i with Quick I/O on a licensed CPU limited basis from there; in the future though, I will be able to move to Oracle 10g hosted in a nonglobal zone so the concepts of the temporary pools in the proposal look pretty good. I can also see a big use for the swap sets and memory sets on a zone basis. Overall, simplicity is good. Yet another GUI certainly would not be good. That being said, management of the proposed changes should be possible in Container Manager in SMC. 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 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. Phil Phil Freund Lead Systems and Storage Administrator Kichler Lighting This message posted from opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
