On Tue, 13 May 2008 05:43:24 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
I think you have some terminology problems.
CF LPARs are NOT dummies.
If you are truly using them as CFs, they should not be used in this manner.
It is OK
What he means , is , he does not need any CF , but he wants to
G'day Michael - this is an ugly hack. But you knew that already.
Weights being merely guess-timates, I normally set them (for all LPARs) to
what you want the box divvied up as when all LPARs are (concurrently) 100%
busy. In your case, maybe set the CF LPAR to slightly higher, just for
sanity -
Thanks Bruno Shane. I know this is not pretty, but you give me more
confidence in what I hope will be a short term solution.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED]
We wish to follow the advice given in an earlier to cap MSU usage of our 2
LPARs (2 monoplexes) by intoducing a dummy CF LPAR when we upgrade our
z890. I understand we should SET DYNDISP OFF.
But what would be a good weight for the CF LPAR so it always consume a
fixed number of MSUs (capped of
But what would be a good weight for the CF LPAR so it always consume a fixed
number of MSUs (capped of course).
CF's do not contribute to MSU charging.
They should always be allowed to run without any form of capping or sharing.
What problem are you trying to solve?
-
Too busy driving to stop
But what would be a good weight for the CF LPAR so it always consume a
fixed number of MSUs (capped of course).
CF's do not contribute to MSU charging.
They should always be allowed to run without any form of capping or
sharing.
What problem are you trying to solve?
Upgrading capacity of z890
Upgrading capacity of z890 but capping total MSUs of existing 2 LPARs to 26
MSUs, but also not wanting to cap each LPAR as such (i.e. each LPAR could
get the whole 26 MSUs if the other LPAR is idle). Therefore using the dummy CF
LPAR to consume the MSUs we do not want to be charged for.
I
7 matches
Mail list logo
