Azure Local 24H2: Creating VM network interface fails when specifying MAC address outside 02:ec:00:0b range

Question

Azure Local 24H2: Creating VM network interface fails when specifying MAC address outside 02:ec:00:0b range

Kenny L 25

Hi

We're attempting to migrate a VMware VM or physical server workload to an Azure Local VM enabled by Azure Arc.

During migration, we want to preserve the original source NIC MAC address. However, when we create an Azure Local VM network interface with Azure CLI and specify the source MAC address, the request fails because the MAC address is outside the Azure Local/MOC-managed range.

Example command:

az stack-hci-vm network nic create `
    --subscription <subscription-id> `
    --resource-group <resource-group> `
    --custom-location <custom-location-id> `
    --location <location> `
    --name "alma93-vm02a-nic-1" `
    --subnet-id "ManagementLnet-static" `
    --ip-address 10.0.0.119 `
    --mac-address 00:50:56:aa:d0:7c

Error returned from Azure CLI:

Screenshot 2026-06-29 at 6.57.03 PM

I'd like to confirm whether Azure Local VM network interfaces created through Azure Arc VM management require MAC addresses to be within 02:ec:00:0b:00:00 to 02:ec:00:0b:ff:ff.

If this range is enforced by design, is there any supported configuration to override it so that a migrated VM can preserve its original source MAC address?

0 comments

Answer accepted by question author

Jerald Felix 18,760 Volunteer Moderator

Hello Kenny Law,

Greetings! Thanks for raising this question in the Q&A forum.

The behavior you're seeing is expected and by design in Azure Local 24H2. When you create a network interface through az stack-hci-vm network nic create, the MAC address isn't handed off directly to Hyper-V. It first goes through the Arc-enabled VM management stack, which is backed by MOC (the on-premises orchestration layer for Azure Local). MOC enforces MAC addresses to come from its own locally administered pool, and the 02:ec:00:0b:00:00 to 02:ec:00:0b:ff:ff range you're seeing is that reserved pool. This exists to guarantee MAC uniqueness across all VMs on the cluster and to avoid collisions when VMs move between nodes, so it isn't something you can extend or override through the CLI or ARM API.

To directly answer your questions:

Yes, this range is enforced by design Any --mac-address value passed to az stack-hci-vm network nic create (or the equivalent ARM REST call) must fall inside the MOC-managed pool. Values outside that range, including real hardware or VMware sourced MAC addresses, will always be rejected at validation time.

There is currently no supported way to override it This is confirmed in Microsoft's own Azure Migrate FAQ for Azure Local, which states plainly that preserving the source MAC address (for example, to keep a DHCP reservation working) is not supported in the current release. This applies broadly to migrations into Azure Local, not just to manual NIC creation through the CLI.

Given that, here is how most teams handle this during a VMware or physical to Azure Local migration:

Plan for a new MAC address on the target VM Treat the Azure Local assigned MAC as the new identity for that NIC going forward. Update any DHCP reservations, static ARP entries, or firewall/NAC rules tied to the old MAC to use the new one, or switch those systems to use IP based reservations instead where possible.

Use static IP preservation instead of MAC preservation Azure Local 24H2 does support preserving the source VM's static IP address during migration for Windows VMs on VMware and Hyper-V (Linux is not supported for this). If your real requirement is "the VM keeps working at the same IP address" rather than specifically the same MAC, this path is supported today.

