This week I learned about a really cool use case from one of our customers who is using vCloud Director to provision Mac OS X virtual machines to their end users both from a development standpoint but also for troubleshooting and demo purposes for their field and QA organizations. Instead of having to manage hardware assignment across large user base, they have built a completely self-service environment for requesting access to Mac OS X VMs, which I thought was pretty neat.
One issue that they were running into was that when they deployed a Mac OS X VM from their vCD Catalog which is a clone operation, they found that the cloned instances contained the exact same serial number as the source VM and that was giving them some problems. I had pinged a few of our engineers to see if they had any ideas and it turns out that the Mac OS X serial number is generated based off of the uuid.bios property of a VM.
Once I found this out, I knew the exact problem because this was something I had seen before when I had worked with vCD. When deploying a vApp from a Catalog in vCD, the bios.uuid property of the VMs are all kept identical and this would explain why the serial number was the same. This behavior is documented in this VMware KB 2002506 and it also includes a solution to the problem. Once the customer made the change, they were now able to deploy new Mac OS X instances with uniquely generated serial numbers. For regular vSphere or Fusion environments, when cloning a Mac OS X VM, the serial number should always be unique as this problem is only specific to vCD. I should also note that once the serial number has been generated, changing the existing bios.uuid will not force the serial number to change.
Ryan Goldstein says
We had to make this change to allow unitrends (formally phd) vituall snapshots to work correctly.