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 Replication Review (VR) in SRM 5

Ok, so VMware has this new replication method through SRM 5 (Site Recovery Manager) and I think that it is profound due to two reasons.

#1 It allows SMB customers the ability to replicate to a DR site without the need for an enterprise storage array on the back end. Think of the impact here – small companies can now implement a disaster recovery process!

#2 It operates at the vSphere level and allows an administrator the proverbial “single pane of glass” to see the virtual inventory at both locations!

Requirements for Enabling:

  • Virtual Machine version 7
  • Port 44046 and 31031 for sync transfers
  • One vSphere Replication Management Server per/vCenter
  • Must have vSphere 5 and SRM 5 installed

A few noteworthy benefits:

  • Full support of Microsoft VSS
  • Replication agent runs on the ESXi node as a host agent
  • Abstracts the storage layer allowing for replication regardless of the storage on either site
  • VM’s are configured for replication as a property of the virtual machine (you can tag one or all the VMDK’s for replication)
  • Traditional seed loading of the replicated site (such as an external drive)
  • Comes in a handy virtual appliance for quick installation (500 protected vm’s max)
  • Efficient use of bandwidth during replication (through the use of the VR Agent hostd)
  • Does an analysis on previous transfers to predict future ones

A few restrictions due to the way VR operates at the virtual disk layer:

  • You can’t replicate powered off machines (although, you can tag a powered off vm for replication, it won’t replicate until its powered on)
  • You can’t use Storage DRS (sDRS) or Storage vMotion with vSphere Replication.
  • No support for fault tolerance (FT) or Linked Clones
  • Performance hit during the initial sync (can schedule)

VR Replication Recap:

As I look at the technology, I see a lot of similarities to FT (Fault Tolerance). On the primary site, the vm’s disks that are marked for replication are monitored and all I/O blocks that are destined for a VMDK are compared at the replicated site and sent over the WAN to mirror that. This is all based on the Recovery Point objective that the administrator sets up. There are basically two areas where you can set up VR; one place is within SRM or it can be configured on a per vm basis as mentioned above.

All this without the use of snapshots!