VMware View inside vCloud Director

I recently wrote about a PowerCLI lab I helped out with at the Greater Cincinnati VMUG (GCVMUG) whole day event (you can read more here). We had originally planned to have each lab station remote desktop into a vCenter server to run each exercise. In the previous article I mentioned a slight twist in our lab delivery — the zero clients provided only supported VMware View. I’ve previously been a part of a VMware View pilot, so I knew we had a couple design choices on how to accomplish this task:

Scenario #1: Automated Pool
Needing 25 temporary and identical desktops for a training lab is a perfect use case for VMware View automated non-persistent pools using linked clones. The non-persistence of the desktops would allow the machines to be refreshed each time someone completed the lab — keeping the desktops clean. Using linked clones would reduce disk space requirements and speed up provisioning operations (since we wouldn’t need to clone the full virtual machine).

Scenario #2: Manual Pool
As the name suggests, manual pools require the provisioning operations to be completed manually. Since I needed 25 desktops, this scenario would require that I manually create (or clone) each desktop.

A manual pool may seem like an odd suggestion, since it is a lot more work than an automated pool. However, this is the route we selected. The key factor was resource availability — the environment we had available was the vCloud environment at Bluelock’s Data Center. In order to create an automated pool a target host or cluster would have been required. Since vCloud Director provided the computing resources, we would have needed to create ESXi virtual machines (nested ESXi) to run the virtual desktops. To improve performance we decided to manually deploy the virtual desktops.

From my testing, it appears that you cannot install the View Agent prior to cloning. When I tried, the cloned VMs would not register in the View Manager interface. I had attempted to use the “Guest OS Customization > Customization Script” feature in the vCloud deployment to install the agent. This did not work either, as the View Agent attempted to reboot the virtual desktop before customization finished. I’m sure I was doing something wrong — the agent should be possible to install in the base image. However, I didn’t have a lot of time, so I went with a simple approach that I knew worked. I ended up creating a batch file on the desktop of my template. After the customization was complete, I manually logged in and ran the batch file. Here are the contents of that file:

C:\Downloads\VMware-viewagent-4.6.0-366101.exe /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_SERVER=viewcon01.viewlab.local VDM_SERVER_NAME=viewcon01.viewlab.local VDM_SERVER_USERNAME=VIEWLAB\vdmadmin VDM_SERVER_PASSWORD=vdmadmin"

Since the desktops were manually deployed, we decided to to place the lab content into a shared folder. We used the domain controller’s NETLOGON share since all clients would have native access. I will post another post in the future about a change that was required during the lab.