VMware View Recompose and MAC Address

This week I answered to this question to someone on Twitter and then I saw it again at VMware internal forums.

– How to persist MAC Address during recompose operations?

Persisting MAC address during Linked Clone recompose operations is critical for many organizations. The ability to persist MAC address is directly related to the ability to automatically place desktops in specific VLANs, license applications that require MAC address registration, re-register an already existing IP address that has been recomposed with an existing MAC address automatically via DNS and DHCP, or even if for any reason you require to spoof MAC addresses in your network (yes, I have seen this one).

Prior to VMware View 5.0 only the Linked Clone refresh operation would maintain MAC address because refresh operation is actually a snapshot rever-back operation. After a desktop is customized, the VM is shutdown and a snapshot is taken for this VM (vmname-checkpoint.vmdk) and then the VM is powered on for inital use.

When a refresh operation is  then triggered the VM is shutdown and reverted back to the snapshot maintaining the MAC address for the VM. Please note that this behavior was changed in VMware View 4.5, where prior to that the MAC address would also change for refresh operations.

 

 

What about Linked Clone recompose operations?

Starting with VMware View 5.1 all Linked Clone recompose operations will preserve the MAC address for both assigned and unassigned VMs. Prior to VMware View 5.1, Linked Clone recompose operations preserved the VM MAC address of assigned VMs only, while unassigned VMs would be recreated and assigned new MAC addresses.

That behavior is particularly useful for non-persistent desktops in floating desktop pools and will also persist MAC addresses when re-balancing Linked Clones across datastores.

 

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.

 

6 comments

Skip to comment form

    • Darren Henderson on 01/08/2013 at 5:21 am

    Andre,

    Can you expand a little, are you saying, with View 5.1 now a recompose on a linked clone non-persistent desktop pool WILL persist the Mac address, and a refresh always did (well from 4.5)

    So in a non-persistent pool, a user logs into a desktop, logs off and the desktop is refreshed on log off. The MAC will be persist.

    Also in a non-persistent pool, a user logs into a desktop, logs off and and that desktop (or pool) is recomposed, the MAC will be persist ?

    It’s just the explanation above refers to assigned/unassigned desktops, which in a non-persistent pool is not quite the same/clear. 🙂

    Thanks

    Shmern

  1. Shmem,

    Yes, you are correct. The MAC address will persist across refresh and recompose for any Linked Clone pool type. I refer as assigned/unassigned for persistent desktop that have been attached to a user or not.

    I hope that helps,

    Andre

    • Petr T. on 05/21/2014 at 5:59 am

    Thank you! it’s exactly what my customer is looking for. Unfortunately with View 5.3 they are not seeing this behavior and application (Integrated Office Navigator version 1.2.1007 for Mitel Navigator IP phone) that depends on MAC address for licensing is not functioning correctly. If you have a reference to VMware official documentation or article it would be helpful.

    • Tom Brennan on 10/27/2014 at 6:41 am

    I have the same issue with an application called Calabrio. The Mac address is used to register the phone used by the agent and needs to be static. When I created the pool and documented the Mac addresses, they all changed when I refreshed the pool (MS Updates applied). We’re running View 5.5.

  2. Tom, the MAC address should remain constant in Horizon View 5.5 when refreshing or re-composing a desktop pool. Please verify the issue with VMware support.

    • Tom Brennan on 10/28/2014 at 8:22 am

    Hi Andre. I think I figured out what was causing the problem. The Mac only changed when I destroyed the VM, but did not change with a simple refresh or recompile. I think we’re going to have to change the pool from floating to dedicated and remove the setting to destroy on log off.

Leave a Reply