The way things work out, I tend to build a lot of vCenter Servers in the lab. Or at least it feels like I do. I need to test this. A customer I’m meeting with wants to specifically see that. I need don’t want to taint or impact an existing vCenter Server which may already be dedicated to something else having more importance. VMware Site Recovery Manager is a good example. Each time I bring up an environment I need a pair of vCenter Servers which may or not be available. Whatever the reason, I’ve reached the point where I don’t need to experience the build process repeatedly.
A while ago, I had stood up a private cloud for the Technical Solutions/Technical Marketing group at Dell Compellent. I saved some time by leveraging that cloud environment to quickly provision platforms I could install vCenter Server instances on. vCenter Servers as vApps – fantastic use case. However, the vCenter installation process is lengthy enough that I wanted something more in terms of automated cookie cutter deployment which I didn’t have to spend a lot of time on. What if I took one of the Windows Server 2008 R2 vApps from the vCD Organization Catalog, deployed it as a vApp, bumped up the vCPU and memory count, installed the vSphere Client, vCenter Server, licenses, a local MS SQL Express database, and the Dell Compellent vSphere client plug-in (download|demo video), and then added that vApp back to the vCD Organization Catalog? Perhaps not such a supported configuration by VMware or Microsoft, but could I then deploy that vApp as future vCenter instances? Better yet, build a vApp consisting of a pair of vCenter Servers for the SRM use case? It sounded feasible. My biggest concerns were things like vCenter and SQL Express surviving the name and IP address change as part of the vCD customization.
Although I ran into some unrelated customization issues which seemed to have something to do with vCD, Windows Server 2008 R2, and VMXNET3 vNICs (error message: “could not find network adapters as specified by guest customization. Log file is at c:\windows\temp\customize-guest.log.” I’ll save that for a future blog post if I’m able to root cause the problem), the Proof of Concept test results thus far have been successful. After vCD customization, I was able to add vSphere 5 hosts and continue with normal operations from there.
Initially, I did run into one minor issue and that was hosts would fall into a disconnected status approximately two minutes after being connected to the vCenter Server. This turned out to be a Windows Firewall issue which was introduced during the customization process. Also, there were some red areas under the vCenter Service Status which pointed to the old instance name (most fixes for that documented well by Rick Vanover here, plus the vCenter Inventory Service cleanup at VMware KB 2009934).
To The Cloud! You don’t normally hear that from me on a regular basis but in this case it fits. A lengthy and increasingly cumbersome task was made more efficient with vCloud Director and vSphere 5. Using the Linked Clone feature yields both of its native benefits: Fast Provisioning and Space Efficiency. I’ll continue to leverage vCD for similar and new use cases where I can. Lastly, this solution can also be implemented with VMware Lab Manager or simply as a vSphere template. Caveats being Lab Manager retires in a little over a year and a vSphere Template won’t be as space efficient as a Linked Clone.