az stack-hci-vm network nic create `
    --subscription <subscription-id> `
    --resource-group <resource-group> `
    --custom-location <custom-location-id> `
    --location <location> `
    --name "alma93-vm02a-nic-1" `
    --subnet-id "ManagementLnet-static" `
    --ip-address 10.0.0.119

If MAC based licensing is the real blocker If the reason you need the original MAC is a third party application license tied to that address, this is a common pain point and worth raising directly with the vendor for a re-host or re-key, since Azure Local, like Azure IaaS, does not support arbitrary MAC assignment for exactly this reason.

If your workload absolutely cannot function without the original MAC Submit feedback through the Azure Local product feedback channel so the product group can track demand for this capability, since it is explicitly called out as unsupported in the current release rather than something that will never be revisited.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

0 comments

2 additional answers

Your answer

Answer 1

Kenny L 25

Hi Jerald,

Much appreciate for your quick answer and the details you've given in terms of how others would have handled this when migrating virtual or physical host to Azure Local. It's very helpful.

Thanks again and regards,

Kenny

0 comments

Answer 2

{"locale":"en-us","body":"Hello**KennyLaw,\n\nGreetings!ThanksforraisingthisquestionintheQ&Aforum.\n\nThebehavioryou'reseeingisexpectedandbydesigninAzureLocal24H2.Whenyoucreateanetworkinterfacethroughazstack-hci-vmnetworkniccreate,theMACaddressisn'thandedoffdirectlytoHyper-V.ItfirstgoesthroughtheArc-enabledVMmanagementstack,whichisbackedbyMOC(theon-premisesorchestrationlayerforAzureLocal).MOCenforcesMACaddressestocomefromitsownlocallyadministeredpool,andthe02:ec:00:0b:00:00to02:ec:00:0b:ff:ffrangeyou'reseeingisthatreservedpool.ThisexiststoguaranteeMACuniquenessacrossallVMsontheclusterandtoavoidcollisionswhenVMsmovebetweennodes,soitisn'tsomethingyoucanextendoroverridethroughtheCLIorARMAPI.\n\nTodirectlyansweryourquestions:\n\n1.Yes,thisrangeisenforcedbydesignAny--mac-addressvaluepassedtoazstack-hci-vmnetworkniccreate(ortheequivalentARMRESTcall)mustfallinsidetheMOC-managedpool.Valuesoutsidethatrange,includingrealhardwareorVMwaresourcedMACaddresses,willalwaysberejectedatvalidationtime.\n\nThereiscurrentlynosupportedwaytooverrideitThisisconfirmedinMicrosoft'sownAzureMigrateFAQforAzureLocal,whichstatesplainlythatpreservingthesourceMACaddress(forexample,tokeepaDHCPreservationworking)isnotsupportedinthecurrentrelease.ThisappliesbroadlytomigrationsintoAzureLocal,notjusttomanualNICcreationthroughtheCLI.\n\nGiventhat,hereishowmostteamshandlethisduringaVMwareorphysicaltoAzureLocalmigration:\n\nPlanforanewMACaddressonthetargetVMTreattheAzureLocalassignedMACasthenewidentityforthatNICgoingforward.UpdateanyDHCPreservations,staticARPentries,orfirewall/NACrulestiedtotheoldMACtousethenewone,orswitchthosesystemstouseIPbasedreservationsinsteadwherepossible.\n\nUsestaticIPpreservationinsteadofMACpreservationAzureLocal24H2doessupportpreservingthesourceVM'sstaticIPaddressduringmigrationforWindowsVMsonVMwareandHyper-V(Linuxisnotsupportedforthis).Ifyourrealrequirementis"theVMkeepsworkingatthesameIPaddress"ratherthanspecificallythesameMAC,thispathissupportedtoday.\n\n\ndockerfile\nazstack-hci-vmnetworkniccreate`\n--subscription<subscription-id>`\n--resource-group<resource-group>`\n--custom-location<custom-location-id>`\n--location<location>`\n--name\"alma93-vm02a-nic-1\"`\n--subnet-id\"ManagementLnet-static\"`\n--ip-address10.0.0.119\n\n\nIfMACbasedlicensingistherealblockerIfthereasonyouneedtheoriginalMACisathirdpartyapplicationlicensetiedtothataddress,thisisacommonpainpointandworthraisingdirectlywiththevendorforare-hostorre-key,sinceAzureLocal,likeAzureIaaS,doesnotsupportarbitraryMACassignmentforexactlythisreason.\n\nIfyourworkloadabsolutelycannotfunctionwithouttheoriginalMAC**SubmitfeedbackthroughtheAzureLocalproductfeedbackchannelsotheproductgroupcantrackdemandforthiscapability,sinceitisexplicitlycalledoutasunsupportedinthecurrentreleaseratherthansomethingthatwillneverberevisited.\n\nIfthisanswerhelpsyoukindlyaccepttheanswerwhichwillhelpotherswhohavesimilarquestions.\n\nBestRegards,\n\nJeraldFelix.\n\n","tagsGeneratedByAi":[false]}