One question I constantly receive from customers is how they can use Auto Deploy with their current TFTP solution, often they may have an existing TFTP server but still want to make use of AutoDeploy stateless installs to easily deploy and manage their ESXi hosts. This can also fall under the question of how can I deploy two sets of hosts to different vCenters on the same VLAN?
Both of these questions can be addressed in this post, the key thing to keep in mind is how we will be designing the DHCP/PXE/TFTP infrastructure to use AutoDeploy, there are multiple ways to achieve this depending on your companies environment and what best fits into your infrastructure. I have often heard from customers that they are unable to use AutoDeploy because they already have a PXE infrastructure, this is not always a roadblock.
Scenario
The scenario I have used for this post is that we have two vCenters, there is a vCenter for Infrastructure and a vCenter for the VDI environment, in this scenario we have a very simple network and both infrastructures are on the same network and the same VLAN.
I will assume that your initial AutoDeploy environment has already been setup and is deploying your ESXi hosts to your infrastructure environment, this document walks you through this entire process step by step.
The following instructions show how we would alter our existing environment to deploy ESXi hosts to a second vCenter for VDI workloads using the existing DHCP and TFTP server, as an overview I will be explaining the orange path below.
Step 1 – Updating the TFTP boot files
We first need to ensure we have a second Auto Deploy server which is setup to work with our VDI Infrastructure, once this has been enabled we would download the TFTP files from the Auto Deploy plugin in vCenter in the same way we did for our first server using the link entitled “Download TFTP Boot Zip”. Once you have the zip file, extract the files into a temporary location, the only file we need from the extracted files is the file named “tramp”. Rename this file and copy it into the TFTP boot folder where the original TFTP files are already deployed. In my screenshot below you can see I have named it trampVDI.
Step 2 – Altering the DHCP Scope
The second thing we will need to do is alter our DHCP server to enable us to specify a TFTP file to use when booting with iPXE and therefore taking us out of “hardwired” mode and allowing us to point our hosts in a specific direction. If we had two TFTP servers this would be as simple as setting up a second scope/reservation which had a different TFTP address as part of the options (option 66) but the idea of this post is to show how we can use the same DHCP and TFTP infrastructure. Throughout this blog post I will use a reservation to make my changes as an example of how this can be achieved.
During the boot process of a host there will be two sets of communication with the DHCP server, the first communication will be when the host boots with legacy PXE options and the DHCP server will send the host an IP address and a filename to boot iPXE from. Once the host has booted, iPXE will then use the tramp file to chainload the ESXi boot process. By default, the chainloading is all handled via the “undionly.kpxe.vmw-hardwired” file which has the name of the tramp file hard coded. However, we also give you another iPXE boot file, called “undionly.kpxe” which allows you to specify the name of the tramp file that is used to chainload the ESXi boot process. When booting with the “undionly.kxpe” there is some additional setup required as the name of the tramp file must be set as part of the DHCP options for the iPXE boot.
First we will need to setup our new reservation to boot from the “undionly.kpxe” file, this can be done by altering option 67 in the reservation. Next we will need to add an iPXE class to our DHCP server to tell it when a host iPXE boots using this reservation it will need to pick up our second tramp file (trampVDI).
To do this on a Windows DHCP server, when using DHCP Manager, right click on your IPv4 protocol object and select “Define User Classes” as can be seen below:
Click “Add” and define the new class as below, you just need to type iPXE in the ASCII field and the binary entries will be automatically filled out.
Once this has been added click OK and close to return back to the DHCP settings.
Now our iPXE class has been added we can adjust our reservation to take advantage of this, first click on “Configure Options” for the reservation and select the General tab, edit option 67 to now use the “undionly.kpxe” file as below:
Next select the Advanced tab and change the user class to iPXE
Change option 67 (Boot Name) to the new tramp file we added from our second Auto Deploy server and click OK, this setting will be the file that is used on the iPXE boot as described earlier.
Now if we compare our Infrastructure reservation with our VDI reservation you will see that they are set to boot from different boot file names and therefore will contact different Auto Deploy servers and be attached to different vCenter servers.
Infrastructure Host
VDI Host
Conclusion
It is possible to use multiple vCenters on the same network with Auto Deploy but each vCenter will need their own Auto Deploy server and the PXE infrastructure will need to be adjusted as shown in this post, this comes in handy when working with both existing PXE infrastructures and also deploying hosts automatically to different vCenters.
