Does vCenter Server recycle VM MAC Addresses after Cross vCenter vMotion?

I recently received a question from a customer who was concerned that after a VM has been migrated from one vCenter Server to another using Cross vCenter vMotion, that the original source VM MAC Address could potentially be recycled and re-used at a later point. Back in 2015, I actually wrote about this very topic and the concerns around VM MAC Address duplication after a Cross vCenter vMotion, which I highly encourage folks to check out if you have not seen this article already.

While re-reading the article, I realized that the article had primarily focused on vCenter Servers that were in Linked Mode or under the same vSphere Single Sign-On (SSO) domain and although I did mention the Cross vCenter vMotion across across different vSphere SSO domains scenario, it looks like the details were a tad bit light.

To quickly summarize, when a VM is migrated from a source vCenter Server to the designation vCenter Server, the VM's MAC Address is added to a MAC Address "block list" on the source vCenter Server. This ensures that the VM MAC Address will not be reallocated by the source vCenter Server which would cause a network conflict. This has been the default behavior since vSphere 6.0 and no additional configuration change is required by customers.

What is not clear is whether this behavior also occurs for a VM that has been migrated across vCenter Servers that are not  part of the same vSphere SSO Domains or basically vCenter Servers not part of Linked Mode? The easiest way to verify the behavior was to simply test this in the lab! Before doing so, we can also check what MAC Addresses are currently in the "block list" by using a private vSphere API, which is accessible via the vSphere MOB called fetchRelocatedMACAddress

This API will return the list of MAC Addresses that is currently blocked by the given vCenter Server. To view the list, simply open the browser to following URL: https://[VCSA_FQDN]/mob/?moid=networkManager&method=fetchRelocatedMACAddress and authenticate with an administrative user. To invoke the API, click on the Invoke Method button and you will either see no results, which means you have not performed any Cross vCenter vMotion or a list of VM MAC Addresses which have been blocked.

Now we can perform a Cross vCenter vMotion and upon completing the operation, we can now re-run the vSphere API on the source vCenter Server and what we should see is that the VM that was migrated, its MAC Address has now been added to the block list, as shown in the screenshot below.

We can now definitively confirm that regardless of the vCenter Server(s) vSphere SSO domain configuration, once a VM has been migrated, the source vCenter Server will automatically add the VM MAC Address to its block list to ensure it is not reused again. If the VM is migrated back to the source vCenter Server, the block list will automatically be updated as mentioned in the original blog post. I still find it amazing that I can still learn something new every day, even for a feature that is over 6 years old!