Advantages | Drawbacks |
Patch management – Provides ease of deployment and patch management of large scale environments: • Ability to re-deploy new versions of ESXi to a large number of ESXi hosts. Increases refresh agility when managing many ESXi hosts. • Uses stateless ESXi hosts, memory is resident, and there is no need to have dedicated hard disks/volumes to run ESXi hosts. (Although some sort of storage is required for stateless caching.) | Complexity – Additional complexity when deploying to small number of servers. |
Eliminate configuration drift – By sharing a standard ESXi image profile across multiple hosts, all ESXi hosts are running the same ESXi version. In addition, each time a host is rebooted, it is like performing a fresh install of ESXi. | Management – Managed using vSphere PowerCLI, which might be less familiar to the customer (although a fling is available). • Heavily dependent on knowledge of vCenter Server host profiles and PowerCLI. • Heavily dependent on vCenter Server, which poses recoverability issues in the event of a site failure. (Use of vCenter Server heartbeat is supported.) • If vCenter Server is virtualized, the vCenter Server cluster of ESXi hosts must be deployed using installable ESXi. This cluster must be installed, patched, and updated differently from the vSphere Auto Deploy hosts. VMware recommends that vSphere Auto Deploy is not used when provisioning ESXi hosts in the case where a management cluster will be used to host the vCenter Server. The management cluster running vCenter Server must be configured with stateful booting. • VMware recommends installing vSphere Auto Deploy on a dedicated server. For each vCenter Server, a dedicated vSphere Auto Deploy server is required. |
Reduced storage costs – Because vSphere Auto Deploy installs directly into the host's memory, there is no need to dedicate a boot disk for each server. This not only saves money when purchasing new hardware and storage, but when booting from SAN, it helps to simplify the storage architecture by eliminating the need to map dedicated LUNs to each ESXi host. | Additional Infrastructure – vSphere Auto Deploy introduces several additional “mission critical” applications to the infrastructure management stack, such as TFTP, DHCP, PXE and vSphere PowerCLI. Issues with blade or access switching infrastructure might cause problems in a disaster recovery scenario after powering off and powering on the host. vSphere Auto Deploy might pose a single point of failure if the image profile is incorrectly configured and the PXE and DHCP architecture is unavailable. In this case, the servers would not be able to boot. (The vSphere Auto Deploy server can be protected with vCenter Server heartbeat.) Two options available in vSphere Auto Deploy can be configured to mitigate against this risk: • Stateless caching – Caches the image locally on the ESXi host, ready for an event where the PXE, DHCP, or vCenter Server architecture is not available. • Stateful Install – Installs the ESXi image in a stateful manner on the local disks, removable media or SAN LUN that will act in the same way as if it were installed manually. Both options negate some of the benefits of vSphere Auto Deploy by having to maintain local storage for cache/installation, but they reduce risk to the architecture. vSphere Auto Deploy uses the PXE network boot feature of an ESXi host and is fully dependent on an operational DHCP and a TFTP server. Additional DHCP scope options are required when configuring vSphere Auto Deploy: • 066 Boot Server Host Name (address of the TFTP server) • 067 Boot File Name (iPXE binary will be used to boot the ESXi hosts) vSphere Auto Deploy uses a PXE boot infrastructure that supports only IPv4. You can use vSphere Auto Deploy in a mixed IPv4/IPv6 environment or an IPv4-only environment, but not in an IPv6-only environment. |
Fast server provisioning – Deploying a new ESXi host is as simple as enabling PXE boot and powering on a new server. The vSphere Auto Deploy server identifies the new server, assigns an appropriate ESXi image profile and host profile, and places the server in the correct vCenter Server folder or cluster. Consider the following design points: • The vCenter Server that provisions vSphere Auto Deploy hosts must not be dependent on vSphere Auto Deploy. • Keeping the management cluster separate from the vSphere Auto Deploy infrastructure facilitates role-based access control. • It is easy to grow the environment if additional instances of vCenter Server and the vSphere Auto Deploy server are needed. | vSAN is not supported on a stateless host. |
vSphere Auto Deploy stateful deployment – vSphere Auto Deploy can also be used to provision an ESXi host and set up a host profile that causes the host to store the ESXi image and configuration on the local disk, a remote disk (boot from SAN), or a USB drive. Subsequently, the ESXi host boots from this local image. vSphere Auto Deploy no longer provisions the host. This process is similar to performing a scripted installation. With a scripted installation, the script provisions a host and the host then boots from disk. In this case, vSphere Auto Deploy provisions a host and the host then boots from disk. |