VM MAC Address Changes in VMware View

A common question from VMware View administrators is if the MAC addresses in each VM are retained after a recompose or refresh operation.

In VMware View 4.0 and earlier linked cloning operations were a little more CPU and IO intensive. Because of the high number of recourses utilized during these operations VMware decided to change the basics of those operations for VMware View 4.5. I have previously written about how Linked Cloning operations work under the hood, read on Part 1 and Part 2 of my article “VMware View 4.5 Linked Cloning Operations Explained”. The article does not discuss the retention of MAC addresses.

In VMware View 4.5 and later if a VM is assigned to a user their MAC address is retained after recompose operations.

For non-persistent pools and for VMs that haven’t yet been assigned to a user, a recompose operation will be performed as delete-then-recreate resulting in MAC address change.

For VMware View brokers as long as a VM is scheduled for recompose, it will only do recompose. The choice between recompose and delete-then-recreate is made by View Manager based on following conditions:

  1. If the VM is assigned to a user, always use recompose to ensure MAC address is preserved.
  2. If VM is not assigned to a user, whether the desktop pool is persistent and whether the recompose is on the entire pool or on a list of VMs.
  3. If recompose is selected for the entire pool, whether the default image was changed.


Now, you are probably asking why you would want to retain MAC addresses for non-persistent desktop pools.

One of the possible reasons to retain MAC addresses could be applications that have their licensing model tied to MAC addresses. In this situation VMs that have not been assigned to users yet or belong to floating pools would need to retain their MAC addresses.

There is no simple way to retain or determine MAC addresses for a VM with VMware View if the VM is not yet assigned to a user. A possible workaround would be to spoof the GuestOS MAC address via Windows registry key change. There are many articles that demonstrate step-by-step how to accomplish the change. Read How to change MAC-Address in Windows Registry or How to Change or Spoof MAC Address in Windows XP, Vista, Server 2003/2008, Mac OS X, Unix and Linux.

For GuestOS spoofing to work as expected you will need to create a “postsync” script for the desktop pool. The script will have to shutdown the VM, change the MAC address to static, turn off the ESX protections against spoofing, and finally edit the MAC address in the .vmx file or inside the registry.

The reverse idea is also valid in some situations. Let’s say you want to make sure VMs always have the same MAC address, even after a delete-then-recreate operation. As an example, a good example is the MAC address relationship between a DHCP range and specific firewall rules and filters based on those MAC addresses. In this case a DHCP range needs to be enforced according to MAC addresses.

Here is a little tip – If you wish that VMs that have not yet been assigned to a user do not change their MAC addresses, instead of recomposing the entire pool, recompose a list of VMs. In this case View Manager will schedule the unassigned VMs for recompose rather than delete-then-recreate.

If you decide to run postsync scripts you will find view-composer log file at c:\windows\temp\vmware-viewcomposer-new.log. If something is not working properly it should be easy to figure out from there what is going wrong.

I also have found an interesting tool called MAC MakeUp that can do the job for you. The application has a GUI and also lets you script MAC batches and set new MAC addresses using CLI. If you are keen to develop a script, please share with us.


    • Bozo Popovic on 07/08/2011 at 3:45 am

    First thank you for sharing this info about MAC changes for dedicated and floating users. i have a situation with one of our customers where their application ties with a MAC address as well as configuration file. It was easy now while they are using physical dedicated desktops. Now they want to move to virtual desktops for various reasons. But the problem with the MAC changes appears to create problems…What they want to accomplish?

    They want to use floating desktop with 500 virtual machine for 1500 call center users which work 24/7 in a 8 hour shifts. All 1500 users have unique AD domain names offcourse. So initially we will have to provide unique login name to remote application from the client side, the configuration file and a MAC address. They are willing to pay for 1500 licenses no problem with that, we can create a startup script which copies from configuration file from the network share to the appropriate location in the c: drive folder. But how to accomplish roaming of the MAC address as well since there is no guarantee that they will get the same desktop next time they login. I was thinking about creating a startup script which alters the registry key for the MAC address, but they are not willing to go for any 3rd party application. What would you recommend as a solution if you think this is not good or there is an another way?
    They would like to preserve the MAC by using VMware View mechanism or some MS tool. I am assuming they got this feeling working with Citrix Xen Desktop + XenApp which have this option out of the box.

    Thank you,

  1. @Bozo Popovic
    I believe you are on the right path with the post-sync script. Have a look at my article “Automatic VLAN change in VMware View” to understand diferent use cases for pots-sync scripts.

Leave a Reply