Good morning,
I applied the most recent set of patches to one of my vSphere hosts last night (SuperMicro SYS-5028D-TN4T) and in the vSphere client this morning I'm seeing a Configuration Issues popup:
XXX esx.problem.hyperthreading.unmitigated.formatOnHost not found XXX
Tried searching a log bundle through the vSphere Web client and couldn't locate this in the bundle for that host.
Any ideas what this is about? I'm seeing Hyperthreading Active on this host.
vSphere 6.0 Essentials on this box(VMware ESXi, 6.0.0, 9313334)
Thanks!
--Ben
Open the vSphere Web Client navigator and locate the particular host system, select the Manage tab and click Settings. Select Advanced System Settings in the System area and select the VMkernel.Boot.hyperthreading entry. If the value is true, hyper-threading is enabled in vSphere 6. Reading Time: 7 minutes The L1 Terminal Fault (aka Foreshadow) bug is another speculative execution side channel attack that affects Intel Core processors and Intel Xeon processors only. For VMware vSphere, there are some patches available as described in this document: VMSA-2018-0020. All patches have been released on August, 14th 2018.
I applied the most recent set of patches to one of my vSphere hosts last night (SuperMicro SYS-5028D-TN4T) and in the vSphere client this morning I'm seeing a Configuration Issues popup:
XXX esx.problem.hyperthreading.unmitigated.formatOnHost not found XXX
Tried searching a log bundle through the vSphere Web client and couldn't locate this in the bundle for that host.
Any ideas what this is about? I'm seeing Hyperthreading Active on this host.
vSphere 6.0 Essentials on this box(VMware ESXi, 6.0.0, 9313334)
Thanks!
--Ben
EDIT 2: My application benefits from hyper-threading
A. Yes I know what the technology is and what it does
B. Yes I know the difference between a physical core and a logical one
C. Yes turning HT off made the render run slower, this is expected!
D. No I am not overprivisoning when I assign all the logical (yes logical) cores to one VM, if you read the white papers from VMWare you will know that the scheduler generates a topology map of the physical hardware and uses that map when allocating resources, assigning ALL the logical cores to one VM generates 16 logical processors in Windows, the same as if I installed the VM on physical hardware. And whoa and behold, after 5 tests this arrangement has produced the fastest (and most efficient) render times.
F. The application in question is 3ds max 2014 using backburner and the Mental Ray renderer.
TL|DR: I (sometimes) want to run one VM on vSphere with as much CPU efficiency as possible, how?
I'm hoping to use VMWare's ESXI / vSphere hypervisor in a bit of a non-standard way.
Normally people use a hypervisor to run multiple VM's simultaneously on one system. I want to use the hypervisior to let me quickly switch between applications, but only ever really run one VM / App at a time.
It's actually a pet project, I have a 5 node renderfarm (ea. node 2x Intel Xeon E5540) that for the most part stays off (when I'm not rendering I have no need to run these machines). It seems like a waste of valuable compute time so I was hoping to use them for other things when not rendering (kind of a general purpose 40 core / 80 thread compute cluster).
I was hoping that vSphere could let me spin up render node VM's when rendering and other things when not. Problem is, I really really need a high efficiency when it comes to CPU when the render VM is running.
I'm using a render job as a benchmark and getting about 88% of the speed on the VM as I can get on a non-VM setup. I was hoping for closer to 95%, any ideas how I could get there?
EDIT: Details:
Resources being used by the render VM, I don't fully understand why this bar is not full:
Resource settings for that VM:
Even though the VM doesn't show as using 100% of the resources, the host does:
I don't entirely understand the % shares here, is this when all these VM's are on? Also I didn't configure the other VM's to reserve 10%:
Finally the host does show as being fully utilized, although not shown here, the MHz utilization is lower (IE not 100%):
VM Config:
I understand this is a interesting case, but nevertheless I feel the question is valid and good and may help others in a similar situation down the line (although I admit this case is quite specific).
Cody Smith
Cody SmithCody Smith
closed as off-topic by Andrew, Rob Moir, HopelessN00b, Ward♦, Falcon MomotFeb 19 '14 at 6:25
This question appears to be off-topic. The users who voted to close gave this specific reason:
- 'Questions must be relevant to professional system administration. Server Fault is dedicated to professional system and network administrators. End user and enthusiast questions are off-topic (contact your system administrator or hire a professional to help you out). Please see the Help Center for more information.' – Andrew, Rob Moir, HopelessN00b
2 Answers
I think you've reached about the maximum of what you're likely to get with those old Xeons, though unlike ewwhite I do not believe hyperthreading is causing you any sort of problem. Indeed, at least since ESXi 5.0, VMware has recommended using hyperthreading for most workloads, and your own testing seems to confirm that you are benefiting from HT. As ewwhite correctly notes, though, using HT will make some metrics in vSphere appear strangely.
I think you have one obvious issue and possibly one non-obvious issue here:
First is the obvious issue that virtualization itself incurs overhead that you can never fully eliminate. In the case of the CPU, certain instructions must be virtualized in order for the hypervisor to correctly isolate one virtual machine from another. Thus instead of executing the instruction directly, as in bare metal, the hypervisor will intercept the call and execute several instructions in its place. From prior experience we can see that 87-90% is about what you should expect for the CPU. Getting much past that would require a significant advance in hardware. If you're now seeing 91% of native CPU performance, it's probably about as good as it's going to get.
Second is the non-obvious issue of NUMA. This is an issue with multiprocessor systems, where part of the memory is faster when accessed by the nearest CPU, and slower when accessed by other CPUs. Depending on how your rendering job handles memory, you might see some benefit by running two parallel renderers in two VMs, each of which is pinned to a specific CPU and always accesses the slightly faster memory. (If you run two VMs on a single host, each using half the available vCPUs, ESXi should sort this out automatically for you.) Though if you aren't seeing this issue on bare metal, you probably will gain little benefit by trying this.
Community♦
Michael Hampton♦Michael Hampton180k2828 gold badges337337 silver badges667667 bronze badges
You've misconfigured your virtual machine(s) and host.
Things to consider:
- If you have a computationally-heavy process, you may want to disable HyperThreading.
- Intel E5540 CPUs date back to 2009. They are quad-core CPUs. You'll have 8 physical cores and 8 logical cores (16 total).
- If you've configured a single VM with 16 vCPUs, scale back!!
- ESXi requires some resources, too.
- Try right-sizing your virtual machine (8 vCPU) if you're not willing to disable HyperThreading.
Other things to do (in general)...
- Update your ESXi to the current revision and patch.
- Update the virtual hardware of your VMs (e.g. vmx-09 or vmx-10).
Community♦
ewwhiteewwhite176k8080 gold badges380380 silver badges734734 bronze badges