Auto Deploy Stateless Caching Provisioning

The initial release of Auto Deploy in vSphere 5.0 was focused and limited to stateless provisioning use cases. Now, in vSphere 5.1 Auto Deploy has been updated to support Stateful and an enhanced version of Stateless provisioning called Stateless Caching.

Auto Deploy Stateless provisioning allows diskless hosts to automatically install and configure ESXi by downloading images via a PXE boot process. The installation’s unique configuration items are applied as part of the build process but it’s handled by Host Profiles. The ESXi image and it’s configuration are then retain in local RAM. This solution initially presented some areas of concerns in regards to the overall availability of the solution. The failure of any Auto Deploy dependent services such as TFTP, PXE, DHCP puts the solution at risks as neither new hosts or rebooted hosts will be able to download their respective images. While those are valid concerns, they can be address with the right architecture design and implementation that focuses on mitigating those risks. It’s safe to say, the initial release of Auto Deploy presented a few limitations, but the new release delivers much improves in those areas.

In vSphere 5.1 two new provisioning options have been added to Auto Deploy, Stateless Caching and Stateful Installs.Stateless Caching works much like the Stateless deployment option found in the previous and current version of vSphere, but it addresses the availability concerns with the new feature. Stateless Caching introduces the ability to save (cache) the ESXi image to an assigned storage device (Local disk, SAN, USB). Now, this option could have an impact with the overall cost and initial manageability of any environment if procuring storage media is required. All hosts boot process needs to be configured with a specific boot order, and with a minimum of 1 GB storage capacity on a supported storage media device. The boot order for Auto Deploy stateless cashing should be setup in the following order:

Network boot device first

Hard Drive or Removable Device (USB)

Stateless Caching Boot Order

Now how does this work? and How and when is the image cached?

The caching of the ESXi image takes place after the download and configuration are completed and running in local RAM, the image is then copied to the local storage device. This procedure acts as the fail back mechanism for hosts in the event any of the Auto Deploy dependent services fail or are unavailable for image downloads. The Auto Deploy Stateless Caching configuration has to be defined within the Host Profiles settings. Figure below illustrates the options available for Stateless Caching under the advanced configuration settings of a Host Profile.

Host Profiles Stateless Caching Setting

Under normal operations hosts will run in stateless mode, but in the event of a service or component failure the boot process will fail back to the boot image cashed to the storage device. The argument for first disk and the check to overwrite VMFS volumes on the selected disk capability options are only available if a storage device other than USB is selected. VMFS volumes cannot be created in USB storage media.

While Stateless Caching addresses some of the availability concerns surrounding Stateless provisioning, it’s important to understand that in scenarios where host have been configured with Stateless Caching it doesn’t guarantee that hosts will be fully functional and able to contact the vCenter Servers and other systems. One of primary benefit of Stateless Caching is the fact that hosts are brought online to facilitate troubleshooting and help resolve problems that prevent a successful PXE boot.

Currently Auto Deploy in vSphere 5.1 is only available via the C# client (thick client), I hope VMware releases for the new vSphere Web Client soon.Auto Deploy remains a PowerShell CLI centric tool in vSphere 5.1. A Technical Preview GUI plug-in is available for vSphere 5.0 but that version i snot currently compatible with vSphere 5.1 so you may need to keep your PowerCLI skills up to date until the GUI is available.

I’m a big fan of Auto Deploy as it’s extremely handy and now with even more relevance in the era of the Software Defined Datacenters.

Alex,
I havent tested this but I’m going to assume that it is possible. Basically in vSphere 5.1 Auto Deploy has new capabilities and its compatibility is based on vSphere 5.1. It supports two new provisioning methods as functions which are not specifically related to the image you trying to push out. If you setup and activate an ESXi 5.0 image in Auto Deploy 5.1 it should work. I will try to test this and confirm it 100% when I get chance. If you get to do it before I get back to you, please let me know the results.

Yes, Stateless Caching is supported with SAN LUNS. I believe one of the ways is to use argument “remote”. Though as with using “local” if you choose “remote” you cannot identify the exact FC LUN which will be selected. To avoid this, you can use any of other or some combination of arguments like vendor,driver,esx etc. hope that helps

Still working on the suppose but seems SAN caching is not working, as expected. How can Auto Deploy know where to make a copy when no LUN ID/SCSI ID can be given. The combination of arguments is a farce, i have 72 disks all the same vendor and model etc. (that is why you have a SAN:-) ). So back to stateless without any caching (hopefully it will work with version 2 or 3 of auto deploy, but for now VMware is more and more looking like Microsoft, release something and then see if it works then after a couple of versions it will work).