vSphere5 introduced a brand new way to deploy the hypervisor – ESXi5 to the physical machine. There’s still the...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
option to install to storage – be that USB/SD-Card, DAS, or boot-from-SAN – but a new feature called “Auto-Deploy” has been developed to allow the booting of the hypervisor across the network using PXE booting. This should allow for a “state-less” ESX host – and make it very easy to deploy a new rack of servers or replace a dead server. It also means that the ESX host can be totally diskless, with its state being delivered on-demand as it boots, rather than being “stored” as configuration files on the host itself.
This requires a DHCP service and a TFTP service to provide an IP address to the booting server, and files required to make boot process work. The VCVA has these services built-in to it, and if you are running the Windows version of vCenter – then you're likely to just use an existing DHCP/TFTP service already available in your environment.
Auto-Deploy should make the long-term deployment of ESX hosts much faster – however, at the moment you might find its use in production limited at the moment. Auto-Deploy requires the use of Host Profiles to configure the ESX host after the boot process has completed – and with Host Profiles being an Enterprise+ feature only – this might stymie its wide-spread adoption in the VMware Community. With that said, the customers who are MOST likely to benefit from this are customers with a large installation base such as Service Providers – who (lets face it) would regard Enterprise+ licensing as a “standard” in their data centers.
Auto-Deloy Boot Process
When a server boots for the first time – its BIOS is configured such that it boots from the physical NIC first – and gets allocated an IP address. In the DHCP scope options a record is added to tell it where to find the boot files from the TFTP service. Next the server connects to a “Waiter” service on the server running the Auto-Deploy Service. Using a range of criteria (IP address, MAC address etc) auto-deploy select a “Host Image” (a build of ESXi5 that might contain custom components such as driver for ESX to use for a Teradici APEX card, or support for EMC PowerPath), a Host Profile and its location in a HA/DRS Cluster (auto-deploy supports auto-add of the ESX host into the vCenter management system). Once gathered the ESX host boots from the image file, and the host profile is applied on completion. This represents a run-once situation (where a brand new host is added for the first time), after that subsequent reboots if they happen, mean the ESX host is repeatedly added and removed from vCenter.
As vCenter is now closely associated with the boot process this can pose an issue for customers who have virtualized their vCenter (which is now considered by VMware to be a recommend best practise). In this case you would create a management cluster of ESX hosts that booted from disk – that then contained the virtualized vCenter/Auto-Deploy Service – which would assist in the deployment of the rest vSphere5.
Image builder is actually collection of PowerCLI tools that allow to create you own custom ESXi5 builds and apply them to different groups of servers. There is a currently a GUI front-end of it as a VMware Fling on their VMware Labs website.
An image consists of a core hypervisor, CIM provider, plug-ins, drivers – which are complied into VIBs (VMware Infrastructure Bundles). It's possible to add and remove VIBs – although it's more common to add VIBs from 3rd parties to add functionality. Using the cmdlet Add-ESXSoftwareDepot, it's possible to add the default image that ships with ESX download – to then clone it to make your own custom image by adding additional VIBs to it. Although Image Builder is closely associated with Auto-Deploy, it can be used in a stand-alone function to create your own custom build of ESX.