Heads Up! Valid Static Address Ranges in vSphere 5.1

If you are planning to upgrade to vSphere 5.1, you need to pay attention to this, especially if you have assigned static MAC addresses to your virtual machines. After upgrading to vSphere 5.1, VMs with statically assigned MAC address may fail to power on with the error: “The MAC address entered is not in the valid range.” 

In vSphere 5.1 new policies have been implemented where the statically assigned MAC addresses can only be in the range 00:50:56:[00-3F]:XX:XX or other non-VMware OUI addresses. Why did we make this change in 5.1? Primarily to check for MAC conflicts.

There is some blurb around changes to the MAC address ranges in the vSphere 5.1 Release Notes but it doesn’t explain the situation fully. The release notes mentions that Prefix- and range-based MAC address allocation is supported only in vCenter Server 5.1 and ESXi 5. This implies that if you add pre-5.1 hosts to vCenter Server 5.1, and use anything other than VMware OUI prefix- or range-based MAC address allocation, virtual machines assigned MAC addresses that are not VMware OUI prefixed fail to power on their pre-5.1 hosts.

Now, from what we’ve seen, the restriction is a little more detailed than what is described above. Static MAC addresses in vSphere 5.1 must be in the range 00:50:56:[00-3F]:XX:XX. If the MAC addressed is prefixed with 00:50:56 but it is outside of the [00-3F]:XX:XX range, it is still considered invalid and the VM will fail to power on.

This is a real issue if you have applications running in VMs which have licenses that are tied to a specific MAC address. In particular, I know that HP P4000 series (LeftHand) VSAs use this licensing mechanism. Therefore if you are forced to use new static MAC addresses, you will need to source new licenses for your nodes. This has already been an issue for some customers, and I’ve seen this discussed in the community forums. And of course, if you do not have a current contract with HP for your appliance, sourcing new licenses might be difficult.

Although KB 2007042 mentions ethernetX.checkMACAddress = “FALSE” as a workaround, this is out of date and does not work on the most recent versions of vSphere. We are actively considering re-implementing this feature. I’ll provide an update when I learn more.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @CormacJHogan

16 thoughts on “Heads Up! Valid Static Address Ranges in vSphere 5.1

  1. I’d love to have the option to disable the check – I have one customer who won’t be able to move to 5.1 as it stands. The MAC address used on the VM was 00:50:56 but outside of the [00-3F]:XX:XX range and thus invalid. I did do a little messing about – I couldn’t get the workaround’s noted in the post above or in the Lefthand VSA forum post to work.

  2. Is there any update on the potential to disable MAC address checking? As it stands I can’t move to 5.1 without purchasing whole new storage + migration.

  3. Have you tried ……

    1). Edit the VM settings and put MAC Address “Automatic”
    2). Turn on the VM to automatically assign MAC (this step may not be necessary)
    3). Shutdown the VM
    4). Edit the file. Vmx
    5). Find the line ethernet0.generatedAddress = “1a: 2b: 3c: 4d: 5e: 6f” and change the MAC generated by we want.
    6). Start the VM and check that it does not check the MAC error. and assigned to the MAC that we have put into the configuration file.

  4. What about using
    ethernet0.addressType = “generated”
    ethernet0.address = “00:0c:29:1a:8b:12″

    I tried that and it worked.

  5. Pingback: Full MAC spoofing sur ESX 5 – MAJ - Hypervisor.fr

  6. You don’t have to add this line. It’s there by default.
    If you have a license fixed to a MAC address like 00:0c:29:xx:xx:xx you need to manipulate uuid.bios in your VMX file. See my 1st reply to Cormac’s posting.

  7. I agree with Souhil. I have a VM with the following details in the VMX file.

    ethernet0.present = “true”
    ethernet0.virtualDev = “e1000″
    ethernet0.networkName = “VLAN NAME”
    ethernet0.addressType = “generated”
    ethernet0.generatedAddress = “00:0c:29:xx:xx:xx”

    With the risk of kicking in an open door: I guess the difference between “generated” and statically assigned is crucial here.

  8. Pingback: HP StoreVirtual FOM smette di funzionare aggiornando vSphere 5.0 a 5.1

  9. Pingback: HP StoreVirtual FOM stops working after vSphere 5.0 is upgraded to 5.1