Azure MANA NIC Rollout: Could It Impact Your Aviatrix Gateways?

If you run Aviatrix on Azure, there is a slow-moving infrastructure change happening underneath your gateways right now that is worth paying attention to. Microsoft started rolling out a new generation of network hardware on May 26, 2026, called MANA (Microsoft Azure Network Adapter). For most Azure workloads, the change is invisible. For network virtual appliances (NVAs) like Aviatrix gateways, it is not, and Aviatrix has issued a field notice (FN-2026-AZ-001) telling customers to take action.

What is MANA and Why is Microsoft Rolling it Out?

For roughly a decade, Azure VMs with Accelerated Networking enabled have used Mellanox-based NICs exposed to the guest as mlx4/5 SR-IOV adapters. SR-IOV (Single Root I/O Virtualization) lets the VM talk to the network card hardware directly, bypassing the hypervisor's virtual switch. This is what gives Accelerated Networking its low-latency, high-throughput characteristics.

Microsoft has been quietly building its own in-house networking silicon. MANA is the result: a Microsoft-designed network adapter that replaces the Mellanox hardware Azure has been using on the host side. From an Azure customer's perspective, MANA preserves Accelerated Networking semantics, but the device the guest OS sees is different. The driver is different. The interface name is different. And that is where Aviatrix gateways run into trouble.

Why Aviatrix Gateways Are Affected

Aviatrix gateways are not generic VMs. They run a custom data plane that binds tightly to the underlying NIC for performance reasons. Specifically, the gateway image expects the Mellanox driver to be present and operational. On MANA hardware, that driver is no longer in play, and the gateway image does not yet include a MANA-aware driver.

Per the field notice, the symptom is intermittent performance degradation rather than an outright outage. That makes it harder to detect: throughput drops, latency spikes, or session resets that look like noise can be the early signs of a gateway that landed on MANA hardware after a redeployment.

What is affected:

• All Aviatrix gateway types on Azure: Transit, Spoke, and Specialty Gateways, plus their HA peers
• Across the Intel v5, V6/Cobalt 100, and V2-V4 VM families
• Aviatrix versions 8.0.x through 9.0.x and earlier

What is not affected:

• Aviatrix Controller and CoPilot instances running in Azure. These don't forward actual traffic, they are not in the data plane, so the driver mismatch does not impact them.

Which Azure Regions are Live Today?

Microsoft is rolling MANA out region by region, starting in late May 2026. As of this writing, the field notice lists the following:

Additional regions are being announced via Azure Service Health under Tracking ID 5RWW-K4G. If your subscription has gateways in any Azure region, it is worth subscribing to that Service Health alert.

The hard deadline is August 1, 2026. Microsoft has stated that on this date, the global cutover happens, and any V2 through V5 family VM may land on MANA hardware in any region. After this date, even regions not yet listed can rehost your gateway on MANA-backed hosts during a routine service-healing event.

When Does a Gateway Land on MANA Hardware?

The exposure is not just about deploying new gateways. Per the field notice, any of the following operations can place a gateway VM on a MANA-backed host:

• New gateway provisioning
• VM restart
• Redeployment
• Image upgrade
• Scale operations
• Azure service-healing events
• Manual administrator actions through Controller, CoPilot, or the Azure portal

In other words, any lifecycle event that recreates the underlying VM is a chance for it to land on the new hardware. That includes events you didn't trigger, such as Azure moving a VM for host maintenance.

How to verify if you are already on MANA hardware

As per Microsoft article, using the command lspci:

$ lspci
7870:00:00.0 Ethernet controller: Microsoft Corporation Device 00ba

If you see Microsoft Corporation Device 00ba, then your VM is using MANA.
If you see anything else, for example Ethernet controller: Mellanox Technologies, you are on legacy hardware.

Of course with Aviatrix, this is not easy to check, since Aviatrix customers can't directly SSH to their Gateways, but as an Aviatrix customer, I can say their Support is super-helpful and they can check it fairly quickly.

