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:
- If the VM is assigned to a user, always use recompose to ensure MAC address is preserved.
- 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.
- 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.