VMware Auto Deploy: A Closer Look

One of the best new deployment features to come out from VMware is the Auto Deploy method introduced with the release of vSphere 5. There was a similar product that was released on the labs.vmware.com site a while back that had similar features to it, but almost all “Flings” that are posted on the VMware Labs site are unsupported since they are not official release products from VMware.

VMware Auto Deploy is a feature rich automated process to deploy 100’s if not 1000’s of hosts in a very short timeframe and without intervention. What makes this product unique is the fact that it leverages a true definition of Stateless Computing whereas the ESXi nodes themselves can run completely in memory and there is no need for magnetic or solid state storage in the server. This is not to say that you cannot deploy hosts to local storage (you certainly can) but generally this type of deployment method is geared towards larger scale environments when stateless computing is preferred giving you the ability to scale your environment in a very short period of time. The unique configuration of each cluster node is handled by a Host Profile that is applied prior to the node becoming an active participant in the cluster.

Image creation starts at the MS PowerShell and vSphere PowerCLI level with the creation of custom image builds that are specific to your hardware and can be tailored to only include the necessary VIB’s (Software Packages) that are pertinent to your hardware. This helps with boot times as well as having a bloated image that contains drivers for hardware you don’t even have.

These image profiles are stored in what are called “Software Depots” and are usually stored on the server that is handing out the images to the hosts which generally happens on the vCenter server.

There are two methods to creating these images; one from the PowerShell command line and the other is to use PowerGUI (My personal favorite and the method I will be talking about in this post).

As for the infrastructure that supports this deployment method, there are a number of key services that need to be in place and configured for VMware Auto Deploy service to work. This includes a DNS server that will have DHCP reservation addresses in it and have the associated host names as static entires, a DHCP Server that will serve as a target for the gPXE booting hosts with a custom scope that has a pointer to the TFTP server that will deliver the custom ESXi image, installation of the VMware Auto Deploy server on the vCenter server (where you obtain the TFTP boot zip file from, this file needs to be placed in the TFTP_Root directory of your TFTP server in unzipped format), a custom ESXi image (as stated above), a host profile attached to the install process and proper answer files for them.

List of Required Software & Hardware:

  • vCenter 5 (with datacenter, clusters & folders properly configured)
  • Minimum 4GB RAM & a separate volume recommended
  • SAN Storage (with a list of target IP’s and volumes for iSCSI or NFS)
  • NIC MAC Addresses of the targeted hosts for deployment
  • FQDN’s (fully qualified domain names) and IP Addresses for each of the targeted hosts
    • Network Mask
    • Routing Address
    • Primary & Secondary DNS Servers
    • IP Address and NetMasks for the VMkernel management network as well as for storage, FT & vMotion
  • vSphere Install Image
  • VMware PowerCLI & Microsoft PowerShell
  • TFTP Server (Not Windows 2008 TFTP)
  • DHCP Server (Windows DHCP OK)
Auto Deploy Points to Remember:
  • The TFTP Server that is included with Windows 2008 is not recommended to use with VMware Auto Deploy
  • If you a using VMware Auto Deploy to install on a DAS (Direct Attached Storage) vSphere will do a check on each system for local storage devices and existing partitions and will not create partitions if the DAS:
    • Has remote storage
    • Contains a GPT partition map
    • Has a MBR table that has any partitions defined within it
  • The network segment that you are deploying on must have total control of the broadcast domain. No other DNS, DHCP or TFTP server can exist on the subnet!
*Note about unknown partitions to vSphere: Auto Deploy will overwrite these partitions and create a new one. Linux LVM is one such partition type that vSphere does not recognize.

*Note about EFI hosts: These MUST be set in BIOS compatibility mode.

Using PowerGUI to Create Custom Images:

I started using PowerGUI a while back and ever since they released a PowerPack for VMware, I’ve been a big fan. During the installation, you have the option to install the VMware PowerPack and you will need to install the Windows Management Framework Core Package (Windows PowerShell 2.0 and WinRM 2.0) along with VMware vSphere PowerCLI 4.1 or later (I recommend version 5.0). After the install, launch PowerGUI and go to the administrative console. Click on tools and then select “Find PowerPacks Online” and search for “Auto Deploy”. There you will find Alan Renouf’s PowerPack (image 1) that you will download and install into your PowerGUI console. It should look something like (Image 2) when installed.

