WilliamLam.com

How to copy the Raspberry Pi UEFI files and boot ESXi-Arm using just USB device?

by // 9 Comments

There are actually a number of ways to boot and install the ESXi-Arm Fling, but the easiest method is already outlined in the official ESXi-Arm Raspberry Pi (rPI) documentation and the PDF can be downloaded from the Fling website. As a quick refresher, you only need to have two storage devices.

  • SD Card - Used to store the rPI UEFI files which is required to boot ESXi-Arm Installer
    • ESXi-Arm can not run on SD Card and for these reasons, you do not need a large capacity SD Card
  • USB Device - Contains ESXi-Arm Installer / Installation
    • After the ESXi-Arm installer boots, you can actually re-use the exact same USB device for the installation of ESXi-Arm itself. A separate USB device is not required unless that is your goal or if the capacity is not enough for running VMs

The boot process after the ESXi-Arm installation is that the UEFI firmware will first load on the rPI and then it will boot up the ESXi-Arm from the USB device. As mentioned, there are other variations but this is the most basic option. The other nice behavior is that if you need to re-install ESXi-Arm, you simply create a bootable USB device with the ESXi-Arm installer and then install that right on the same USB device without having to mess with UEFI image. This also allows you to perform scripted installation also known as Kickstart, which is something I will be covering in the future that takes UEFI image into consideration.

I have seen a few questions asked whether it is possible to have everything run off of the SD Card and/or USB Device and the answer is yes to certain degree.

  • It is possible to put the ESXi-Arm installer + UEFI on SD Card but ESXi-Arm will NOT be able to use it as installation media, so there is not a whole ton of value there.
  • It is possible to have both the UEFI image and ESXi Installation on the same USB device, especially if you do not have spare SD Cards which apparently has come up a few times

In this blog post, I will outline the instructions for booting an installed ESXi-Arm installation completely off of the USB device without the needing an SD Card containing the UEFI image.

[Read more...]

Update on running ESXi on Intel NUC Hades Canyon (NUC8i7HNK & NUC8i7HVK)

by // 55 Comments

The Intel NUC is one of the most popular and affordable hardware platform for running vSphere and vSAN Home Labs. For customers that want a bit more computing power, Intel also has their Skull Canyon platform which was released back in 2016 and has also gained in popularity amongst VMware Home Labbers. To be clear, the none of the Intel NUC platforms are on VMware HCL and therefore are not officially supported.

Earlier this year, Intel released their second generation of their higher-end Intel NUCs dubbed Hades Canyon which comes in two flavors NUC8i7HNK and NUC8i7HVK, with the latter being the higher-end unit. Based on the previous generation of hardware, most customers assumed ESXi should just work and went out and purchased the lower-end "HNK" version just to find out that was not case. The ESXi Installer would boot up to a certain point and then stop with the following error:

“Shutting down firmware services…..

Using “simple offset” UEFI RTS mapping policy”

To add to the confusion, this issue was not observed with the higher-end NUC8i7HVK model which was also quite interesting. Over on the nucblog.net, they also confirmed ESXi runs fine on "HVK" model and the issue seems to be isolated to the lower-end "HNK" model.

[Read more...]

Using ESXi Kickstart %firstboot with Secure Boot

by // 6 Comments

If you install ESXi via a Kickstart script and make use of the %firstboot option to execute commands on the first boot of the ESXi host after installation, you should be aware of its incompatibility with the Secure Boot feature. If you install ESXi where Secure Boot is enabled, the Kickstart will install ESXi normally only execute up to the %post section. However, it will not execute the %firstboot scripts and if you look at the /var/log/kickstart.log after the host boots, you should see the following message:

INFO UEFI Secure Boot Enabled, skipping execution of /var/lib/vmware/firstboot/001.firstboot_001

If you have Secure Boot enabled, %firstboot is not supported. The reason for this is Secure Boot mandates only known tardisks which can hold executable scripts, and a kickstart script is an unknown source so it can not run when Secure Boot is enabled. If you wish to continue using %firstboot scripts, the only option is to disable Secure Boot and then re-enable it after the installation. A preferred alternative is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (recommended method) and this way you can still customize your ESXi host after the initial installations. I have already filed an internal documentation bug to add a note regarding Secure Boot and %firstboot, hopefully that will roll out with the net documentation refresh.