Hyper-V: Installing Nasuni in Azure Local

Overview

Azure Local is a hyperconverged infrastructure (HCI) operating system delivered as an Azure service. It provides security, performance, and hybrid capabilities, including Azure Arc enablement and management through the Azure portal.

Tip: For more information on Azure Local, see Azure Local solution overview.

Tip: For further information on deploying Azure Local, see Deploy the Azure Local operating system.

Important: Deploying Nasuni on Azure Local is not available as a native Azure Marketplace image. Unlike standard Azure Marketplace offerings, such as Windows Server or Linux distributions, a Nasuni Edge Appliance cannot be deployed directly. The supported approach for Azure Local is a nested deployment using Hyper-V. In this configuration, Hyper-V runs as the primary hypervisor within the Azure Local environment, and the Nasuni appliance is deployed as a guest virtual machine (VM) inside Hyper-V using the certified Nasuni Microsoft Hyper-V VHD image. This nested setup allows the Nasuni virtual machine to operate fully within the Azure Local environment while providing all of Nasuni’s cloud-integrated file services.

Prerequisites

Before installing Azure Local, ensure that the following prerequisites are in place:

An Azure account subscription.
An Azure catalog-certified server. For more information, refer to the Azure Stack HCI requirements.
Install and configure the Azure Local (formerly Azure Stack HCI) operating system. For more information, see Install the Azure Stack HCI operating system

Installed and configured Windows Server virtual machine to run Hyper-V within the Azure Local HCI cluster node.

Tip: Nested virtualization is supported from Windows 2016 onwards.

Tip: Ensure nested virtualization is enabled, since Nasuni can only run as a Guest virtual machine within Hyper-V using a certified Nasuni Edge Appliance Microsoft Hyper-V VHD image.

Tip: To enable the virtual machine for nested virtualization, use this command:
Set-VMProcessor -VMName "VMName" -ExposeVirtualizationExtensions $true
Get-VMNetworkAdapter -VMName "VMName" | Set-VMNetworkAdapter -MacAddressSpoofing On
Where:
VMName is a name for the virtual machine.
ExposeVirtualizationExtensions specifies whether the hypervisor should expose the presence of virtualization extensions to the virtual machine, which enables support for nested virtualization.
MacAddressSpoofing specifies whether virtual machines can change the source MAC address in outgoing packets to one not assigned to them. Allowed values are On (allowing the virtual machine to use a different MAC address) and Off (allowing the virtual machine to use only the MAC address assigned to it).

This guide assumes that Hyper-V is installed and configured on a Windows Server Host. For more information, see Installation of Microsoft Hyper-V.
Access to the certified Microsoft Hyper-V VHD image for the Nasuni Edge Appliance. For more information, see Nasuni Portal.

Deployment considerations and guidelines

This section serves as a deployment guideline. It is imperative to ensure that the following workflows are completed accordingly. Otherwise, this might have an impact on outbound connectivity to the public Internet via NAT (Network Address Translation), which is a requirement when running Nasuni appliances, because this requires internet connectivity to communicate with the NOC.

Tip: Your nested Nasuni virtual machines need to connect to the Internet or other Azure resources. However, due to restrictions on the network fabric, it is not possible to create an external switch and give virtual machines direct access to the Azure Local host’s physical network.
A solution to this restriction is to configure NAT (Network Address Translation), so that virtual machines can access the Internet with the host NAT public IP, and also routing to enable connectivity to other virtual machines in Azure.
This document describes the following:
The process of configuring an Azure Local (formerly Stack HCI) cluster node.
Enabling nested virtualization support for the Hyper-V host.
Configuration of the nested virtual machine’s networking requirements (NAT in particular).
Other best practices to ensure seamless installation and configuration of Nasuni appliances running in Azure Local.

Hyper-V virtual machine configuration workflow

The following provide additional guidance on configuring the Hyper-V components required for deployment with Nasuni.

Create and configure a virtual switch in Hyper-V (External, Internal or Private). For details, see https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines.
Set up a NAT virtual network (internal vSwitch + NAT) on Hyper-V host. For details, see https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network.
Use NAT-enabled virtual switch to give VMs internet or outside connectivity through the host.
Configure NAT port-forwarding or static mappings on Hyper-V NAT or NetNat (if inbound access to nested VMs is needed). For details, see https://petri.com/create-nat-rules-hyper-v-nat-virtual-switch/.
General guidance: Use Hyper-V virtual networking best practices including NAT-switch design, switch-type selection, isolation vs external connectivity, VLAN or virtual switch management.
Deploy and manage VMs on Azure Stack HCI (i.e., how to create or manage VMs in HCI cluster). For details, see https://docs.azure.cn/en-us/azure-local/manage/vm-powershell.

Add a second NIC (Network Interface Card) to the Hyper-V host.
Create subnet on the Azure VNET.
Enable IP Forwarding on the Hyper-V NIC.
Create a Network Address Translation (NAT) vSwitch for outside connectivity.
Set up the Routing and Remote Access Service (RRAS).
The Routing and Remote Access Service (RRAS) is a Windows Server feature that allows a server to function as a network router and to provide remote access to a private network, most commonly via VPNs. Routing enables the server to direct traffic between different networks, while remote access allows users to connect to the network from a remote location as if they were directly connected to the local network.

