Today I had a comment from one of the posters on the site, Matt. I think Matt sparked a very good question/problem that I wanted to open up to everyone else to see if we could get some clever ideas to combat this issue.

Here is Matt’s question

Paul,
I was wondering if you or anyone else has run into this issue:
After refreshing/recomposing a Floating Pool of linked clones I found that DNS resolution for those VMs was broken. After a bit of investigation I found that on a refresh/recompose the linked clones generate a different MAC address which leads to them getting a different DHCP address.
The problem is that when this happens it leaves a stale entry with the old MAC in DHCP which is linked to its DNS record. This could potentially flood DHCP with stale entries that are locking up IP addresses (DoS if the DHCP scope runs out) if you have a large desktop Pool with a high refresh rate (refresh on logout option). It also prevents the linked clones DNS record from being updated.

My question is, is there any way to force view composer to keep the VM’s MAC address when it does a refresh/recompose? that would stop it from getting a different DHCP address every time and it will keep the DNS record up to date.

If not, will I have to write some script to run on power off that deletes the DHCP and DNS entries for that virtual desktop?

 

As you know the virtual machine MAC address changes when you recompose/refresh when using a floating or non-persistent desktop pool. The MAC address does not change after a refresh/recompose when you have users assigned to that particular desktop.

The common solution to this issue is to create a special DHCP scope just for your floating/non-persistent desktop pools with a very low DHCP reservation value like 4 hours. Now this doesn’t totally solve the issue because you could be ripping through 500 desktops in the matter of hours especially if you are a college or library and still run into some DNS cache poisoning issues.

This is a long shot but Quickprep gives you the ability to run scripts after a recompose/refresh or after power off. You could have a script run that will run after a refresh/recompose to retain your current MAC Address. I don’t have a sample of one but I am sure it’s possible but would probably involve a great deal of effort on your part.

VMware needs to grant us the ability to manually configure MAC addresses for our pools so we can get around this issue.

Does anyone out there have a better solution? I am very interested in your thoughts…




Similar Posts:


More about Paul Slager

Written by Paul Slager
Paul is the owner of PaulSlager.com and enjoys writing a wide variety of technical articles for the community. Paul specializes in Virtualization, Storage, DR, Strategic Planning, Backup, SharePoint, Active Directory, and MS Exchange. He holds his PMP, MCITP, and VCP. Paul also does free community service and consulting for any companies that wish to use his resources.