May 18 2022 05:36 PM - edited May 18 2022 05:43 PM
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.
May 19 2022 08:05 PM
May 19 2022 08:27 PM
SolutionHi 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
May 21 2022 01:29 PM
May 21 2022 01:33 PM
May 21 2022 02:54 PM
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.
May 22 2022 07:34 AM
May 27 2022 02:44 AM - edited May 27 2022 02:45 AM
@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 ?
May 27 2022 08:11 AM
May 28 2022 06:29 AM
Jan 06 2024 02:18 PM - edited Jan 06 2024 02:19 PM
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
May 19 2022 08:27 PM
SolutionHi 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