R.S. wrote:
IMHO it does make a sense.
1. You can share processors for systems which do not support more than
x (16) CPs, or support them badly, or there are tools installed which
do not support or...
Who said anything about assigning more logical CPs than an operating
system can handle?
2. You can assign CPgroup1 to prod LPARs, and CPgroup2 to non-prod.
Or, you assign group1 to Customer1 LPARs, and group2 to Customer2
LPARs. Workload is balanced only within Customer "sandbox". Especially
useful when whole-CP granularity isn't enough.
If the production LPARs using CPgroup1 become constrained for physical
CPs, they won't have access to the physical CPs dedicated to CPgroup2 --
even if some of them are idle. (Yikes!) Best to share them all. Let prod
& test get all they want allowing LPAR weights to determine what happens
when utilization reaches 100%.
Believe me, I recognize the need for some sort of LPAR grouping
capability. I have suggested the concept of an LPAR group, in which
several LPARs could be managed -- in aggregate -- to a given defined
capacity. (That capability would solve a number of sub-capacity issues.)
But I really don't like the idea of physical partitioning of the
processor. IMHO, it's asking for trouble!
--
-----------------------------------------------------------------
| Edward E. Jaffe | |
| Mgr, Research & Development | [EMAIL PROTECTED] |
| Phoenix Software International | Tel: (310) 338-0400 x318 |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 |
| Los Angeles, CA 90045 | http://www.phoenixsoftware.com |
-----------------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
