AzS-HCI Cluster Creation, new SDN step in WAC wizard

Hi @keith ,

You don't need to deploy SDN just to allow comms in a nested environment. Instead, you'll need to enable MAC address spoofing within the Hyper-V settings of the nested VM, specifically on the NICs that are part of the Switch Embedded Team (SET) virtual switch inside the VM. After this, the vNICs behind the SET on the nested VMs should be able to communicate.

Hope this helps!

Unlike previous deployments, the new converged switch defaults new VMs to an APIPA address on a virtual switch ComputeSwitch with an IP address 169.254.190.128. During the deployment, it the ComputeSwitch didn't link with the InternalNat switch in HyperV.

Any ideas if there was something we mis-configured in the Network deployment definitions?

ComputeSwitch is External Type, shared with Management OS. We initially configured the IP address to be a static address on the InternalNat HyperV virtual switch i.e. 192.168.0.10/24.

Hi @keith ,

Please allow me to be sure I have a clear understanding of your setup.

2019 Hyper-V Host using a NAT'd virtual switch that is running an HCI VM.
The virtual NICs that are showing inside of the HCI VM properties are connected to the NAT'd virtual switch.
Then, inside of the HCI VM itself, you have another virtual switch (called ComputeSwitch) which was created by Windows Admin Center.
The virtual switch inside of the HCI VM has its own, separate virtual NICs that should allow the HCI VM to communicate with the external world.

If this is your setup, then please do confirm that the virtual NICs that show within the HCI VM properties are set to allow MAC Address Spoofing. The reason for this is because the VMs inside of the nested VM will require their own MAC addresses to be able to communicate. If you do not check the option to allow MAC address Spoofing, the hosting VM will not be allowed to change the MAC address on the outgoing data to that of the nested VM.

If you were to remove the virtual switch within the nested HCI VM, you would likely see VM communication would succeed without needing MAC address spoofing enabled. If you test with the virtual switch removed and you still do not have proper communication, I'd look further at the NAT switch configuration on the host.

Trent, recapping our deployment. We deployed the Nested deployment into a Windows Server 2019 Hyper-V host. We used the powershell scripts to deploy the AZSHCINODE01 & 02. During this deployment documentation, we deploy an InternNat Virtual Switch with the address 192.168.0.1 On this same 192.168.0.x network, we've deployed a Domain Controller x.x.0.253, WAC WinX @ x.x.0.250 and a DHCP server @ x.x.0.254.

When building the cluster, we get to the Network Settings page as we've done in the past, selecting interface "Ethernet" on both AZSHCINODE01 & AZSHCINODE02. When we get to the next network configuration, we select interface "Ethernet 2" on both VMs as our Compute Interface. When configuring the IP Addresses, we enter accordingly,

AZSHCINODE01:
Ethernet 2 192.168.0.6 24 192.168.0.1
Storage 1 10.0.1.1 16
Storage 2 10.0.2.1 16

AZSHCINODE02:
Ethernet 2 192.168.0.16 24 192.168.0.1
Storage 1 10.0.1.2 16
Storage 2 10.0.2.2 16

HCI Cluster IP 192.168.0.20

We were able to build the Clustered Volume with S2D enabled. Doesn't appear to be any issues there. On "Ethernet 2" adapters on both VMs, it created a Virtual Switch "ComputeSwitch" that doesn't appear to be connected to the Host HyperV Virtual Switch "InternalNAT".

Hope this helps clarify.

Hi @keith ,

I did some testing in my lab. I was able to successfully deploy a NAT switch on a 2019 Hyper-V Host. From there, I created an HCI VM with three adapters. My equivalent to your 'Ethernet 2' adapter was connected to the NAT switch within the VM properties. I first confirmed I had connectivity by running Test-NetConnection 8.8.8.8. This test succeeded. I also confirmed there was a NAT session on the host using Get-NetNatSession. I then added the virtual switch onto the HCI VM and performed the same testing. Again, this succeeded.

Without tracing or seeing the environment, it would be very difficult for me to pinpoint the actual issue. The virtual switch seems to be performing as it should considering you were able to create the cluster. That tells me communication is happening at least within the 192.168.0.x network. The NAT translation itself would be the responsibility of the 2019 host machine which may be where the problem lies.

Here's what I would do next:

• Confirm the NAT policy per Get-NetNat
• Confirm the IP address on the host vNIC is indeed in the same range as the NAT policy
• Remove the virtual switch from the HCI VM and test connectivity
• Delete the NAT policy and corresponding virtual switch and re-create them per https://video2.skills-academy.com/en-us/virtualization/hyper-v-on-windows/user-guide/setup-nat-network

If you have a Microsoft support agreement, feel free to open a case and we can assist you further.

Hope this helps!