SOLVED

b25110 Enabling nested virtualization will only be visible in PowerShell and WAC but not accepted

MVP

I have created new VMs with WAC 2110.2 GA and enabled Nested Virtualization

Trying to create an Azure Stack HCI cluster with AzStack HCI 21H2 on WS vNext b25110.

 

Problem:

Nested virtualization is enabled and visible in PowerShell via Get-Processor but installing Hyper-V on the nested VM is not possible. Also the AzStackHCI Cluster Creation Wizard fails with an error.

 

Both Install-WindowsFeature and the wizard behave as if Nested Virtualization is not enabled.

 

Expected behaviour:

According to the settings the requirements are set and as such it should be possible to install Hyper-V on the VMs.


Error in WAC Cluster Creation wizard

 

K_WesterEbbinghaus_0-1652920165443.png


trying to add the feature manually

 

K_WesterEbbinghaus_1-1652920271593.png


With these commands I cannot see the enablement of the feature 

K_WesterEbbinghaus_2-1652920311054.png


According to VMProcessor the feature is enabled. Same in WAC, says it is enabled.

K_WesterEbbinghaus_3-1652920478215.png

 

K_WesterEbbinghaus_0-1652920888085.png

 

 

10 Replies
Quick question: is this a regression in behavior? If so, do you know the last version where this was working?

It's expected that Windows Admin Center and PowerShell would expose the same data - we do try hard to keep them in sync.
best response confirmed by Karl-WE (MVP)
Solution

Hi Karl! Thanks for trying Azure Stack HCI!

 

The short answer is what you're seeing is actually expected. The reason is that officially, Azure Stack HCI is only supported on physical hardware. And in some nuances, it's not the same as nested virtualization. More specifically, because Virtual Secure Mode (VSM) is enabled by default, that "hides" necessary virtualization extensions from the Hyper-V compatibility checker. That said, if you use Enable-WindowsOptionalFeature, it will bypass the compatibility checker and should successfully enable Hyper-V. So, try this:

Enable-WindowsOptionalFeature -Online -FeatureName 'Microsoft-Hyper-V'

Here's a slightly longer explanation for those curious: https://twitter.com/pronichkin/status/1294308601276719104

 

 

Good question I will try this on WS 2022 release and report back.
Hi Artem thanks for taking time for a good explanation.
You're welcome I am working on my Hybrid Administrator, so AzSHCI is something I strive for.

So, should I enable Hyper-V on the VM where AzSHCI is installed?
I know and understand some features named differently on Windows Client and Server and how you enable / disable them with PS differs from version to version. Wonder why Install-WindowsFeature and Enable-WindowsOptionalFeature is not the same on Windows Server though.
When using dism, would it have differences?

Enable-WindowsOptionalFeature is part of the DISM module for PowerShell. It uses the same underlying mechanisms (that is, DISM APIs) as DISM.exe. As such, it shares the same feature names (e.g. Microsoft-Hyper-V) with DISM.exe, and the same behavior. This behavior is very basic, these tools merely do what they're told. I.e., put features into enabled or disabled state. Also, this cmdlet is available on both Windows client operating systems (such as Windows 10 and Windows 11), as well as server operating systems (such as Windows Server and Azure Stack HCI.)

 

In the other hand, Install-WindowsFeature is part of the Server Manager module for PowerShell. (Fun fact: in some older operating systems it was called Add-WindowsFeature, which is now an alias.) Just like Server Manager itself, this cmdlet can only be used to manage server operating systems. (Even though you can install it on Windows 10/11 as part of RSAT.) This cmdlet is somewhat more advanced comparing to Enable-WindowsOptionalFeature. For instance, it can be used over network, against a remote machine. Or offline, against a VHD(x) file. Another difference is that it uses slightly different feature names, e.g. "Hyper-V." (Also, not all features are available here, but only those which are visible in Server Manager as Server Roles, Role services or Server features.)

 

But most importantly, Install-WindowsFeature cmdlet (just like Server Manager itself) tries to prevent you from shooting yourself in the foot, by running prerequisite checks and post-installation tasks, where applicable.

 

For these reasons, in general, we recommend always using Install-WindowsFeature when you're managing server operating systems such as Windows Server or Azure Stack HCI. However, because this cmdlet is so advanced and trying to be helpful, it might not always work for niche and unsupported scenarios, such as enabling Hyper-V on Azure Stack HCI when running in a VM. (As I explained earlier, this is specific to this exact scenario. E.g. you won't face these issues when managing a physical machine running Azure Stack HCI, or a virtual machine running Windows Server.)

 

So, for those scenarios, you can use Enable-WindowsOptionalFeature as a workaround.

That makes sense. Thank you Artem I will try the command and report back.

@Artem Pronichkin @MSBernstein can confirm this is the issue. WAC cluster creation does not use Enable-WindowsOptionalFeature, doing so manually solves this blocker. 

Mr. Bernstein, I believe it is not worth the time, considering the guidance from Artem, to test with previous versions, as the behaviour is not OS based but rather part of the cluster creation WAC module. 

 

I will add this to the MS ToDo list shared with the WAC team and see if they want to change this. Otherwise I could imagine that Trung is not responsible for the module, eventually @EldenChristensen ? 

K_WesterEbbinghaus_0-1653644559170.png

 

 

Passing the suggestion to the WAC team makes sense. I imagine there is some tension between wanting Windows Admin Center to support all possible scenarios, but also wanting to keep Windows Admin Center in sync with the protective checks that Artem described.

"But most importantly, Install-WindowsFeature cmdlet (just like Server Manager itself) tries to prevent you from shooting yourself in the foot, by running prerequisite checks and post-installation tasks, where applicable."

Happy new year @Artem Pronichkin @MSBernstein the procedere this still the same in WAC 2311.
I raised this feedback to the WAC team or who else the Cluster (creation) extension.

https://feedback.azure.com/d365community/idea/a9268101-e0ac-ee11-92bc-000d3ae54955

1 best response

Accepted Solutions
best response confirmed by Karl-WE (MVP)
Solution

Hi Karl! Thanks for trying Azure Stack HCI!

 

The short answer is what you're seeing is actually expected. The reason is that officially, Azure Stack HCI is only supported on physical hardware. And in some nuances, it's not the same as nested virtualization. More specifically, because Virtual Secure Mode (VSM) is enabled by default, that "hides" necessary virtualization extensions from the Hyper-V compatibility checker. That said, if you use Enable-WindowsOptionalFeature, it will bypass the compatibility checker and should successfully enable Hyper-V. So, try this:

Enable-WindowsOptionalFeature -Online -FeatureName 'Microsoft-Hyper-V'

Here's a slightly longer explanation for those curious: https://twitter.com/pronichkin/status/1294308601276719104

 

 

View solution in original post