Here at Droplet, we leverage several different performance extensions for our container technologies. These are very much tied to their respective platforms. On Microsoft Windows, we leverage WHPX whereas on Apple macOS and Chromebook we leverage HVF and KVM respectively. All of these different hardware accelerators essentially do the same thing – they give us access to the underlying Intel VT or AMD-V extensions which improve performance. Historically, these attributes on the chip we implemented to improve performance for virtualization – but they also drive performance improvements for emulators like Android Studio and container technology like Droplet Computing. Microsoft does have a couple of different names for WHPX – whose full name is “Windows Hypervisor Performance Extensions”. These are a collection of APIs/SDKs that vendors such as us can speak to get a performance boost. It’s not to be confused with Hyper-V which provides a full virtualization management layer and engine. All that WPHX provides is access to those Intel-VT/AMD-V attributes on the CPU chipset.
HVF and KVM are built-in and enabled by default in the world of Apple macOS and Chromebook, whereas on Microsoft Windows, WHPX needs to be enabled by the administrator. Of course, Microsoft provides a range of different ways of doing that using either the UI, command-prompt, or PowerShell. Enabling WHPX from the UI involves navigating to >Control Panel >Programs and Features >Turn Windows features on and off and placing a tick in the box next to “Windows Hypervisor Platform”.
Please note, that all the UI doesn’t state it – we would recommend a reboot once applied.
So that’s great for demo purposes and in simple trials – but no administrator worth their salt wants to be running around their environment doing this through the UI. So there are ways thru the command-prompt or PowerShell by which this process can be enabled. Usually, I include these processes at the end of the scripting process – because I can finish off the script with a reboot – leaving the Windows PC or virtual desktop ready in a state to be used for Droplet containerized apps.
From Command-Prompt:
You can use the dism command to enable the feature. This is simple “one-liner” format that will appeal to those who prefer easy DOS-based batch (.bat / .cmd) scripts. In case you don’t know DISM stands for the “Deployment Image Servicing and Management” tool:
dism /online /enable-feature /featurename:HypervisorPlatform
Notice how in the command-line tool the name is different again – not WHPX, Windows Hypervisor Platform, but merely “HypervisorPlatform”. DISM is clever enough to know if WHPX or any service has already been enabled before, and so won’t try anything illogical like trying to enable the same thing twice.
From PowerShell:
PowerShell is my main CLI of choice, even if I might use a simple batch file to my PS scripts together as a single setup.cmd. What PowerShell brings to the table is the ability to include IF statement logic in the script environment.
$featureName = ‘HypervisorPlatform’
$Feature = get-wmiobject -class Win32_OptionalFeature | where {$_.Name -eq $featurename}
If ($feature.InstallState -eq “1”)
{
write-Host $featureName “is installed”
}
Else {
Write-Host “Not installed”
Enable-WindowsOptionalFeature -Online -FeatureName $featureName
shutdown /t 600 /r /c “Restarting Windows 10 within the next 10mins to enable Microsoft WHPX”
}
The nice thing about a script like above is I can reuse it time and time again, by simply changing the string for $featureName – but also use tools like WMIobject to verify if WHPX has already been enabled.
Once WPHX has been enabled hardware acceleration can be enabled in our software, and you verify its presence in the UI:
Now for some caveats….
When we talk about “hardware acceleration” or “performance extensions” there are some things to bear in mind.
Firstly, and most importantly, how significant are those performance differences? Well, it can be measured in seconds – with hardware extensions enabled the login process to the container can be as little as 3-4, with subsequent applications opening in less than a second. Without hardware acceleration, the login process is more like 8-9 seconds, with subsequent applications loading in less than a second. So, we are only talking about seconds worth of difference which is unlikely if ever to result in any ‘productivity gains – it’s more about delivering the best user experience.
Secondly, where it pays dividends are in our older 32-bit containers, rather than our 64-bit containers. We find that hardware acceleration is less impactful on our 64-bit containers mainly because a 64-bit container on a modern 64-bit OS running on 64-bit hardware has all its performance ducks in a row. For this reason, we tend to use our 32-bit container in a traditional Windows PC model where one user runs one container. Whereas we tend to use our 64-bit containers in Windows WVD and Citrix Virtual Apps where one container services the needs of many users – and where the additional scalability of 64-bit works – because of the larger addressable memory and CPU. Although we can run with hardware acceleration in environments like Windows WVD, often the scalability and resource efficiencies win out over raw performance, especially when you’re talking about a couple of second differences.
Thirdly, and finally – Windows 10 versions. We support Windows 10 1909 or higher with WHPX. There is a known issue with WHPX on 1809 or later which has known conflicts with Microsoft’s Device Guard and Windows virtualization-based Security (VBS).