[bcarlson]

Hey all,

I'm slowly getting my APV legs and have run into a stumbling block.

I understand changing entitlement for an LPAR that is active via the HMC and such.

How, or for that matter, can one do that for an inactive LPAR? Besides activating the LPAR, DLPARing and then shutting it down again?

[estuart]

For an inactive lpar you would just adjust the settings by selecting the desired partition profile and modifying the properties.

[bcarlson]

That only helps if the aim is to reactivate the LPAR.

Here's my situation:
The managed system is 100% allocated for processing units. An LPAR is inactive but is still reserved its entitlement. Is it possible to deallocate the inactive LPARs entitlement without changing the LPAR's profile or switching the profile, activate/DPLAR/deactivate the LPAR?

[estuart]

Since the lpar is defined and it has a minimum cpu entitlement then that entitlement must be reserved by the hypervisor so that the lpar can start should it be turned on. To access some of that entitlement you would have to modify the partition's properties and lower its minimum cpu requirement or delete the lpar. If the lpar is off, modifying its entitlement should be trival.

[bcarlson]

I would think this is easy to do, I just don't know how. Let me make the situation clearer.

I've got several LPARs, uncapped/shared on a p570.

I've got an lpar, that is currently down, with the following:
lshwres -r proc --level lpar -m p570 | grep LPAR
....curr_min_proc_units=0.2,curr_proc_units=1.0,cu rr_max_proc_units=1.0....

The pool is completely allocated:

lshwres -r proc --level pool -m p570
shared_proc_pool_id=0,configurable_pool_proc_units =16.0,curr_avail_pool_proc_units=0.0,pend_avail_po ol_proc_units=0.0


What I'd like to do is set this inactive LPAR to it's minimum allocation without activating/deactivating. WSM doesn't allow this as the LPAR is down (no DLPAR).

This seem like simple bookkeeping to me, I'm just looking for the proper book.

I would have thought chhwres would handle this, but the man page specifically mentions that only modifies a running LPAR.

[ScriptDaddy]

It's not possible to modify or perform any operations on an LPAR that is in a down/de-activated state.

The LPAR would need to be activated for the hypervisor to perform any changes.

When you modify a LPAR profile, the hypervisor does not know about those changes until you activate the profile, which is when it's written to memory.

The only way around it is to activate and then de-activate your profile I'm afraid, unless you know someone who has access to the low level commands, that will write the updates to the Hypervisor direct. I only know of one bloke that has knowledge of those commands and he helps write the HMC software.

Ben

[bcarlson]

Okay, that's what I was beginning to suspect.

Recommended practice then would be to carefully consider DLPARing resources before bringing an LPAR down.

[ScriptDaddy]

I understand it can be a hinderence, but it has been implemented this way for a reason. Imagine everytime you made a change to the profile it was updated on the Hypervisor, not a problem if you are 100% sure with things, but imagine if an inexperienced user accidently assigned all available and shared CPU's to a LPAR, you run the risk of seriously effecting performance or worse causing the system to fail.

The good thing about activating the profile is that is will complain should resource conflicts or lack of resources be found.

I'm sure in a future release of the HMC software they will remove this boundary, but in the mean time, it's a case of activate / deactivate.

Ben

[bcarlson]

Originally Posted by ScriptDaddy

I understand it can be a hinderence, but it has been implemented this way for a reason. Imagine everytime you made a change to the profile it was updated on the Hypervisor, not a problem if you are 100% sure with
Ben

I agree, making profile changes apply to the Hypervisor as soon as they are made would be bad. Nevermind that multiple profiles could exist, how would you choose which profile settings to apply?

However, what I've been talking about is not a profile change. The behavior I have seen is that even though a shared LPAR is down, its last entitlement (which may be anywhere between min and max, whatever was last DLPARed) is reserved even though that LPAR is down. And there doesn't seem to be a way to affect that entitlement other than activate/DLPAR/deactivate.

Imagine I have 3 LPARS and 3 total processing units (3 CPUs). Each LPAR is set with shared, uncapped and:
min_proc_units=.5
desired_proc_units=1
max_proc_units=2

Start with L1 and L2 active, L2 was allocated max entitlement at some point. L3 is currently inactive
L1,active,curr_proc_units=1
L2,active,curr_proc_units=2
L3,inactive,curr_proc_units=0

At this point, L3 can't be activated. Say we down L2. L3 still can't be activated, checking the processor pool would show 0 proc_units available, with
L1,active,curr_proc_units=1
L2,inactive,curr_proc_units=2
L3,inactive,curr_proc_units=0

What should be possible is to set L2's curr_proc_units, even though it is currently down. I can understand reserving L2's proc_units, otherwise downing an LPAR may allow another LPAR to 'steal' enough proc_units that the original LPAR can no longer start: very undesirable.

[ScriptDaddy]

I understand what your saying and also agree. I was mainly pointing out a scenario that could happen.

Like you mentioned earlier, any future DLPAR operations will need to be carefully thought through. As a rule of thumb I always try to ensure at least the minimum amount of CPU is still assigned to an LPAR i.e. not DLPAR'd out, removed etc, as you never know when you'll need to bring the LPAR back up.

Re: Your scenario.

L3 would be able to start if you downed L2, what you are seeing is what the Hyper Visor currently know's. Once you started L3, it would update it's config and allow the LPAR to start, as long as the CPU's were set to shared.

Sorry if I haven't made myself clear, I'll try to reword it better if that's the case.

Ben