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.
The Idea
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.
The POC
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).
The Conclusion
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.
Do you have the vCenter vApp join a domain using customization settings? Just curious how that all worked out in the catalog.
this can be done fairly easy and I’ll tell you how we did it for demo purposes for different products.
You need to have your vApp completely configured with all the VMs, connections, IP addresses, etc. vCenter, Hosts, vMotion, SQL, etc.
On your vCenter server, you need to configure 2 virtual NICs.
Now, when it comes time to deploy this vApp it has to work like this.
Deploy the vApp onto a network using a FENCED network. Make sure to put 1 of the NICs from the vCenter Win2k8 server onto an External Routed Org network. Or direct connect external.
NEVER customize the VMs, leave all the VMs with the same IP, except use Fencing. When you do this, all your work to make your VMs intercommunicate never gets butchered.
Create some firewall rules in the vShield Edge appliance for the fenced vApp that creates a 1:1 mapping for RDP access into that vCenter 2K8 server, and now you are up and running without ever having to go through all the trouble you did before.
Steven Bryen (@virtualportal) did all this in the matter of a weekend with vCenter Orchestrator. pretty slick stuff.
@Mike I built the vCenter Server while it was not a member of a domain with the intent to add it to a domain after each deployment. The domain add can happen as part of the customization or manually.
Jason,
Great post, maybe using the vCSA and automation from William http://www.virtuallyghetto.com/2012/02/automating-vcenter-server-appliance.html might be an idea to pursue?
Hugo
I was about to post the same thing as Kendrick – instead of redeploying + customization (thus partially breaking the setup), why not deploy it as a fenced environment, thereby removing the need for customization?
– Jesse
I saw the same issue with “could not find network adapters as specified by guest customization. Log file is at c:\windows\temp\customize-guest.log” I am trying to trigger a post script to deploy management agents after customization with vcd/win2k8/vmnet3 combo, but it seems to stuck on this error. did you ever resolve this?