HCX Bulk Migration Fails: "The MAC Address of the VM Belongs to the Reserved MAC Range" Explained and Fixed

VMware HCX troubleshooting

An HCX Bulk Migration with Retain MAC enabled fails validation with "The mac address of the VM belongs to the reserved mac range, retain mac is not supported for such vms". The VM's MAC address sits in a range VMware reserves for vSphere's own address allocation (prefixes 00:0C:29 and 00:50:56), so HCX will not carry it to the destination. You can fix it by giving the source VM a MAC address outside the reserved range, or by migrating without Retain MAC so the destination assigns a new one.

We see this error most often in estates that have been through several platform moves, physical-to-virtual conversions or hand-built VMs, where MAC addresses were typed in years ago and nobody has looked at them since. This guide explains how VMware allocates MAC addresses, why HCX refuses some of them, the two fixes and how to choose between them, and a related Retain MAC conflict that catches people on second migrations.

The exact error message

HCX reports the problem during migration validation, before any data moves. The mobility group shows a general failure followed by a per-VM reason:

One or more VMs have errors, cannot proceed with migration.
The mac address of the VM belongs to the reserved mac range, retain mac is not supported for such vms

Broadcom documents this in KB 316680 for HCX Bulk Migration with the Retain MAC option selected.

How vSphere assigns MAC addresses

A MAC address is six bytes. The first three are the Organizationally Unique Identifier (OUI) that identifies the vendor, and the last three identify the network adapter. VMware uses its OUIs in three different ways, and the difference explains why some addresses are safe to carry between environments and others are not.

Table 1. VMware MAC address ranges in vSphere.

Both prefixes are reserved for vSphere's own use. vCenter and ESXi hand out addresses from them and track what they have issued so that two VMs do not end up with the same one. An address that was generated by a different vCenter, or typed in by hand years ago, sits inside that space without the destination vCenter knowing where it came from.

Why HCX refuses to retain these MAC addresses

With Retain MAC selected, HCX creates the destination VM with the same MAC address as the source. That keeps DHCP reservations, MAC-based licences and firewall rules working after cutover, which is why it is popular for migrations that use Network Extension. The KB states that HCX cannot retain a MAC address from the VMware reserved range and blocks the migration at validation.

In our reading, the reason is collision risk. The destination vCenter allocates its own MAC addresses from the same reserved ranges. If HCX brought in an address from those ranges, the destination vCenter could later generate the same value for another VM, and two adapters with one MAC on the same Layer 2 segment cause intermittent packet loss that is very hard to trace. Refusing up front is safer than letting a duplicate surface weeks after cutover.

Fix A: change the source VM's MAC address

Use this when the destination VM must keep a fixed, known MAC address, for example because a licence server or a DHCP reservation is tied to it. You change the address once at the source, update whatever depends on it, then migrate with Retain MAC so the new value carries through.

1. Agree the new MAC address. If you want to stay in the VMware manual range, it must be between 00:50:56:00:00:00 and 00:50:56:3F:FF:FF. Check it is not already in use anywhere on the extended network.
2. Schedule a maintenance window and power off the VM. vSphere only lets you set a manual MAC address on a powered-off VM.
3. In the vSphere Client, select the VM, open Edit Settings and expand the network adapter.
4. Set MAC Address to Manual and enter the new address. Choose Automatic instead if you only need vCenter to generate a fresh one.
5. Update DHCP reservations, licence files, firewall objects and any guest network configuration bound to the old MAC, then power the VM on and test.
6. Rerun HCX migration validation for the mobility group.

If you still administer a much older ESXi host, you may find guidance that sets ethernetX.checkMACAddress = "false" in the VM's .vmx file to force a static MAC outside the allowed range. That workaround is from the ESXi 5.5 era and switches off the host's conflict check. We do not use it in migrations, because it hides exactly the duplicate-MAC problem HCX is trying to prevent.

Fix B: migrate without Retain MAC

Use this when nothing depends on the MAC address, which is true for most application servers that use static IP addresses or DHCP without reservations. In the mobility group, clear the Retain MAC option for the affected VM and rerun validation. HCX migrates the VM and the destination vCenter assigns a new MAC address from its own range. The source VM is not changed, so rollback is simple.

Table 2. Choosing between the two fixes.

A related failure: MAC conflicts on a second migration

A second Retain MAC problem shows up when you migrate the same VM more than once, for example after a test migration or a rollback. Broadcom documents it in KB 414407 for HCX with VMware Cloud on AWS. If the first migrated copy still exists in the destination vCenter, even powered off or renamed, the vCenter database still records its MAC address. The second migration cannot reuse that address and the destination logs a vim.event.VmMacConflictEvent.

The KB gives two ways to clear it before retrying:

• Remove the first migrated VM from the destination vCenter inventory.
• Or keep that VM but change its MAC address: in Edit Settings, remove the network adapter that holds the MAC, add a new adapter and connect it to the same port group or NSX segment.

In our experience this catches teams who run a test migration, power the copy off, roll back to the source and then try the real cutover a week later. Add "clean up test copies" to the cutover runbook.

Find affected VMs before the migration wave

You can find these VMs before validation does. This PowerCLI query lists every network adapter with a VMware-prefixed MAC address and how the address was assigned, so you can decide on Fix A or Fix B per VM during wave planning:

Get-VM | Get-NetworkAdapter |
  Where-Object { $_.MacAddress -match '^(00:0c:29|00:50:56)' } |
  Select-Object @{N='VM';E={$_.Parent.Name}}, Name, MacAddress,
    @{N='AddressType';E={$_.ExtensionData.AddressType}} |
  Sort-Object AddressType, VM |
  Export-Csv .\vm-mac-audit.csv -NoTypeInformation

The AddressType column shows manual for static MACs, assigned for vCenter-generated MACs and generated for host-generated ones. Manual entries and anything starting 00:0C:29 deserve the closest look, because they are the addresses most likely to have been set by hand or carried in from another environment. HCX validation remains the final word on which VMs it will accept with Retain MAC.

• MAC audit exported for every VM in the wave
• Each VM marked Retain MAC yes or no, with the reason
• Owners confirmed for anything tied to a MAC: licences, DHCP reservations, firewall objects
• Guest OS checked for configuration pinned to a hardware address
• Test migration copies removed from the destination vCenter before cutover

For other failure patterns and the logs to read, see our HCX migration failure troubleshooting guide, the HCX Bulk Migration guide and the 70-point HCX migration checklist.

Frequently Asked Questions about the HCX reserved MAC range error

Sources

• Broadcom KB 316680: HCX Bulk Migration fails with the error "The mac address of the VM belongs to the reserved mac range"
• Broadcom KB 414407: HCX migration extended option to retain MAC address
• vSphere 8 documentation: VMware OUI allocation
• Broadcom KB 317478: Setting a static MAC address for a virtual NIC
• vStellar: Static MAC address in ESXi 5.5 conflicts with VMware reserved MACs

Written by the Consult Circle VMware HCX migration team. Last reviewed 3 November 2026.