A Home Lab Basics: Part 1 – An automated ESXi installation

Over time almost every virtualisation specialist asks himself a simple question: ‘Do I need a home lab?’

In recent years, this topic has become more and more popular. Many top bloggers write at least once about their experience with building a home lab; some contribute more to the community providing scripted installs, OVA-templates for the nested virtualisation, and even drivers for unsupported devices.

There is plenty of choice in terms of hardware platforms and networking devices to build your lab (including Raspberry Pi), and the sky’s the limit.

My preference would be for the all-in-one solution, and the rest is done in the nested environment. It should be relatively compact and quiet, with minimum wired connections to the router – an ideal option for someone leaving in the apartment.

As a result of my research, I bought Lenovo P-series ThinkStation with two Intel Xeon CPUs and 80 GB of RAM a few years ago. Instead of using magnetic drives, I put in NVMe M.2 SSDs (used for the VMFS and vSAN datastores) and one USB flash drive for the ESXi boot partitions. A workstation has two onboard 1 Gbps network cards and I have added an additional quad-port 1 Gbps PCIe card to test different configurations (bonding, path-through, etc). All NICs are connected to the router which provides access to the home network and to the Internet.

This platform is sufficient for setting up the vSphere, vSAN, and vRealize Automation labs.

In a serious of articles, I am planning to show how to automate different parts of those labs. It all starts here with the scripted ESXi installation using a bootable USB flash drive.

To create a bootable media, we need to do the following steps:

  1. Format a USB flash drive to boot the ESXi Installer.
  2. Copy files from the ESXi ISO image to the USB flash drive.
  3. Modify the configuration file SYSLINUX.CFG.
  4. Modify the configuration file BOOT.CFG.
  5. Create an answer file KS.CFG.

In the paragraphs below, I am going to discuss those steps in detail.

Step #1 – Format a USB flash drive

Depending on the operating system, the process can vary. In the official documentation, VMware details this task for Linux. To have it done on the computer with Mac OS, I used steps described in the blog posts here and here.

Firstly, we need to identify the USB disk using the diskutil list command. In my case, it is /dev/disk2.

Then, we erase that disk using the diskutil eraseDisk command:

diskutil eraseDisk FAT32 ESXIBOOT MBRFormat /dev/disk2
Started erase on disk2
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk2s1 as MS-DOS (FAT32) with name ESXIBOOT
512 bytes per physical sector
/dev/rdisk2s1: 7846912 sectors in 980864 FAT32 clusters (4096 bytes/cluster)
bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=2048 drv=0x80 bsec=7862272 bspf=7664 rdcl=2 infs=1 bkbs=6
Mounting disk
Finished erase on disk2

It is important to choose the MBR format for the disk (MBRFormat option). Otherwise, when you boot from this USB, the ESXi won’t be able to copy data from that partition and will generate the following error message: ‘exception.HandledError: Error (see log for more info): cannot find kickstart file on usb with path — /KS.CFG.’

As a result, you will have one MS-DOS FAT32 partition /dev/disk2s1. The next step is to mark it as active and bootable:

diskutil unmount /dev/disk2s1
Volume ESXIBOOT on disk2s1 unmounted

sudo fdisk -e /dev/disk2
fdisk: 1> flag 1
Partition 2 marked active.
fdisk:*1> write
Writing MBR at offset 0.
fdisk: 1> quit

Before copying any data into USB, we need to remount /dev/disk2s1:

diskutil unmount /dev/disk2s1
Volume ESXIBOOT on disk2s1 unmounted
diskutil mount /dev/disk2s1
Volume ESXIBOOT on /dev/disk2s1 mounted

Step #2 – Copy the ESXi ISO image files to the USB flash drive

There are two simple steps – mount the ISO file and copy data to the USB drive. In the example below, I used the VMware ESXi 6.7 Update 2 image.

hdiutil mount VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

cp -R /Volumes/ESXI-6.7.0-20190402001-STANDARD/ /Volumes/ESXIBOOT/

Step #3 – Modify SYSLINUX.CFG

We need to rename ISOLINUX.CFG to SYSLINUX.CFG:


Then we define a location of BOOT.CFG (here ‘-p 1‘ refers to /dev/disk2s1):

