AutoLab Automation outline

This is another post from Alastair. Just a reminder that Cody is no longer alone in posting on ProfessionalVMware.com.

Earlier this month the AutoLab was announced right here on ProfessionalVMware and released on LabGuides.com. We’ve had a huge number of downloads and a great response.  For those who missed it the AutoLab is a package of automation for a vSphere training or test lab that runs on top of a single PC, follow the links above for more information.

Today we released version 0.8 of the AutoLab, this adds support for Windows Server 2008R2 SP1 and vSphere 5.0 Update 1. It also makes quite a few improvements to the automation and simplifies lab setup along with improving the documentation.

I don’t plan on another release until vSphere 5.next is released, so if you find the AutoLab needs some tweaking you may need to do the tweaks yourself. To help with tweaking I’m going to document the automation of the AutoLab over a few blog posts, this one is the outline of the areas of automation.  Following blog posts will dive into each area of automation in more detail. Much of the automation is useful in an environment where you need to build a production system, so even if the AutoLab is perfect for your needs you may want to learn how to automate the non-lab world.

Open Source VMs

The two Open Source VMs are the NAS (FreeNAS 0.7)  and the router (FreeSCO), both VMs are distributed pre-built and ready to go, so no further automation is required.  It’s great to have a compact operating system that can do a huge amount of work.  The NAS provides a build share where the  rest of the automation is hosted.

If the Open Source VMs need rebuilding then just redeploy the whole lab.

Windows VMs

The Domain Controller (DC) and Virtual Centre (VC) VMs are the heart of the lab, both are built from Windows 2008R2 install ISOs and both have their build automated with the AutoUnattend.xml file that is placed on a floppy disk image. Unfortunately there are some version specific directives in the xml so there are separate floppies for 2008R2 RTM and 2008R2 SP1 in the v0.8 release. The AutoUnattend.xml file covers the windows setup including optional service component to install and OS level configuration.  A command script is then launched on first boot after the windows install.  Both VMs start with a script off the floppy image and then transfer control to a script that is copied from the build share.  In the \Automate folder of the build share is a folder for each VM which contains the script and it’s required files.

The DC is made a domain controller of a new domain, DHCP, DNS and TFTP server as well as having SQL Express installed and a heap of other settings tuned to tweaked.

The VC can be automatically made a vCenter server and as many steps as possible automated, or it can just have VMware Tools installed and you can do the rest. Since vCenter install may be what you need to learn it is easy to opt out of this automation, if you’ve installed vCenter dozens of times then you’ll love the automation.

ESXi hosts

The ESXi servers are built using PXE from the DC,  PXE requires DHCP and TFTP, we use the Microsoft DHCP and Jounin TFTP.  The files that are required for the PXE build live on the DC in C:\TFTP-Root and are populated there from the build share by the DC build script.  The files here are version specific, meaning that moving from ESXi 5.0 to ESXi 5.0 Update 1 isn’t a simple rip and replace. A few files are pulled from the Build share over NFS at ESXi install time, however the PXE files are only copied at DC build time.  The PXE build does a minimal setup of the ESXi servers, just setting an IP address and root password. Post build configuration of the ESXi servers is handled when they are added to the vCenter inventory.

vCenter Inventory

The vCenter inventory is populated using a PowerShell script on the VC VM.  Powershell is a great way to automate vSphere, particularly with the community around PowerCLI and the wealth of sample scripts. A few of the things done by the script are:

• Create datacenter and HA/DRS cluster
• Set HA admission control and DRS automation
• Rename local datastore
• Create additional four VMKernel ports
• Create vSwitch with two VM portgroups
• Add and configure iSCSI for storage access
• Create VMFS datastores or register VMs that are on existing datastores
• Create a new VM, set boot order and media and power it on to start installing windows

This should give you a start on what’s behind the AutoLab automation. Over a few posts I’ll dig a little deeper into each area.