Ran across an issue recently when using VMware View and Unidesk to build VDI VMs. The project started in February and we built our gold image, created an OS Layer in Unidesk, and rolled out a few desktop pools with no issues, but in the last month, we started to notice most VMs would “stick” with a Status of STARTUP in VMware View administrator thus they were unavailable to end users.

The problem could be resolved in one of two ways:
1. Wait an hour and eventually the Status would change to Available
2. Reboot the VM via the Unidesk Management Console and more often than not, the VM would “wake up” and become available after a second reboot.

We tried seemingly everything to resolve the issue…we then opened a case with VMware who initially believed it was the Java Memory Heap or something. While collecting logs for the VMware case, I saw that several people were having a similar problem ever since Daylight Savings Time (DST) went into effect. On the surface, the ESX server, the VMs, and the domain controllers were all in sync but still the connection server showed messages being received from the View agents at different times from the time of transmission, almost a one hour difference.

To resolve the issue in a standard View environment, the basic high-level process is as follows:

1. Boot the Master Image
2. Patch Master (if required)
3. Release IP and Set correct time to it.
4. Shutdown
5. New Snapshot
6. Recompose

But I’m using Unidesk to push out my virtual desktops so the process is still easy, but a little different:

1. Add a version to the existing OS Layer
2. Login to the installation machine and set the time zone to something other than your own and reboot. For example, I am in the Eastern time zone so I set my installation machine to the Central time zone and rebooted.
3. Login again and change the time zone to the correct time zone. Again, I’m in the Eastern time zone so I changed my VM from Central to Eastern.
4. Personally, before I finalize any Unidesk layer I reboot so I rebooted my installation machine once more.
5. After the reboot, open the Unidesk Management Console and finalize the new OS Layer.
6. Deploy the new OS layer to an initial batch of pilot/test VMs and verify that the Status reads Available after the VMs reboot to deploy the new OS layer.

For us, this simple fix corrected our STARTUP status problem…I wonder if I’ll have to do the same thing in November?