I recently got a request from a customer of mine to deploy ESXi server through WDS (Windows Deployment Services).
Before you read any further, you should already be familiar with WDS, PXE-Booting, TFTP, DHCP and similar terms surronding the WDS deployment mechanism. If you use WDS already, you probably know this already. If not, I suggest you cover your basics and learn how to setup WDS for regular windows deployment before implementing the ESXi deployment
It may not make sense to some as to why we use WDS… surely there are more standard ways to achieve this (Linux deployment, VMware auto deploy, etc.). Well, let me give you a bit of background on the use case and the environment setup so it will all make sense.
The environment is windows-native and WDS is already a key piece in the deployment process of the infrastructure. The request was to add ESXi deployment through the same WDS component to keep things central and simple.
At first, it looked like a no-brainer. A quick google search showed multiple blogs describing such use-cases and VMware even has official documentation on deploying ESXi through PXE (although not clearly specifying WDS)
However, I faced some unique factors in the current environment that weren’t clearly covered in documentation. Mainly, the fact that our servers are EFI-based. Although EFI is becoming the standard, I couldn’t find a solid way to make it happen.
In addition, many of the articles are suggesting the approach of changing the boot screen from WDS to Linux and the use of PXE linux. We wanted to keep things as-is and as such it wasn’t a good solution (adding another Linux server will just complicate the environment and will require adjustments to maintain deployment for Windows machines)
Before we dive into the “how”, some things about the environment and requirements you should understand –
- WDS already deploys Windows servers and workstations based on EFI
- All the setup for the windows machines is done in advanced so the end-user only presses F12 to boot from network and nothing more. This is called a “lite-touch” install and you can find many documents on how to achieve that through WDS.
- WDS is also a DHCP server and all machines are using reserved IPs
- The building blocks are:
- Pre-stage the windows machine in AD using the machine’s MAC address as a unique identifier
- Define boot program for the machine
- Define boot image for the machine
- Configure an answer file to answer all the question during installation
So, the request was to keep things as-is for the most part, and simply add the ESXi capability on top of that, using the same deployment concepts
To achieve this, we need –
- The ESXi MAC address
- A new, EFI-based boot program for the ESXi server
- A Kick-Start answer file to automate the installation itself
Extract the ESXi ISO to a folder under your remoteinstall\boot\x64 (Remoteinstall being the folder you share on WDS that holds all WDS data). For me, I called in ESXi6U2 (this is the ESXi version I’m installing)
Copy the file from ESXi6U2\EFI\Boot called BOOTX64.EFI to the ESXi6U2 folder and rename it to mboot.efi. This file will be used as the Network Boot Program (NBP) to boot our ESXi from WDS (we will get to that shortly)
Under the ESXi6U2 folder, modify the boot.cfg and add the below line before the line that starts with modules=
Please note, the prefix= should include the relative path to the ESXi folder you extracted in the first phase. If you called it something different in your environment, you should modify the line accordingly (I will add a full boot.cfg sample file later in this manual)
Open regedit and modify HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP\ReadFilter key with the following data (the lines marked in bold are my additions)
\boot\* \tmp\* boot\* tmp\* /boot/* boot/*
Restart WDS service and you’re ready to deploy your ESXi!
Our last step is to assign the mboot.efi as the NBP for the deployed ESXi client. This can be achieved in several ways, and it really depends on how you wish to manage your clients. My setup is this:
Start by creating the device in WDS console by right-clicking Active Directory Prestaged Devices and choose add device
Provide a name for the client and the MAC address and click next
Choose use the following boot program and then you can browse to the mboot.efi file to assign it to the prestaged device
As there are multiple ways to accomplish this, the key thing to remember is that you should assign mbooti.efi as the network boot program for the ESXi before you start the deployment
At this point you can boot your ESXi host, boot from the network and the installation should start. From this point forward, install it as you would install any ESXi. Keep in mind that your ESXi BIOS should be EFI (or UEFI) based
bootstate=0 title=Loading ESXi installer timeout=5 kernel=tboot.b00 kernelopt=runweasel prefix=/Boot/x64/ESXi6U2 modules=b.b00 --- jumpstrt.gz --- useropts.gz --- k.b00 --- chardevs.b00 --- a.b00 --- user.b00 --- uc_intel.b00 --- uc_amd.b00 --- sb.v00 --- s.v00 --- mtip32xx.v00 --- ata_pata.v00 --- ata_pata.v01 --- ata_pata.v02 --- ata_pata.v03 --- ata_pata.v04 --- ata_pata.v05 --- ata_pata.v06 --- ata_pata.v07 --- block_cc.v00 --- ehci_ehc.v00 --- elxnet.v00 --- emulex_e.v00 --- weaselin.t00 --- esx_dvfi.v00 --- esx_ui.v00 --- ima_qla4.v00 --- ipmi_ipm.v00 --- ipmi_ipm.v01 --- ipmi_ipm.v02 --- lpfc.v00 --- lsi_mr3.v00 --- lsi_msgp.v00 --- lsu_hp_h.v00 --- lsu_lsi_.v00 --- lsu_lsi_.v01 --- lsu_lsi_.v02 --- lsu_lsi_.v03 --- lsu_lsi_.v04 --- misc_cni.v00 --- misc_dri.v00 --- net_bnx2.v00 --- net_bnx2.v01 --- net_cnic.v00 --- net_e100.v00 --- net_e100.v01 --- net_enic.v00 --- net_forc.v00 --- net_igb.v00 --- net_ixgb.v00 --- net_mlx4.v00 --- net_mlx4.v01 --- net_nx_n.v00 --- net_tg3.v00 --- net_vmxn.v00 --- nmlx4_co.v00 --- nmlx4_en.v00 --- nmlx4_rd.v00 --- nvme.v00 --- ohci_usb.v00 --- qlnative.v00 --- rste.v00 --- sata_ahc.v00 --- sata_ata.v00 --- sata_sat.v00 --- sata_sat.v01 --- sata_sat.v02 --- sata_sat.v03 --- sata_sat.v04 --- scsi_aac.v00 --- scsi_adp.v00 --- scsi_aic.v00 --- scsi_bnx.v00 --- scsi_bnx.v01 --- scsi_fni.v00 --- scsi_hps.v00 --- scsi_ips.v00 --- scsi_meg.v00 --- scsi_meg.v01 --- scsi_meg.v02 --- scsi_mpt.v00 --- scsi_mpt.v01 --- scsi_mpt.v02 --- scsi_qla.v00 --- uhci_usb.v00 --- vsan.v00 --- vsanheal.v00 --- vsanmgmt.v00 --- xhci_xhc.v00 --- tools.t00 --- xorg.v00 --- imgdb.tgz --- imgpayld.tgz build= updated=0
But wait, there’s more…
What if you want to further automate the deployment. For example, why would you need to accept the EULA, choose the hard disk to install the ESXi on, etc.
Well, this is where ks.cfg comes into play.
ks.cfg is basically a file with different configurations to auto configure the installation of the ESXi
In my next post, I will show you how to add a simple ks.cfg file and use the same WDS server as a web server to distribute the file to the deployed ESXi host.
By the end of the next post, you can fully deploy your ESXi from start to finish simply by pressing F12 to boot it from the network and nothing more.
Sounds good? Stay tuned