sed -e ‘/-c boot.cfg/s/$/ -p 1/’ -i _BACK /Volumes/ESXIBOOT/SYSLINUX.CFG

Step #4 – Modify BOOT.CFG

Now we need to add a path to the answer file (ks=usb:/KS.CFG) into the boot loader (BOOT.CFG).

However, there are two boot loaders available with the image – one for the BIOS boot, and another one for EFI.

find /Volumes/ESXIBOOT -type f -name ‘BOOT.CFG’

So it makes sense to edit both of them to eliminate any possible issues.

sed -e ‘s+cdromBoot+ks=usb:/KS.CFG+g’ -i _BACK $(find /Volumes/ESXIBOOT -type f -name ‘BOOT.CFG’)

In the example above, I created a backup of the original BOOT.CFG files and replace ‘cdromBoot‘ with ‘ks=usb:/KS.CFG‘ inside them.

Step #5 – Create KS.CFG

Finally, we can work on the answer file that will be used to automate the ESXi host installation.

In a basic scenario, the KS.CFG file should include the following:

  • Accept VMware License agreement,
  • Set the root password,
  • Choose the installation path,
  • Set the network settings,
  • Reboot the host after installation is completed.

A best practice would be to encrypt the root password. This can be done using OpenSSL:

openssl passwd -1

To identify the installation path, I normally boot ESXi with a dummy installation script and then use a local console to search for the device names in /vmfs/devices/disks. An MPX format is a preferable option for the disk device name.

A sample installation script is shown below.

In the next post, I will show how to complete the initial server configuration using PowerCLI.

vSphere 6.5: Additional considerations when migrating to VMFS-6 – Part 2

In the Part 1 of this series, I was writing about the most common cases which might prevent a successful migration to VMFS-6. There is another one to cover.

For ESXi hosts that boot from a flash storage or from memory, a diagnostic core dump file can also be placed on a shared datastore. You won’t be able to un-mount this datastore without deleting a core dump first.

VMware recommends using an esxcli utility to view/edit the core dump settings. This also can be automated via PowerCLI.

To check if the core dump file exists and is active, please use the following code:

To delete an old configuration that points to the VMFS-5 datastore, the following script can help:

With this change made you would be able to continue migrating to VMFS-6 without any issue.

If you have any suggestions or concerns, feel free to share them in the comments below.

PowerCLI: Housekeeping after upgrading to the latest version of PowerCLI

With a new version of VMware PowerCLI 11.1.0 released, it is time to plan for an upgrade.

Even if it is simply a matter of one command in PowerShell, you need to remember that the Update-Module cmdlet does not remove the old modules from the operating system (OS). So over the time, it might look a bit messy:

Following a few threads in regards to this issue (here and here), I wrote a simple script that removes the old versions of VMware.PowerCLI and its dependencies from Windows OS.

A few minutes later, it looks much cleaner with only the latest version of VMware.PowerCLI remaining:

Hope it will be useful for you as well.

Windows: Three ways to map a network drive using PowerShell

This subject is not directly related to virtualisation. However, it can be useful when you are not going to utilise Group Policy, and still need to automate drive mapping.

The old school

net use <drive_letter:> <UNC_path_to_the_network_drive> /persistent:[yes|no]

Pros: simple command that works.

Cons: not native to PowerShell; can be deprecated in the future.

Documentation: https://technet.microsoft.com/en-us/library/bb490717.aspx.

PowerShell 3.0+

New-PSDrive -Name <drive_name> -Root <UNC_path_to_the_network_drive> -PSProvider FileSystem -Scope [Global|Local] -Persist:[$true|$false]

New-PSDrive creates temporary and persistent mapped network drives. The scope should be set to allow other applications properly use mapped drives.

Pros: native to PowerShell.

Cons: require PowerShell 3.0+ to be fully functional.

Documentation: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-psdrive.

PowerShell 5.0+

New-SmbMapping -LocalPath <drive_letter:> -RemotePath <UNC_path_to_the_network_drive> -Persistent:[$true|$false]

New-SmbMapping creates a Server Message Block (SMB) mapping on the SMB client to an SMB share.

Pros: native to PowerShell.

Cons: this cmdlet had some issues before PowerShell 5.0.

Documentation: https://docs.microsoft.com/en-us/powershell/module/smbshare/new-smbmapping.