Image 1

Image 2

There are a number of things to discuss regarding the VMware PowerPack, but that is beyond the scope of this post and information that I will be writing about in the very near future.

After installation, you will need to connect to your vCenter server through the “Connect/Disconnect” item under the Image Builder & Auto Deploy section. The next step will be to connect to the VMware “host update” site to when connecting to the Software Depot within the tool. This is constantly being updated by VMware so when you point your PowerGUI client to the depot, you are always obtaining the latest and greatest from them.

This is located at this address: http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

After you connect your client to the VMware Software Depot, you can then look at the Image Profiles that are contained within the depot. Under the name column, they are easily identified with build numbers and the type of install they are.

Software Packages (next item below Image Profiles), lists the various drivers and tools that come with the selected Image Profile.


Cloning a profile is the next logical step in creating your own customized image within PowerGUI. One way is to clone from the “Actions” menu on the righthand side and the other way is to right-click the Image Profile that you want cloned, select Image Profiles and then click on “Clone Profile”. This brings up a window where you enter the name of your custom profile.

When your clone is complete, you can then start the process of removing or adding software packages to the image. When you have this file compiled to match your hardware, you can then export the image as either an ISO or a Zip file to be added to the Auto Deploy server to be handed out in the designated segment discussed earlier.

Creating an Answer File for host uniqueness:

Now that the image is ready to be used on your massive VMware virtual infrastructure, you must now create an Answer File that is to be applied to each host that receives the ESXi image. This is done by creating a Answer File from a reference host (much like we do with existing profiles).

Maintaining your Answer Files for Auto Deploy:

  • Checking the Answer File Status
    • Complete – Valid Answer File
    • Incomplete – Missing necessary answers
    • Missing – Not found
    • Unknown – Status of the answer file is unknown
      • This will occur upon the creation of the first answer file
  • Update the Answer File
    • Simple right-click on it to update values
  • Import & Export Answer Files
    • The Imported answer file must be linked to one of the hosts in the cluster.
  • Syslog Configuration of the Answer File
    • Remote log shipping for each host since they have no local storage
    • Logs can be sent to the new VMware SysLog Collector (new in vSphere 5).

Things to remember about Answer Files:

  • Answer Files are not stored in a format or location that administrators can access. You must use the UI in the VIC (vSphere Interface Client) to edit them.
  • When the profiles are executed, you must place a value in each and every field that is presented or the profile will fail to apply to the host.
  • The host must be in maintenance mode to apply a answer file to.

Thanks for reading,


vSphere Management Assistant (vMA) Review

After my last post, I decided to hang out in the vMA for a while to get acclimated with it. I’ve been using it off and on for quite a while now, but over the last few days I have been living in it. I found a few things that I think are pertinent to anyone who uses this.

First off, I should start with the basics. The vSphere Management Assistant comes from VMware in an OVF format for easy insertion to your virtual infrastructure. The management stations supports any version of ESX or ESXi from version 3.5 update 2 to present. It also consumes 512mb of memory from the host(s) and has a standard 5GB vDisk attached to it. It has two users that are already setup, one is the vi-admin account for administrative operations and the other the vi-user account with read-only rights to execute vCLI commands with. You can even join the vMA to an AD domain if you want to.

I’ve deployed about 5 of them so far and here are a few things that I do to these appliances:

1) Give it a static address and a proper DNS name so it is easy to get to and available when you need it. This can be done during the setup phase or you can run a pre-built script located in /opt/vmware/vma/bin/vmware-vma-netconf.pl – you will notice that you need to become root in order to run this, so see below to reset the password.

2) Change the root password of the appliance (since it is necessary to ‘su’ to run certain scripts on it). You can do this by running the following command: # sudo passwd root

Here are some handy commands and capabilities that you can use for the vMA:

  • Scan for updates to the vMA: # vma-update scan
  • Update the vMA (after you’ve scanned for updates): # vma-update update

Neat capabilities:

  • You can run custom code that force proprietary software or hardware components to work with ESXi.
  • Developers can you the integrated API’s within the VmaTargetLib (library) to connect to vMA targets via Java or Perl.
  • Administrators can add vCenter servers as well as ESX/ESXi nodes as potential “targets” to run scripts. This allows for a single sign on type of mechanism.
  • You can even re-use your old service console scripts that you may have used on older ESX systems.