Virtual Network requirements for Nasuni Edge Appliance or NMC

Two virtual networks (VNETs), each containing its own subnet, are required.

LAN subnet – Use this subnet to host LAN traffic, including communication with other Azure virtual machines or Nasuni appliances.
Internet subnet – Use this subnet for outbound Internet traffic, where traffic is routed through a NAT.

The following illustrates how this can be achieved and configured within the customer environment.

For example:

Default VNET - 10.14.0.0/16 (Main Address space)
NAT Subnet - 10.14.1.0/24
LAN Subnet - 10.14.0.0/24

Creating the Hyper-V Host

To create the Hyper-V host, follow these steps:

Create a Hyper-V virtual machine. This is your Hyper-V host to run the Nasuni nested environment.
Connect the first network adapter to the NAT subnet as you build the virtual machine.
NOTE: It is essential that the first adapter is connected to the NAT subnet, because all outbound traffic is sent through the primary network interface by default.
After the virtual machine is provisioned, add a secondary network adapter and connect it to the LAN subnet.
Enable IP forwarding on the newly created secondary interface.

Hyper-V host configuration guidelines

NOTE: The information below is not intended to be a full step-by-step guide for deploying or configuring a Windows Hyper-V server. Instead, it outlines the key services required to successfully run the Nasuni-certified Microsoft Hyper-V image. For complete instructions on deploying Microsoft Hyper-V, refer to the Prerequisites section.

Considerations

DHCP Server Installation

The DHCP server automatically assigns IP addresses to devices on your network.

Installation command:

Install-WindowsFeature -Name DHCP -IncludeManagementTools

Hyper-V Installation

Hyper-V enables virtualization on your Windows Server.

Installation command:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

Note: The server might automatically restart after installation.

RRAS (Routing and Remote Access Service) Installation

RRAS provides network routing and VPN capabilities.

Installation command:

Install-WindowsFeature -Name Routing -IncludeManagementTools -Restart

Configuring RRAS

Command for routing only:

Install-RemoteAccess -RoutingOnly

Verification

After installation, verify each service using:

Get-WindowsFeature | Where-Object {$_.Installed -eq $true}

Tip: By default, after a VNET is created, Azure provides a default DNS and DHCP server, which handles the DNS and DHCP operations on the two subnets you have created.

Tip: Use DHCP to automatically assign IP addresses to the nested virtual machines. RRAS is used to route traffic between the nested virtual machines and other Azure virtual machines, as well as provide NAT for Internet access.

Virtual Switch configuration for Nasuni

Create a virtual switch that is used by the nested virtual machines as a bridge for NAT and Routing.

For example:

New-VMSwitch -Name "InternalNATSwitch" -SwitchType Internal 
New-NetIPAddress –IPAddress <IP_Address> -PrefixLength 24 -InterfaceAlias "vEthernet (InternalNATSwitch)"

Tip: Rename the network adapter names on the Hyper-V host to match the subnet names in Azure. This makes it easier to identify the networks when we are configuring routing. In this example, this is what the host network settings look like after creating the switch.

Configuring DHCP

You can create a DHCP scope to automatically assign IP addresses to the nested virtual machines, but this is optional, because you can manually assign IPs based on the subnet you have defined. When assigning the DNS server, ensure that you use Azure’s default DNS/DHCP server (168.63.129.16). For more information, see Configure DNS name resolution for Azure virtual networks.

Configuring RRAS

To configure RRAS, follow these steps:

Navigate to the Start menu and open the Routing and Remote Access console.
Under Server Status, right-click and select Configure and Enable Routing and Remote Access.
In the Routing and Remote Access Server Setup Wizard, click Next, and select Custom configuration.
Select NAT & LAN Routing and proceed to complete the configuration.
In the Routing and Remote Access window, navigate to IPV4, right-click NAT, and select New Interface.
Select the previously created interface that matches your NAT subnet and enable the following NAT options:
Click OK.
Configure static routes to route traffic from nested virtual machines to other virtual machines connected to the Azure virtual network.

Under IPv4, right-click static routes, select new static route, and create the following route:
Warning: The previous IP address ranges are examples. Ensure that you set the correct IP subnet ranges to match your customer environment.

This configuration enables the primary interface to respond to the traffic destined for it, avoiding the necessity of an asymmetric route.

Create a second route to route traffic destined for the Azure VNET. In this case, we are using 10.14.0.0/16, which encompasses our Nasuni VNET, including the Hyper-V LAN subnet.

At this point, our host is ready to assign IPs to the nested virtual machines automatically, and it can now also allow virtual machines to connect to the Internet with RRAS NATing the traffic.

Installing the Nasuni Edge Appliance on Azure Local

After successfully deploying the Hyper-V nested environment, complete the procedure by installing the Nasuni Edge Appliance using a certified Nasuni Microsoft Hyper-V image build. For detailed instructions, see: Hyper-V: Installing a Nasuni Edge Appliance or NMC.