mac address

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

10.22.2021 by William Lam // 7 Comments

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.

[Read more...]

How to deploy the vCenter Server Appliance (VCSA) with a custom MAC Address?

02.20.2020 by William Lam // 5 Comments

I recently had a question that came in from our field where a customer needed to deploy the vCenter Server Appliance (VCSA) with a specific MAC Address which was a requirement to ensure property connectivity within their network. This type of network requirement is not really new or unique, it is a common practice used to ensure only valid VMs with a static DHCP reservation can actually connect to a specific network but it certainly was the first time I had heard of this request for the VCSA.

With the default VCSA installer workflow, there is currently not a way to modify the network MAC Address which is automatically generated after the deployment of the OVA. Having said that, I have spent quite a bit of time exploring the various non-standard methods of deploying the VCSA in the past (see here, here and here) and with that information, you definitely can affect the MAC Address while still maintaining a valid VCSA deployment. With a bit of trial/error, there are two options depending if you are deploying the VCSA directly to an ESXi host (for initial setup) or to an existing vCenter Server. To demonstrate how this works, I have created a basic shell script called VCSAStaticMACAddress.sh which you can easily adapt to for a Windows-based environment.

The trick is that when you deploy to a vCenter Server endpoint, the required OVF properties are persisted which would allow you to only deploy the VCSA but not actually power it on and there you can easily augment a number of settings including the MAC Address. In the case of deploying directly to an ESXi host, OVF properties are not persisted and hence a challenge if you wish to make changes prior to powering on the VM. In earlier versions, it was possible to set these OVF properties by way of using the extraConfig property of the VM but it looks like this trick no longer works and requires a slight variation of the workflow which is described in the instructions below.

[Read more...]

Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0

03.05.2015 by William Lam // 4 Comments

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.