Forum Discussion
b25110 Enabling nested virtualization will only be visible in PowerShell and WAC but not accepted
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
trying to add the feature manually
With these commands I cannot see the enablement of the feature
According to VMProcessor the feature is enabled. Same in WAC, says it is enabled.
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
MSBernsteinMicrosoft
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.- Good question I will try this on WS 2022 release and report back.
- Artem Pronichkin
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
- 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?- Artem Pronichkin
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.
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