The Short-Term Mitigation: The LegacyVMNVA Tag

Microsoft is providing an opt-out mechanism specifically for NVA workloads: a tag called LegacyVMNVA. When this tag is set to true on a VM, Azure's placement logic keeps the VM on legacy Mellanox-backed hardware instead of moving it to MANA-backed hosts.

Aviatrix's recommendation is to apply this tag via Azure Policy rather than directly on each VM. The reason is important: Aviatrix gateway lifecycle operations (redeploy, upgrade, HA replacement) often recreate the underlying VM, and a tag set manually does not survive that recreation. A policy-enforced tag does, because the policy reapplies it on the new VM.

How to Apply the Mitigation

1. Assign the Azure Policy at Management Group or Subscription scope.

The policy definition ID is:

e87a87f5-e6dd-4919-be21-abb0a4ea4630

Set the Tag Value parameter to true. Scope the assignment to the management group or subscription that contains your Aviatrix gateway VMs.

2. Activate the tag on existing VMs.

The policy applies the tag to newly created VMs automatically, but existing gateway VMs need a one-time push to pick it up. Aviatrix recommends doing this in a maintenance window using either:

• az vm reapply (preferred, no downtime if you have HA pairs and reapply one at a time)
• A stop-deallocate-start sequence

Either method triggers Azure to register the tag and update placement behavior for that VM.

3. Do not apply the tag manually.

The field notice is explicit on this: do not set the LegacyVMNVA tag directly via the Azure portal, CLI, or PowerShell as a standalone action. Doing so will work until the next gateway lifecycle operation rebuilds the VM, at which point the tag is gone and the new VM is free to land on MANA hardware. Always use Azure Policy so the tag is re-applied automatically on every VM in scope.

The Long-Term Fix: MANA-Compatible Releases

The tag is a workaround, not a final fix. Aviatrix is shipping MANA-compatible releases over Summer 2026:

The other hard deadline is May 31, 2027. On that date, Microsoft disables the LegacyVMNVA tag entirely. Any Aviatrix gateway still running a non-MANA-compatible release at that point will be subject to MANA placement and the associated performance degradation. Aviatrix is explicit about not waiting until the last days before the deadline to upgrade.

A Practical Timeline

If you are running Aviatrix on Azure today, the rough plan for the next 12 months looks like this:

1. This week: Subscribe to Azure Service Health Tracking ID 5RWW-K4G. Check whether your gateways are in any of the four currently-live regions.
2. Before August 1, 2026: Apply the LegacyVMNVA Azure Policy at the appropriate scope and activate the tag on all existing gateway VMs.
3. Summer / Autumn 2026: Plan the upgrade to the MANA-compatible release for your gateway version stream. Test on a non-production environment first if you can.
4. Well before May 31, 2027: Complete the fleet-wide upgrade using the CoPilot Upgrade Groups feature. Decommission the legacy tag once your fleet is fully on MANA-compatible code.

The reason to start now, even if your regions are not yet live, is that once a region is migrated to MANA-backed infrastructure, future gateway lifecycle operations may place VMs on the new hardware unless the mitigation is applied.

Wrapping Up

If you have only ever thought of Accelerated Networking as a checkbox in the VM creation flow, this rollout is a reminder that the hardware under the abstraction does change, and it can change in ways that matter to specialized workloads. For most VMs, MANA is transparent. For NVAs binding to a specific NIC driver, it is not.

The good news is that the mitigation is straightforward, the long-term fix is on the roadmap, and Aviatrix has given customers a year of runway before the legacy escape hatch closes. The bad news is that "intermittent performance degradation" is the kind of symptom that gets misdiagnosed in production for weeks before anyone connects it to an Azure hardware change. The best decision is to apply the policy now, while the rollout is still small.

Source: Aviatrix Field Notice FN-2026-AZ-001

Azure Network Adapter Overview

Azure MANA support for NVAs