We’ve got quite a bit of stuff to talk about in this post/diagram/video, so I’ll keep the introduction as simple as this: It’s the third part, it’s the final part, and it’s my favorite part of the (vSphere In A Box) series.
This is an overall illustration of the workflow and automation process of the environment using the same single server, and an iSCSI array, that we’ve used in the previous posts. The diagram may look a bit complicated at the first glance, but I tried to keep things as simple as possible. I used the actual IP addresses, configurations, and workplaces names that I use in my environment and as you will see in the next video, to keep things clear and easier to follow.
This is by no mean a Lab Manager tutorial, it’s just a very “quick tour” on the components and automation of the my vSphere labs. I intend to do a series of tutorials in the future on Lab Manager 4.0 itself, but for the sake of this subject I created this quick walkthrough video instead of taking more than 20 screenshots that won’t make much sense individually.
My Use Cases:
If you’ve been reading my previous few posts, you’ve probably known what are my objectives from this, and since I hate to repeat myself, I will copy & paste one of the use cases I mentioned in an earlier post, followed by two new cases I’m working on now:
- […] I need to build my own labs for my “virtual private cloud” project, which will typically require building multiple vESX clusters, not to mention the importance of having the templates and libraries for deploying these clusters whenever I need to test something new that would require significant changes (e.g. Nexus1000v for networking, or Reflex vTrust for security) […]
- I’m trying these days also to evaluate the VMware Site Recovery Manager running in two deferent and independent setups to simulate a real life scenario instead of using the traditional all-in-one-subnet setup. Since part of these applications are still in Beta, and consequently under NDA, I won’t be able to elaborate more on this use case until all the software are in the GA stage.
- I discovered another great use case while I was working on the Lab Manager, which is training the SysAdmins in my current corp on the new vSphere platform. We are also growing rapidly with our virtual environment (soon to be: private cloud) and we’ll definitely need more SysAdmins on board. That being said, I now have an instrumental tool for provisioning independent labs for the SysAdmins to login and have their own hands-on experience with the new platform.
As you all know, the vCenter Lab Manager 4.0 was never meant to run virtual ESX hosts inside itself, therefore, there are some tweaks and considerations that you need to know about while you are implementing this in your own environment. But the beauty of VMware is that all its components are highly customizable and work in a true harmony regardless of what you want to achieve at the end.
1) As you know, the vESX hosts need to be connected to a “Promiscuous enabled” vSwitch. When you create new Network Templates in LM, and later on deploy them within your configurations, the LM by default create the new vSwitch with this feature disabled, so you will need to go an manually enable that. I’m trying to figure out a way to automate this or set it to be enabled by default, I will update the post should I manage to do that.
2) When you import your vESX templates you must uncheck the customization part as shown in the screenshot since the VM is not running a supported OS by VMware (like Windows or Linux), however, I managed to install the VMware tools inside the classic ESX 4.0 as shown in the next point.
3) Although I haven’t tested this thoroughly yet, I believe you can customize the classic ESX hosts with COS in Lab Manager by installing the VMware tools as follows:
Mount the VMware tools ISO
unzip/untar the package
Run the perl script and follow the installation instructions:
By this part, I believe that we’ve completed the entire series of the (vSphere In A Box) and shown how and why you need to be doing this setup. I hope that everyone can clearly see now the huge deference between running the ESX hosts inside VMware Workstation compared to running it inside ESX itself, as well as the great benefits of doing that in a larger scale with the automation to achieve many of the use cases mentioned across this series of posts.