If you have 8 CPU cores and you want to create VM guests with 4 cores and 20% entitlement then you should be able to create 10 guests. Obviously this assumes you have sufficient memory, I/O, and other resources needed by these guests.
Dave
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Yes. Your bl860c i2 had 8 CPU cores. You are using 20% entitlements, so each core can support 5 guests. 5*8=40 shares. Since each VM guest is using 4 "shares" you could have 10 such guests.
Dave
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
(1) So, in this rx8640 vmhost, how much entitlement I should give to match that?
I'm not clear what you're asking. Are you asking how much entitlement you need to give a VM guest on an rx8640 with 400MHz CPUs to match a VM guest on a bl860c i2 using 20% entitlements of 1.6GHz CPUs? There are many variables involved here to give a simple answer. Entitlements are merely guaranteed minimums, so a VM with 20% entitlements running on an otherwise idle system could use 100% of the vCPUs it has been assigned. Also, if the VM guest does not need to use 20% of the CPU cores it can use less and other VM guests running on the system can use some of it's CPU time. All the entitlements mean is - when I get busy, I'm guaranteed to get at least X amount of CPU time on these cores. So without knowing how busy your VM guests are on the i2 blade I cannot determine how much CPU time you'll need on the rx8640.
(2) Also, if I give 20% entitlement for each guest, with four CPUs, with four processors....will I be able to create only five vmguests?
If you're ONLY going to create guests with 20% entitlements and 4 vCPUs on then you could create 5 VM guests on a VM host with 4 physical CPUs. You mentioned earlier that some guests have 10%, others 20%, others 7%. It's also possible that some of those guests might only use 1 vCPU, or 2, or 3, etc. In that case, if you're mixing and matching VMs with different amounts of entitlements and different numbers of vCPUs, the number you can run simultaneously will depend largely on what order you try to start them. As the VM guests start and they are assigned their resources, the scheduler will determine how many vCPUs remain available and how much entitlement remains on those CPUs.
Dave
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
@silusan wrote:calculating the CPUs consumed:
2 x 10% = 0.20 CPU
4 x 7% = 0.28 CPU
2 x 10% = 0.20 CPU
2 x 7% = 0.14 CPU
4 x 20% = 0.80 CPU
4 x 20% = 0.80 CPU
-------------------
total 2.42 CPU
------------------so, 1.58 CPU is remaining.
let us consider it as 1.6 CPU, to make calculations easy...
so, I can create four more vm guests with (4 vCPUs x 10%) = 1.60 CPU
No, this is not a valid way to calculate remaining vCPU resources. There are several rules the scheduler applies when assigning vCPUs to physical CPUs. Among them are:
- Attempt to use all available physical cores, rather than stack VM guests on a single core and overload it.
- Ensure that vCPUs of a single VM are not assigned to the same physical core. In other words, if you have a VM guest with 2 vCPUs, the threads associated with those virtual CPUs will run on different physical CPUs. So you cannot say "this guest has 2 vCPUs and 20% entitlement so that's roughly 40% of a single CPU". Instead you need to say "this guest has 2 vCPUs and 20% entitlement so it has the rights to 20% of two separate physical CPUs".
- The scheduler can move vCPU threads around to different physical CPUs, but it makes every attempt to enforce the best locality possible. In other words, it tries to locate the vCPU threads in the same locality domain as the memory assigned to the guest so that the memory latency of vCPUs accessing their memory will be minimized.
So again, simply multiplying the number of vCPUs by their entitlement and subtracting from the physical CPUs will not give you an accurate picture of which specific vCPU resources are available at any given time. Here are a couple slides from one of my "best practices" decks that explain this phenomenon:
If you want to see which physical CPUs are assigned to a specific VM guest at any given time, you can use the "hpvmstatus -C" command. This syntax works on Integrity VM v6.1 and newer systems:
atcuxbl1(/) -> hpvmstatus -C
Virtual Machine Name VM # ldom # Total Memory(MB) SPU Ids
===================== ======= ====== ================ ==========
guest1 1 0 128 12,14
guest2 2 0 128 4,6,8,10
guest3 3 0 128 0,2
guest4 4 0 128 8,10
guest5 5 0 128 4,6,12,14
guest6 6 0 128 0,2,8,10
I created the same 6 guests on my VM host as in your example. My host has 8 physical CPU cores and the scheduler spread these 6 guests across all 8 cores. It also ensures that each vCPU for each VM guest is assigned to a different physical core.
@silusan wrote:
That begs another question, the vm host itself to be UP and running...doesn't it need any CPU at all? If I give all the available CPUs to guests, how does the vmhost remain UP and running? if the vmhost needs some CPU to remain UP and running, how do I know how much it needs?
The VM host scheduler will always hold back some CPU resources for managing the VM guests. You can assign 100% of all the available CPUs to VM guests and have them running without worrying about the VM host not getting the CPU cycles it needs to manage the guests.
Hope this helps,
Dave
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]