OK to allocate all the Host's physical CPU cores to each guest?

[Mike Patterson]

Hello forum -

We want to modify 3 guests, each currently allocated with 2 vCPUs to 4 vCPUs. (We don't want to change the VM resources entitlements.)  

As you can see, the HPVM host has 2, dual-core CPUs (4 cores):

Host60 # machinfo
CPU info:
  2 Intel(R) Itanium 2 9000 series processors (1.59 GHz, 18 MB)
          532 MT/s bus, CPU version C2
          4 logical processors (2 per socket)

Host60 # hpvmstatus -r
[Virtual Machine Resource Entitlement]
[Virtual CPU entitlement]
                                                      Percent       Cumulative
Virtual Machine Name VM #  #VCPUs Entitlement Maximum   Usage            Usage
==================== ===== ====== =========== ======= ======= ================
VM60_25             1      2       10.0%  100.0%   25.6%       4240594649
VM60_26             2      2       10.0%  100.0%    9.1%       1372121936
VM63_27             3      2       10.0%  100.0%   20.7%       1747948460

Question:

If we allow the guests to use all 4 of the host's CPU cores, is there any danger to the host?

In other words, could the guests conceivably take all the CPU power under high load, and possibly crash the physical host blade?  Are CPU resources like Memory in HPVM where you want to reserve some resources for the host to keep running?

[Dave Olker]

No, there is no danger to the host.  The VSP (VM Host) reserves a portion of CPU for its use behind the scenes, so even if you had your entitlements set such that your VM guests were allowed to consume 100% of all 4 CPUs the VSP should still operate as expected.

Dave

[Mike Patterson]

Thanks for the reply, Dave.  Would you consider allocating all the physical CPUs to each guest a generally good practice?

For example, this environment in in "sustain" mode and there simply aren't enough host resources to build another guest even if we ever had such a request.  (These VMs have been up over 800 days in production.)

So, why not simply give each guest the maximum vCPUs available to the avoid peak performance CPU alerts that we've been getting on these VM?  (The IT Mgrs around here ask such questions. )

[Dave Olker · Accepted solution]

My answer, as is my typical answer for any performance related question, is "it depends".  

You could absolutely give each VM 4 vCPUs and leave their entitlements set at the defaults (min=10, max=100) and let the scheduler decide which VM needs more CPU at any given time.  Nothing wrong with that but if more than one VM needs lots of CPU time simultaneously you could run into a case where the VMs are fighting each other for priority.  

It's also possible that the applications running in these VMs won't scale well past 2 CPUs, so even if you gave the VMs more CPUs they might not benefit from them.  The fact that they've been running for 800 days in production at their current configuration (I assume) tells me they work pretty well with 2 vCPUs so changing their config to 4 vCPUs should be done only after some testing to ensure the applications scale as desired.

Do all three of these VMs experience periods of increased need during a typical monthly cycle?  Two of them?  One of them?  If only one VM fluctuates drastically and needs lots of CPU at times then you might consider giving that VM 100% entitlement to two CPU cores and then let the other two VMs share the remaining two cores.

On a side note, if these VMs have really been running for 800 days, that tells me they're likely running an older version of Integrity VM.  Depending on which version, you might need to think about updating to a newer version to remain supported.  For example, support for version 4.2 ended in March 2013.  Support for v4.2.5 ends in September 2013 and support for v4.3 is scheduled to end in March 2014.  If you're running a v4.X version of Integrity VM you may want to think about updating to a v6.X version.

Dave

[Mike Patterson]

Dave -

Thanks for you thoughtful reply. Yes, we're struggling with project politics to get the HP-UX (including VM) updated on all the systems in this environment. 

- Mike