***** If Accelerated Networking (AN) is not enabled on your VM, no action is required ******
As Azure expands Microsoft Azure Network Adapter (MANA) support to existing VM series, Versa-certified Fs* and Fsv2* VOS workloads are uniquely impacted due to their direct dependency on the underlying network hardware, drivers, and minimum DPDK version.
For all deployments going forward — especially new ones — Versa recommends Dadsv5 (AMD-based) instances instead of Fsv2* (Intel-Based).
AMD CPU based instances will not be moved to MANA capable hardware.
| Current Certified VM | Recommended Replacement |
|---|---|
| Standard F8s v2 | Standard_D8ads_v5 |
| Standard F16s v2 | Standard_D16ads_v5 |
| Standard F32s v2 | Standard_D32ads_v5 |
| Standard F64s v2 | Standard_D64ads_v5 |
*******Only Intel based CPU instances from v1-v5 versions are impacted by this MANA transition*****
Once customer moves to recommended AMD based Instances Dadsv5 series above, customers don't need to add tag and these VMs will not be moved to MANA hardware.
There is no functional and performance impact on moving from Intel to AMD in above table.
Native MANA support may be introduced as part of the VOS 23.1.3 (Jammy) or later release (still under development). This cannot be backported to Bionic-based VOS releases due to a minimum kernel version requirement.
LegacyVMNVA must be applied at different levels depending on how the VM was originally deployed. Please refer to the official Microsoft page for details, and follow up with Microsoft Support if you have questions specific to your deployment.
Q. Where should I apply this tag?
A. Based on Microsoft's guidance, LegacyVMNVA tag should be applied to the individual VM or to the Virtual Machine Scale Set (VMSS), depending on the deployment model, please refer to Microsoft advisory for full details.
Q. What is the sequence of steps for reference?
A. You must first add tag and Reapply (this is not service disruptive).
[[ Steps to be followed if you have access to Azure Portal ]]
Step-1 : Add TAG
Step-2 : Reapply
[[ Reference commands for same with Azure CLI ]]
Step-1 - Add tag to all of your VMs
az vm update -g <resource-group> -n <vm-name> --set tags.LegacyVMNVA=True
Step-2 - Reapply
az vm reapply -g <resource-group> -n <vm-name>
Q. What happens if a customer forgets to add the LegacyVMNVA tag before the deadline?
A. Microsoft does not guarantee VM placement on non-MANA hardware. If the VM lacks MANA driver support, the interface automatically falls back to the NetVSC synthetic adapter. On VOS, non-AN (non-accelerated) interfaces are a known limitation — VOS services may be disrupted or become unreachable and are not guaranteed to work, as Versa doesn't certify NetVSC interfaces due to their poor network performance.
Q. If a customer wants to bring up a new VM after the deadline, what should they do?
A. Use the Recommended Replacement instance from the table above, based on the existing VM model.
Q. Does this apply to Versa Director and Versa Analytics?
A. This applies to Versa-certified Azure VMs where Accelerated Networking is enabled. Director and Analytics are not directly impacted, as Versa does not enable or recommend Accelerated Networking for these components.
Q. What happens if Accelerated Networking was enabled on Director or Analytics, by mistake or intentionally?
A. If the underlying OS doesn't support the MANA driver, networking automatically falls back to the NetVSC synthetic adapter. Since Director and Analytics don't rely on a DPDK-based dataplane the way VOS does, they should continue to function as before.
Q. What if Accelerated Networking (AN) is not enabled on any interface of VM?
A. If AN is not enabled, the MANA migration does not affect those deployments, and the LegacyVMNVA tag is not required.
Q. I forgot to add tag before 1 Aug 2026 deadline and one of VM lifecycle moved my instance to MANA based hardware, will adding tag now and reboot bring back to non MANA hardware?
A. No. If a VM has already moved to MANA-capable hardware, adding the LegacyVMNVA tag afterward will not move it back and should not be considered a recovery mechanism. The tag is designed as a preventive opt-out to avoid future placement on MANA-capable hardware, not as a rollback mechanism.
Q. Is it possible to migrate a VM from Intel-based Fsv2* to AMD-based Dadsv5?
A. Technically, it's possible to move with manual intervention and access to the remote console in the Azure Portal, but this is not the certified, recommended path. This should be considered a last resort option, and stability is not guaranteed, as there can be a lot of unknowns over time.