Dynamic CPU allocation into vPar from enclosing nPar

[Martin Kendall]

Folks,

I just need to ask if it is possible to dynamically allocate CPUs into a a vPar
if they are unallocated elsewhere within the enclosing nPar.

Many thanks

[Peter Godron]

Martin,
seems you asked similar question before:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1051200

Please also read:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33 on how to reward any useful answers given to your questions.

So far you have not awarded any points !


From another thread:
"Be careful that you fully understand the implications of what you are doing... remember that in vPar any unbound CPU (that is a CPU that can be moved between vPars without stopping the effected partitions) is NOT capable of handling IO interrupts, and as such cannot handle IO for any of the processes in whatever vPar it happens to be in. Depending on how you change your environment, if you end up with more unbound CPUs than you currently have, you could find a reduction in performance in some of your vPars if you applications have many IO intensive processes."

[Martin Kendall]

Hi Peter,

I know my last question was similar but I did check and this one is different on the following basis. I will award points and apologies if I forgot to do so - I will check the previous one and do so while I await for a response on this one.

Anyway, the difference in this case is that I am considering an "in and out of nPar to a vPar" as opposed to "in and out of vPar to another vPar". I do hope I'm making ense :-)

[Jaime Bolanos Rojas.]

Martin,

If I am not mistaking it, we can not view available resources that are not assigned to any Vpar, from there if we can not view them, we can not assign them.

Regards,

Jaime.

[Martin Kendall]

Jaime,

This is bad news....it seems that one has to create an "extra vPar" just to be able to "borrow" extra CPUs :-)

[Duncan Edmonstone]

Martin,

If I understand ypur question correctly, which I would summarise as follows:

If I have an nPar with 4 CPUs in it, and a vPar in that nPar with 2 CPUs in it, can I assign the 2 unallocated CPUs to the vPar?

The answer is YES of course you can - use 'vparstatus -A' to view unallocated resources, then the usual vparmodify commands as you see fit...

HTH

Duncan

[Martin Kendall]

Duncan,

Do you know if the CPU allocation can be automated via Workload Manager ?

Thanks

Martin

[Tim Nelson]

Martin,

Yes. Dynamic CPU allocation is a function of WLM. WLM simply executes vparmodify commands based on its configuration metrics.

Reveiw the wlm template called vpar_usage_goal. Very simple.

[Martin Kendall]

OK folks, it seems that Duncan's response was helpful and Tim's very helpful indeed. I will do the points allocation if I have not heard any conflicting responses by tomorrow.

I am grateful to you all.

Martin

[Duncan Edmonstone]

Martin,

I'm not so sure your specific scenario will work with WLM - whilst WLM will happily move allocated CPU resources about between vPars, I'm not sure whether it will pay any attention to unallocated CPUs. Read the following:

http://docs.hp.com/en/B8843-90033/ch01s03.html#d0e437

Now this is describing a situation around iCAP, but the point I took from it is that WLM looks at CPUs which are *already assigned* to vPars when it starts.

Of course, if they're not iCAP CPUs I can't think of a reason why you wouldn't want to have all of your CPUs assigned to some vPar - otherwise you're paying for them and not using them...

HTH

Duncan

[Martin Kendall]

Doh ! sorry Duncan, the idea is that 2 CPUs are active - meaning RightToUse is available and the other 2 are iCAP. I was hoping that I could create a 2 CPU vPar and be able to dynamically allocate the 2 iCAP ones as and when workload warrants their use (let's ignore the different types of iCAP for this question).

regards

Martin

[Duncan Edmonstone]

Martin,

So you have another nPar that you're going to 'borrow' active cores from (by moving around where the iCAP cores are)? Well WLM *will* manage that.

The situation described in the link I posted was just for where iCAP wasn't involved (i.e. the CPUs were active, just not assigned to a vPar).

HTH

Duncan

[Duncan Edmonstone]

Have a read of the following whitepaper:

http://h20338.www2.hp.com/hpux11i/downloads/resizing.partitions.with.wlm.pdf

HTH

Duncan

[Martin Kendall]

No, it is the same nPar as the one containing the vPar

[Torsten.]

Hi,

when you are creating a vPar, you are specifying the minimum, maximum and current (total) number of CPUs.

example:

-a cpu:::2:4
(min 2, max 4)

-a cpu::3
(total 3)

In this case you can add 1 other, unallocated CPU to the vPar (check this with vparstatus) by issuing

vparmodify -P name -a cpu::1

this will add 1 CPU to the vPar - same for reduce the total number (-d switch)

For the 11.11 version the minimum stands for the "bound" CPUs.

[Martin Kendall]

Folks these are all good ideas but the crux is still: Can it be done through WLM so that the iCAP CPUs are allocated and activated on demand - to the single vPar in the nPar. In other words, the vPar starts life with 2 active CPUs allocated. It can then have two more CPUs added (the iCAP ones) from the nPar that contains the vPar (there are no other vPars in the same nPar).

[Steve Lewis]

Yes it can, but, I personally had trouble understanding the language that the WLM config utility was using - 'service standards' etc, it didn't seem to translate very well into 'when can I get it to add another core to my partition?' It appeared to be overblown for what wanted.

So what we did instead was to create a simple regular cron job that does a ruptime (enable RWHOD in your netdaemons config file). If it finds that a partition is overloaded, it drops a core from a less-loaded partition and adds it to this one. You could do a similar thing, but also/instead activate a T-ICAP cpu for a while to get you over the peak in processing.

[Martin Kendall]

OK, it looks like it *may* be possible to both activate AND allocate an iCAP CPU that is not currently allocated in an nPAR, to a vPar in the same nPar. No?

Regards

Martin