View 5 Parent VM's

Been working on a VMware View 5 pilot for the past couple months and I wanted to share with you a gotcha we discovered.

First off, I should stress that how you build the Parent VM's is extremely important. I would suggest that you use MDT or SCCM OSD in creation of your image (as always) and that you carefully design your image with the idea that you're running within a shared resource environment.

A short description on Parent VM's. A Parent VM is a virtual machine that is the basis for other virtual machines in a Linked Clone desktop pool. The idea is similar to differential disks in virtualization 101. You have a parent disk and then create/link a second disk to the first. Any additional writes to the VM are written to this second differential disk. The hypervisor then determines which disk to pull from when a read IO occurs. When talking about Parent VM's and Linked-Clones, when a new VM needs to be created, the template it uses is the Parent VM.

Our problem started when we took the snapshot of our parent VM for View to use as our template. Whenever we started provisioning the pool, the VM's would hang at the customization phase. I won't bore you with the details, but first we thought it was hardware we used within the Parent VM. It was built on hardware version 8 (the newest for View 5.0) and that we were using an incorrect storage controller driver with the OS. Whenever we turned on those VM's, it wasn't joined to the domain and we received the "New Hardware Detected" Windows dialog box wanting us to restart the computer.

Easy! Just update the driver and then take another snapshot.

Turns out this wasn't the case.

Several more troubleshooting steps later we finally determine what the problem was: Microsoft App-V. The App-V agent was baked into the Parent VM. When QuickPrep does it's thing, it enumerates all of the drives registered with Windows. App-V creates a logical drive (Default is Q: I believe...) and when the VMware View Agent grabs those registrations and discovers the App-V drive, it handles it incorrectly. When we stop/disable the App-V agent service and started it back up post load it works like a charm.

Whether it was the fault of VMware or Microsoft/SoftGrid (this was using App-V 4.5, no SP so it was pretty old) is unknown. But hopefully this can help someone else who doesn't have to pull their hair out as much as we did.