Hi Andrew!
I believe this may be a bug that was identified last week where the minimums for the cluster are not carried over correctly to all the VMs in the cluster. I am working on that currently, and will update you as soon as I can complete the changes. I'm hoping you might be able to test it in your environment for me! :-)
Thanks,
Mark
Thank you ... I ported the code to JavaScript for the ServiceNow Platform
We will be using the JavaScript based code to select the optimal socket count at provisioning time based on the user's request for vCPUs
During Testing, I got 4 errors (AKA Different answers) out of 12,000+ VMs (Test Cases) ...
--- 2 errors were edge conditions where the host RAM per ServiceNow was (e.g.) 127.96 GB versus 128 causing some of the calculations to fault esp for 128GB VMs
--- the other 2 error were from the one inconsistent cluster that we have
Please let me know if you need any assistance
Please let me know if you have a target release date
Thanks again!
Andrew, I just updated the VMCO module to 3.1.0.0. It should address the inconsistent HW in cluster issue you were having, as well as a 'round' for the host memory that should fix the issue where the host memory was 127.96 vs 128.
You can do an "Update-Module VMCO" to get the latest version. If you are running the "Virtual_Machine_Compute_Optimizer.ps1" script, it should update it for you.
I would appreciate it if you could test it out and give me some feedback!
Thanks!
I updated the VMCO Module
----- Get-InstalledModule -Name VMCO
-----
----- Version Name
----- ------- ----
----- 3.1.0.0 VMCO
I called $optimizationObject = Get-OptimalvCPU -vmName $vm.Name
----- With VM pointing to VM Running on an Inconsistent Cluster
----- Let's call the VM "largishVMOnInconsistentCluster"
----- VM Config is 6 vCPUs and 8GB RAM
******* Code did not detect the inconsistent cluster ********
If I execute:
----- $foo = Get-VMHost -Location $clusters.Name, $foo contains 4 Hosts
Name ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz MemoryUsageGB MemoryTotalGB Version
---- --------------- ---------- ------ ----------- ----------- ------------- ------------- -------
host0 Connected PoweredOn 28 5923 72604 15.850 255.741 6.7.0
host1 Connected PoweredOn 8 4070 27928 7.406 255.742 6.7.0
host2 Connected PoweredOn 28 3725 72604 11.822 255.741 6.7.0
host3 Connected PoweredOn 28 5635 72604 48.109 255.741 6.7.0
----- You can see that host1 has 8 CPUs (2 Sockets * 4 Cores Per Socket)
---------- I recognize that this is unusual, but it is accurate
----- In Get-vSphereInfo(),
---------- Line 117 Correctly Returns the Single Host that the VM is currently running on (host2)
---------- Line 142ish - Cluster has been identified
---------- Line 144 - only 1 host returned (host2 - the host it is running on)
It, therefore, always sets the $Cluster.Inconsistent to $false (the number of hosts inspected is 1 - not all 4)
Line 370 -- $optSockets is computed as 1
The Cluster has DRS Enabled ...
The VM with 6 CPUS is running on host2, but if DRS moves the VM to host1 (4 cores per socket), the VM should be configured for 2 sockets ... is that correct?
Line 375, bacause the cluster is set to Inconsistent = $false, the code at Line 377 never gets executed
If line 377 were executed with knowledge of the 4 hosts in the cluster, it would respond with an optimized core count of 2
----- Get-OptSockets $vm.Name $vm.MemoryGB $calcVmCPUs $clusterMemPerChannel 8 4
Thanks Andrew. I'm working on trying to reproduce your exact issue, as I can't duplicate in my test lab.
Do you happen to have a VMware TAM? One feature I gave the module was the ability to run this tool against the json report that we can generate from the TAM Data Metrics from a customer. That would provide me a very easy way to test against your specific data. Regardless, I'll continue troubleshooting and see if I can figure it out.
I'm in the same place, no “Virtual_Machine_Compute_Optimizer_v3.0.0.ps1" script inside the zip file.
Leonardo,
Apologies for the oversite. I just submitted an update request, so files should hopefully be updated shortly!
We used the VMCO fling to optimize our VMs and made many changes over the past month. A lot of our VMs are 4+ cores, many 8 and 16 cores, and it suggested we move all our VMs to 1 socket and (4, 8, and 16) core setups.
However, our CPU ready time was astronomical... Like 80,000+ ms. Our CPU utilization on each host was only ~25%. We are running single-socket EPYCs host, each with 64 cores/128 threads.
We have since moved almost all of our VMs back to (1) core-per-socket and 4, 8, and 16 sockets. Now our CPU ready time is ~100ms or less for most of our VMs, 300-400ms for some of the heavy hitters.
Since moving back to (1) core-per-socket the VMs feel snappier but we made the changes yesterday and haven't had time to do proper testing. Any suggestions?
Heinrich, I apologize for the slow reply! Can you confirm what version of vSphere you are running in your environment? There are some versions that had performance issues w/ the EPYC processors, so a good place to start troubleshooting. See this KB: https://kb.vmware.com/s/article/67996.
Thanks!
Mark thanks for the reply. We are using vSphere 7.0 U2 (7.0.2.00100) and have AMD EPYC 7742 (Rome) processors.
We looked through this guide (Page 27) https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere70u2-cpu-sched-amd-epyc.pdf
We followed these recommendations:
- NUMA nodes per socket = 1
- CCX-as-NUMA = Disabled
These past few weeks the systems seem to be running much better, CPU Ready time is down considerably. Unfortunately I don't have a good benchmark test (before/after) to show...
Hi Mark,
Where is this recommendation coming from? "The Host Power Policy is recommended to be set to High Performance
for VMs with more than 8 vCPUs"?
I have a VM (6 vCPU, 8GB RAM) running on an inconsistent cluster
--- Cluster has 4 hosts:
------ 3 hosts have 256GB RAM, 2 Sockets * 14 Cores = 28 Physical Cores
------ The inconsistent host has 4 cores per socket) ...
------ DRS is Enabled on the Cluster
Yet the tool does not report the inconsistent state and suggests a optimal socket = 1 - this VM would not fit on the small host ...
Any thoughts?