In vSphere 6.0, the mobility options for a Virtual Machine is truly limitless. This has all been possible with a new set of vMotion capabilities introduced in vSphere 6.0 which you can learn more about them here and here. In the past, one area of concern when migrating a VM from one vCenter Server to another is the possibility that a migrated VM's MAC Address might be re-provisioned by the source vCenter Server resulting in a MAC Address conflict. In fact, this is actually a topic I have covered before in my considerations when migrating VMs between vCenter Servers article. I highly encourage you check out that article before proceeding further as it provides some additional and necessary context.
When looking to leverage the new Cross vCenter Server vMotion (xVC-vMotion) capability in vSphere 6.0, are MAC Address conflicts still a concern? To answer that question, lets take a look at an example. Below I have a diagram depicting two different vSphere 6.0 deployments. The first is comprised of three vCenter Servers who are joined to the same SSO Domain called vghetto.local and VM1 is currently being managed by VC1. The second is a single vCenter Server connected to a completely different SSO Domain called vmware.local. I will also assume we are being a good VI Admin and we have deployed each vCenter Server using a unique ID (more details here on why having different VC ID matters).
Lets say we now migrate VM1 from VC1 to VC2. In previous releases of vSphere, this potentially could lead to VC1 re-provisioning the MAC Address that VM1 was associated with because that MAC Address was no longer being managed by VC1 and from its point of view, it is now available. Though this type of a scenario is probably rare in most customer environments, in a high churn continuous integration or continuous delivery environment, this can be a real issue. So has anything been improved in vSphere 6.0? The answer is yes, of course 🙂
In vSphere 6.0, vCenter Server now maintains a VM MAC Address Blacklist which upon a successful xVC-vMotion will update this blacklist with the MAC Addresses associated with the migrated VM. This ensures that the source vCenter Server will not re-provisioned these MAC Addresses to newly created VMs and these MAC Addresses are basically "blacklisted" from being used again as shown in the diagram below.
If we decide to migrate VM1 from VC2 back to VC1, the blacklist is automatically updated and "blacklisted" MAC Addresses will be removed. If we decide to migrate VM1 to a completely different vCenter Server which is not part of the same SSO Domain, then the MAC Address could potentially be re-used, but it will depend on your environment if VC4 is on a completely different L2 segment, then a MAC Address conflict would not occur.
As of right now, there is no automatic way of reclaiming blacklisted MAC Addresses, it is a manual process that must be initiated through a private vSphere API. I am hoping we will be able to get this documented in an official VMware KB, so that in case this is required, you can easily follow the simple steps to execute the necessary APIs. Automatic reclamation is being looked at by Engineering and hopefully we will see this in a future patch/update in vSphere. Overall, this should should not really be a concern given that vCenter Server can uniquely generate about 65,000 unique MAC Addresses and you would have to perform quite a few xVC-vMotions before ever needing to reclaim from the blacklist.
One thing to be aware of when performing xVC-vMotion or ExVC-vMotion is that there are currently no pre-flight checks for MAC Address conflicts at the destination vCenter Server (something Engineering is looking update in a future patch/update release). Having said that, there are two additional measures you can implement in you environment to prevent MAC Address conflicts:
- Create vCenter Server alarm which can detect and notify you of a duplicate MAC Address in you environment (also applicable to vSphere 5.5)
- Pro-actively check to see if the existing MAC Addresses of your VM is currently in use prior to performing a xVC-vMotion, this is especially useful when performing ExVC-vMotion.
To help with with number 2, I have created a simple PowerCLI script called check-vm-mac-conflict.ps1 which accepts both your source and destination vCenter Server as well as the name of the VM in the source VC to be migrated. It will check the VM's MAC Addresses in the destination VC and ensure that there are no conflicts. If there is a conflict, it will output the name of the destination VM and the MAC Address that is in conflict as seen in the screenshot below.
Hopefully with these additional measures, you can easily prevent MAC Address conflicts when performing xVC-vMotions in your vSphere environment which can be a pain to troubleshoot.
Is there a limitation of MAC addresses in the blacklist?
I just heard back from Engineering and there is not a limit
Hi William! Is it possible to leverage the private vSphere API to manually add MAC Addresses to a vCenter's Blacklist? We've migrated hundreds of VMs from a 6.0 source vCenter to other 6.0 vCenters in different SSO domains. We are now finding that the source vCenter has re-used some of those MAC addresses (which seems to be fair play based on my understanding of your post). Thanks for your help!
Jason,
No, the private APIs only provide the ability to check which MAC addresses have been migrated and if you need, reclaiming the MAC addresses so they can be used. As mentioned in the article, the blacklisting happens automatically and you can not manually blacklist an address. What you're describing sounds a bit strange, you may want to file an SR to have support/Engr take a closer look in your env