RE: Setting up HMC Processor(s)

I agree with Pete, only I go down to .10 processors for the minimum.
Movement of CPU between LPARs is near instant and lets the horsepower go
where it's needed. It's not an after-the-fact adjustment with a
catch-up lag period like the i5/OS performance adjuster that moves RAM
from pool to pool.

As to Virtual CPUs, for the vast majority of workloads the best setting
is equal to the maximum number of physical CPUs the LPAR can have,
rounded up. 0.10 Physical --> 1 Virtual. 1.01 Physical --> 2 Virtual.
2 Physical --> 2 Virtual, and so on. In Pete's first paragraph below,
that would lead to Dev having 1 Virtual CPU and Prod having 2.

BTW, while you can cap Dev at 1 CPU, you could cap it at 2 but assign
higher weighting to Prod so it always gets priority over CPU resources.
That way even big Dev jobs can get a lot of CPU if - and only if - the
CPU isn't currently needed in Prod.

Really, it works fantastically well. You don't notice any lag in
movement of CPU from LPAR to LPAR.

As for reactivation, technically you are reactivating the partition
profile. So on the HMC hit the + next to the LPAR name and then
right-click the profile and activate it.

Last note: On a WRKACTJOB or WRKSYSSTS, 100% CPU = Desired. So you can
tell when an LPAR is using more than Desired, all the way up to Maximum.
However, the Max CPU percentage possible on an LPAR can vary based on
the max CPU allocation. If Dev has min/desired/max of 0.10, 0.5, 1.0
then 100% CPU usage as shown by WRKACTJOB is 50% of a physical CPU and
the max the LPAR can show is 200% if it is running at the full 1.0 CPUs.
Prod, OTOH, has allocations of 0.10, 1.5, and 2.0 so 100% utilization
equates to 1.5 physical CPUs and the max CPU percentage that WRKACTJOB
can show would be 133% (2.0 being 133% of 1.5). It is a little
confusing at first, but I've found that once I set up the uncapped
access and assigned appropriate weighting factors I've just about
stopped looking at CPU busy when monitoring the system.