crimsonyoshi
Contributor
Contributor

Workstation Pro 17 and Alder Lake

Good afternoon VMWare community! This is a follow up post to this thread I made in the technical preview boards (which have now been disabled with the release of version 17): VMWare Workstation Pro WS-TP-22H2 - VMware Technology Network VMTN

 

I've been doing further testing and I've managed to alleviate most of the remaining problems. The virtual machines still aren't 100% glitch free, but they're maybe at 99% now.

 

In summary and in the event the linked post is removed in the future, P and E-cores were causing problems for the technical preview versions of WS17Pro while running Windows 11 Pro (22H2) on both the host and VM. I was able to replicate most of the problems in the release candidate for WS17Pro as well. The first and major issue was with E-cores enabled, if the virtual machine grabbed any E-cores for use on the host, all cores on the VM session appeared to be treated as and performing as E-cores. This had the effect of causing extremely slow startup times for the VM OS and very sluggish performance of the virtual machine in general. Side channel mitigations did not affect performance here. My solution (I'll admit it's not a good one) of disabling the E-cores within the host's BIOS such that only P-cores were available to the host machine and therefore the VM solved the E-core problem. There were the odd times where the virtual machine fired up with E-cores available on the host and the VM ran fine, but these were few and far between.

 

Regardless of E-cores enabled or not, on the "good" runs of the VM, there were still hangs and freezes of the virtual machine usually under an hour of the VM being powered on. These hangs required the VM to be hard reset (unable to guest power down or cycle at all) each time, but the host computer was unaffected and fully functional every time during VM hangs. My initial steps were to update the host BIOS and graphics drivers to their latest versions. Toggling Accelerating 3D graphics did not affect performance regardless of enabled or disabled. These updates (BIOS and graphics driver) reduced the frequency of the virtual machine hangs, however the one big thing that seems to have had the most effect was to disable the fast boot option on the host machine. I noticed the times when the VM would really struggle was when the host computer was powered back up beginning the next day, and the uptime metric in the task manager's performance tab suggested that the host machine had been powered on for over 24 hours. Since I've disabled fast boot on the host (and only run on P-cores), the VM is finally performing well about 99% of the time.

 

I still have some lingering hangs with video playback, or anything that seems to really engage the graphics processor (note, I'm only using Intel's onboard graphics bundled with their Alder Lake processors). I believe there is still some work that needs to be done on the graphics side of things as well as work to be done with E-cores enabled on the host and available for the virtual machine to use. Hopefully this helps others out with similar problems!

1 Reply
TimothyHuckabay
Enthusiast
Enthusiast

In my IT world, 99% uptime / proper performance is ABSOLUTELY UNACCEPTABLE!  And there is NO excuse for VMware to have failed to properly handle Intel's big.little architecture (in CPUs with P and E cores) after three years of development work on Workstation 17.  Moreover, nvme performance is still garbage, and it remains to be seen how well the updated virtual display adapter is detected and performs with photo and video editing products generally.  But I'm especially disappointed that big.little remains unaddressed.  I've used VMware's products since the release of Workstation 2, and VMware is now failing as a company in my view.  Broadcom's acquisition will only make things worse, if that's not already occurred.  VMware needs to revamp its management.

0 Kudos