Is the vCenter Server Unique ID still important today?

When I was a customer back in the day, one of my operational checklist items for deploying a vCenter Server was to configure the vCenter Server ID and ensure that it was unique from other vCenter Servers within my environment.

The vCenter Server ID is a value between 0-63 that is randomly generated by default, but it can updated by a user after the vCenter Server has been deployed.

Why should you care about the vCenter Server ID? vCenter Server uses this ID to generate Virtual Machine MAC Addresses and if two vCenter Servers have the same ID, it can potentially generate duplicate VM MAC Addresses as explained in this VMware KB 1024025.

With this background in mind, is having a unique vCenter Server ID still relavent and applicable today in 2022?

If you would have asked me a few days ago, I would have said yes, especially since my understanding of this concern had not changed and I think many in community also believes the same. It was only due to a recent customer inquiry on this topic again that lead me to ask whether this was actually still relavent in 2022. After speaking with Engineering, the answer actually surprised me as it was a NO and it has been a no for a number of years now! 😲

vCenter Server has a couple of advanced options that were introduced almost a decade ago that completely eliminates the need for relying on the vCenter Server ID to generate unique VM MAC Addresses (also known as VMware OUI MAC MAC Address Allocation). Using the default VMware OUI MAC Address Allocation method, an organization can only deploy up to 64 vCenter Servers on a single network, each supporting a maximum of 64,000 MAC Addresses before they could potentially run into issues.  

Back in 2012, vSphere 5.1 introduced two new options in vCenter Server for generating unique VM MAC Addresses:

• Prefix-based MAC Address Allocation
• Range-based MAC Address Allocation

both of these options resolves the concerns around generating duplicated VM MAC Addresses but they also help increase the scale for customers that need to deploy more than 64 vCenter Servers within a single Layer 2 network and can support up to ~16 million MAC Addresses when using the new Prefix-based allocation method.

I am not sure what was more surprising for me, the fact that a solution has existed for over a decade now, the use of extremely large Layer 2 networks where these limits were being reached by customers or that many folks internally/externally (including myself) still thought that a vCenter Server should have a unique ID? 🤷

Which MAC Address Allocation should you use?

If you need to deploy more than 64 vCenter Servers within a single Layer 2 network, you should probably switch or update to either a Prefix or Range-based allocation. Personally, I have only ever spoken to one customer who had ran into a duplicate MAC Address due to same vCenter Server ID being used. However, in speaking with Engineering, we have had some really big customers in the past that manage extremely large infrastructures that have a need to deploy more than 64 vCenter Servers and duplicate VM MAC Address has been an issue and these additional MAC Address allocation schemes can help address these concerns.

For the majority of users, the default VMware OUI MAC allocation is more than sufficient and it is still the default allocation even in vSphere 8. For many organizations, multiple smaller Layer 2 networks is used to reduce the fault domain of a single network and also broadcast traffic. Even if you deploy a handful of vCenter Servers within a single network, you may never reach the 64,000 VM MAC Address limit to even run into the risk of getting a duplicate address. If you still have concerns, you can certainly check and update your vCenter Server IDs to ensure that they are all unique.

Here is a quick PowerCLI snippet that retrieves the vCenter Server Advanced Setting instance.id which is the ID configured for your vCenter Server:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name instance.id

Here is a quick PowerCLI snippet to update the vCenter Server Advanced setting instance.id with a new value:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name instance.id | Set-AdvancedSetting -Value 1

Note: A restart of the vCenter Server service is required for the change to go into effect after updating the ID.

Detecting and Preventing MAC Address Conflicts

vCenter Server also has a built-in alarm for detecting duplicate VM MAC Address which can be useful if you perform Cross vCenter vMotion of your VMs across different vCenter Servers. If you need to check whether you have any conflicts, you can also use vSphere API and Automation to scan across all your vCenter Server and dump all VMs and their associated MAC Address. Below is a quick PowerCLI snippet that you can use and adapt, which also can be outputted to a CSV file for analysis.

$results = @()
foreach ($vm in Get-VM | where {$_.PowerState -eq "PoweredOn"}) {
    foreach ($adapter in $vm | Get-NetworkAdapter) {
        $adapterShortName = "NIC-$($adapter.Name.split("Network adapter ")[1])"
        $tmp = [pscustomobject][ordered] @{
            Name = ${vm}.Name + "-" + $adapterShortName
            MAC = ${adapter}.MacAddress
        }
        $results += $tmp
    }
}

# Output to Console
$results

# Output to CSV
$results | ConvertTo-Csv | Out-File vm-mac-address.csv

Configure Prefix/Range-based MAC Allocation after vCenter Deployment

Since the VMware OUI allocation is the default method, if you wish to switch to a different MAC Address allocation scheme, you will need to add or update the specific vCenter Server Advanced setting as outlined in the VMware Documentation and restart the vCenter Server service for the changes to go into effect. The MAC Address allocation scheme can be changed at any time, whether that is initially after a vCenter Server has been deployed or after it has been running for awhile with existing workloads. Once the MAC Address allocation method has been updated, vCenter Server will start using the new method to generate new VM MAC Addresses from that point forward. In addition to the vSphere UI, users can also automate this post-deployment using the vSphere API or PowerCLI.

Configure Prefix/Range-based MAC Allocation during vCenter Deployment

For customers that prefer not to have an additional post-deployment step, both Prefix or Range-based MAC Allocation can be configured as part of the vCenter Server deployment. There are advanced OVF properties that allow customers to specify these settings when using the VCSA Installer.

However, these settings are only available when using the VCSA CLI Installer as the OVF properties are hidden options that can only be used through the OVFTool argument pass-through feature which was introduced back in the VCSA 6.5 CLI Installer.

Here is an example of a VCSA deployment JSON which also configures the Prefix-based MAC Address Allocation method:

{
    "__version": "2.13.0",
    "new_vcsa": {
        "esxi": {
            "hostname": "192.168.30.5",
            "username": "root",
            "password": "VMware1!",
            "deployment_network": "VM Network",
            "datastore": "sm-vsanDatastore"
        },
        "appliance": {
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "VCSA-MacAddressPrefix"
        },
        "network": {
            "ip_family": "ipv4",
            "mode": "static",
            "ip": "192.168.30.190",
            "dns_servers": [
                "192.168.30.1"
            ],
            "prefix": "24",
            "gateway": "192.168.30.1",
            "system_name": "192.168.30.190"
        },
        "os": {
            "password": "VMware1!",
            "ntp_servers": "pool.ntp.org",
            "ssh_enable": true
        },
        "sso": {
            "password": "VMware1!",
            "domain_name": "vsphere.local"
        },
        "ovftool_arguments" : {
            "prop:guestinfo.cis.vpxd.mac-allocation-scheme.prefix": "005050",
            "prop:guestinfo.cis.vpxd.mac-allocation-scheme.prefix-length": "24"
        }
    },
    "ceip": {
        "settings": {
            "ceip_enabled": false
        }
    }
}

Once the vCenter Server is deployed and accessible, you will see the correct vCenter Server Advanced Setting is automatically updated based on the allocation method that you have specified in the JSON configuration file.