WDS and ESXi Deployment (EFI Based)

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 surrounding 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)

The concept

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

WDS Preparation

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)

1

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)

2.jpg

Under the ESXi6U2 folder, modify the boot.cfg and add the below line before the line that starts with modules=

prefix=/Boot/x64/ESXi6U2

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/*

3.jpg

Restart WDS service and you’re ready to deploy your ESXi!

Client Handling

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

4.jpg

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

Sample boot.cfg

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

Advertisements

One thought on “WDS and ESXi Deployment (EFI Based)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s