Using vSphere Auto Deploy
cover the following recipes:
- Enabling vSphere's auto deploy service
- Configuring a TFTP server with the files required to PXE boot servers
- Configuring a DHCP server to work with auto deploy
- Preparing the vSphere environment – create host profile, configure the deploy
- rules and activating them
- Enabling stateless caching
- Enabling stateful install
Introduction
In a large environment, deploying, and upgrading ESXi hosts is an activity that requires a lot of planning and manual work. For instance, if you were to deploy a set of 50 ESXi hosts in an environment, then you might need more than one engineer assigned to perform this task. The same would be the case if you were to upgrade or patch ESXi hosts. The upgrade or the patching operation should be done on each host. Of course, you have vSphere update manager that can be configured to schedule, stage, and remediate hosts, but again the process of remediation would consume a considerable amount of time, depending on the type and size of the patch. VMware has found a way to reduce the amount of manual work and time required for deploying, patching, and upgrading ESXi hosts. They call it vSphere auto deploy. In this chapter, you will learn not only to design, activate, and configure vSphere auto deploy but also to provision the ESXi hosts using it.
vSphere auto deploy architecture
vSphere auto deploy is a web server component that, once configured, can be used to quickly provision a large number of the ESXi hosts without the need to use the ESXi installation image to perform an installation on the physical machine. It can also be used to perform the upgrade or patching of the ESXi hosts without the need for vSphere update manager. Now, how is this achieved? vSphere auto deploy is a centralized web server component that lets you define rules that govern how the ESXi servers are provisioned. It, however, cannot work on its own. There are a few other components that play a supporting role for auto deploy to do its magic and here they are:
- The auto deploy service
- A DHCP server with scope options 66 and 67 configured
- A TFTP server hosting files for a PXE boot
- Servers with PXE (network boot) enabled in their BIOS
- Host profiles configured at the vCenter server
The ESXi Host first begins to network boot by requesting for an IP address from the DHCP Server. The DHCP Server responds with an IP address and the DHCP scope options
providing the details of the TFTP Server. The ESXi Host then loads the PXE boot image from the TFTP Server to bootstrap the machine and subsequently sends an HTTP Boot
Request to the Auto Deploy Server, to load an ESXi Image into the host's memory. The image is chosen based on the rules created at the Auto Deploy Server. The workflow is
shown here:
Enabling vSphere auto deploy service
Auto deploy services, by default, are left disabled and need to be enabled explicitly. Understandably so, unless the environment warrants having specific features, they are left disabled to keep the resource consumption optimal. There are two specific services that need to be enabled to ensure that auto deploy functions as desired. In this recipe, we shall walk through the process of enabling the auto deploy service and image builder service on the vCenter Server Appliance.
The following procedure through enabling the appropriate services to activate
Auto Deploy:
1. Log in to vCenter Server Appliance.
2. Navigate to Home | Administration | System Configuration as illustrated in the
following screenshot:
3. Click on Nodes and select the intended vCenter instance and Related Objects as
shown here:
4. Highlight Auto Deploy service and click on Start.
5. Click on Settings and set Automatic to start automatically as shown here:
6. Highlight ImageBuilder Service and click on Start.
7. Click on Settings and set Automatic to start automatically.
8. Confirm that services are started from the Recent Tasks pane:
How it works...
Auto deploy services are, by default, left to start manually although integrated with vCSA. Hence, if the environment warrants having the feature, the administrator has to enable the service and set it to start automatically with vCenter.
Configuring TFTP server with the files required to PXE boot
Trivial File Transfer Protocol (TFTP) enables a client to retrieve a file and transmit to a remote host. This workflow concept is leveraged in the auto deploy process. Neither the protocol nor the workflow is proprietary to VMware. In this recipe, we shall use an open source utility to act as the TFTP server, there are other variants that can be used for similar purposes.
The following procedure would step you through configuring the TFTP server to be PXE boot ready:
1. Log in to vCenter Server Appliance.
2. Navigate to Home | vCenter | Configure | Auto Deploy
3. Click on Download TFTP Boot Zip instance as depicted here:
4. Extract the files to the TFTP server folder (TFTP-Root) as demonstrated in the
following screenshot:
5. Start the TFTP service as shown here:
How it works...
TFTP is primarily used to exchange configuration or boot files between machines in an environment. It is relatively simple and provides no authentication mechanism. The TFTP server component can be installed and configured on a Windows or Linux machine. In this recipe, we have leveraged a third-party TFTP server and configured it to provide the relevant PXE files on demand. The TFTP server, with the specific PXE file downloaded from vCenter, aids the host in providing a HTTP boot request to the auto deploy server.
Configuring the DHCP server to work with auto deploy
Once the auto deploy services and TFTP servers are enabled, the next most important step in the process is to set up the DHCP server. The DHCP server responds to servers in scope with an IP address and specifically redirects the server to the intended TFTP server and boot filename. In this recipe, we shall look into configuring the DHCP server with TFTP server details alongwith the PXE file that needs to be streamed to the soon-to-be ESXi host. In this recipe, we shall walk through setting up a Windows-based DHCP server with the specific configuration that is prevalent. Similar steps can also be repeated in a Unix variant of DHCP as well.
Getting ready
Ensure that the TFTP server has been set up as per the previous recipe. In addition, the steps in the following recipe would require access to the DHCP server that is leveraged in the environment with the appropriate privileges, to configure the DHCP scope options.
How to do it...
The following procedure would step through the process of configuring DHCP to enable PXE boot:
1. Log in to the server with the DHCP service enabled.
2. Run dhcpmgmt.msc.
3. Traverse to the scope created for the ESXi IP range intended for PXE boot.
4. Right click on Scope Options and click on Configure Options... as shown in the following screenshot:
5. Set values for scope options 066 Boot Server Host Name to that of the TFTP server.
6. Set values for scope options 067 Bootfile Name to the PXE file undionly.kpxe.vmw-hardwired as demonstrated here:
How it works...
When a machine is chosen to be provisioned with ESXi and is powered on, it does a PXE boot by fetching an IP address from the DHCP server. The DHCP scope configuration option 66 and 67 will direct the server to contact the TFTP server and load the bootable PXE image and an accompanying configuration file. There are three different ways in which you can configure the DHCP server for the auto deployed hosts:
1. Create a DHCP scope for the subnet to which the ESXi hosts will be connected to.
Configure scope options 66 and 67.
2. If there is already an existing DHCP scope for the subnet, then edit the scope
options 66 and 67 accordingly.
3. Create a reservation under an existing or a newly created DHCP scope using the
MAC address of the ESXi host.
Large-scale deployments avoid creating reservations based on the MAC addresses, because that adds a lot of manual work, whereas the use of the DHCP scope without any reservations is much preferred.
Preparing vSphere environment – create host profile, configure the deploy rules and activate them
Thus far, we have ensured that auto deploy services are enabled, and the environmental setup is complete in terms of DHCP configuration and TFTP configuration. Next, we will need to prepare the vSphere environment to associate the appropriate ESXi image to the servers that are booting in the network. In this recipe, we will walk through the final steps of configuring auto deploy by creating a software depot with the correct image, then we will create auto deploy rules and activate them.
How to do it...
The following procedure prepares the vSphere environment to work with auto deploy:
1. Log in to vCenter Server.
2. Navigate to Home | Host Profiles as shown here:
3. Click on Extract Profile from host as shown:
4. Choose a reference host based on which new hosts can be deployed and click on Finish:
5. Navigate to Home | Auto Deploy.
6. Click on Software Depots | Import Software Depot, provide a suitable name and browse to the downloaded offline bundle as shown here:
7. Click on the Deploy Rules tab and then click on New Deploy Rule.
8. Provide a name for the rule and choose the pattern that should be used to identify the target host; in this example we have chosen the IP range defined in the DHCP scope, also multiple patterns can be nested for further validation:
9. Choose an image profile from the list available in the software depot as shown here:
10. (Optional) Choose a host profile as shown here:
11. (Optional) In the Select host location screen, select the inventory and click on OK to complete:
12. Click on Activate/Deactivate rules.
13. Choose the newly created rule and click on Activate as shown here:
14. Confirm that the rule is Active as shown here:
How it works...
To prepare the vSphere environment for auto deploy, we perform the following steps:
1. Create a host profile from a reference host, a host profile conserves the efforts in replicating much of the commonly used configuration parameters typically used
in the environment. There is a natural cohesion of the feature with auto deploy.
2. Create a software depot to store image profiles, typically more than one depending on the environment needs.
3. Create deploy rules to match specific hosts to specific images.
In a complex and large infrastructure, there could be heterogeneous versions of products in terms of software, hardware, drivers, and so on. Hence, the auto deploy feature enables the
creation of multiple image profiles and a set of rules through which targeted deployments could be performed. In addition, auto deploy use cases stretch beyond the typical deployments to managing the life cycle of the hosts, by accommodating updates/upgrades as well.
There are two primary modes of auto deploy:
Stateless caching: On every reboot, the host continues to use vSphere auto deploy infrastructure to retrieve its image. However, if auto deploy server is inaccessible, it falls back to a cached image.
Stateful install: In this mode, an installation is performed on the disk and subsequent reboots would boot off the disk. This setting is controlled through the host profile setting system cache configuration.
Enabling stateless caching
In continuation of the previous recipe, an administrator can control if the ESXi hosts boots from the auto deploy on every instance of reboot, or perform an installation through auto
deploy and have subsequent reboots to load image from disks. The option to toggle between stateless and stateful is performed by amending the host profile setting. In this recipe, we shall walk through the steps to enable stateless caching.
How to do it...
1. Log in to vCenter Server.
2. Navigate to Home | Host Profiles.
3. Select the host profile and click on Edit host profile.
4. Expand Advanced Configuration Settings and navigate to System Image Cache Configuration as shown here:
. Select on Enable stateless caching on the host or Enable stateless caching to a USB disk on the host.
6. Provide inputs for Arguments for first disk or leave at default: this is the order of preference of disk on which the host would be used for caching. By default, it will detect and overwrite an existing ESXi installation, if the user indicates the specific disk make, model or driver used, the specific disk matching the preference is chosen for caching:
7. For the option Check to overwrite any VMFS volumes on the selected disk, leave it unchecked. This would ensure that if there were any VMs on the local VMFS volume, they are retained.
8. For the option Check to ignore any SSD devices connected to the host, leave it unchecked. You may need to enable this setting only if you have SSD for specific use cases for the local SSD, such as using vFlash Read Cache (vFRC).
How it works..
The host profile directs the installation mode in an auto deploy-based deployment. In a data center where we see blade architectures prevalent, the local storage is rather limited and data is more often stored in external storage with the exception of hyperconverged infrastructures. The stateless caching feature specifically aids in such scenarios to limit dependency on local storage. In addition, users may also choose the option to enable stateless caching to USB disk.
Enabling stateful install
While the stateless caching feature is predominantly built to tackle disk specific limitations on server hardware, the stateful install mode is more of a legacy installation through PXE mechanism. Apart from the installation procedure that is set to scale, it mimics the attributes of a standard manual installation. In this recipe, we shall walk through the steps to enable stateful install.
How to do it...
1. Log in to vCenter Server.
2. Navigate to Home | Host Profiles.
3. Select the host profile and click on Edit host profile.
4. Expand ;Advanced Configuration Settings and navigate to System Image Cache Configuration as shown here.
5. Click on Enable stateful install on the host or Enable stateful install to a USB disk on the host:
6. Provide inputs for Arguments for first disk or leave at default: this is the order of preference of disk on which the host would be used for installation. The administrator may also indicate the specific disk make, model or driver used, the specific disk matching the preference is chosen for installation.
7. For the option Check to overwrite any VMFS volumes on the selected disk, leave it unchecked. This would ensure that if there were any VMs on local VMFS volume, they are retained.
8. For the option Check to ignore any SSD devices connected to the host, leave it unchecked; you may need to enable this setting only if you have SSD for specific use cases for the local SSD such as using vFRC.
If this help please mark helpful or correct.