VMware has launched a training portal that allows you to improve your skills and knowledge of Tanzu and Kubernetes. On the portal ModernAppsNinja there are many free trainings that will bring you closer to the ModernApps topic. You will find a variety of courses, labs, tutorials, learning materials and handson tutorials. For example, if you want to prepare for the Certified Kubernetes Administrator (CKA), or the VCP ModernApps, you can easily find the necessary resources and tools there. But also useful tutorials such as how to use VSCode.
With vSphere7 fundamental changes in the structure of the ESXi boot medium were introduced. A fixed partition structure had to give way to a more flexible partitioning. More about this later.
With vSphere 7 Update 3 VMware also brought bad news for those using USB or SDCard flash media as boot devices. Increasing read and write activity led to rapid aging and failure of these types of media, as they were never designed to handle such a heavy load profile. VMware put these media on the red list and the vSphere Client throws warning messages in case such a media is still in use. We will explore how to replace USB or SDCard boot media.
ESXi Boot Medium: Past and Present
In the past, up to version 6.x, the boot medium was rather static. Once the boot process was complete, the medium was no longer important. At most, there was an occasional read request from a VM to the VM Tools directory. Even a medium that broke during operation did not affect the ESXi host. Only a reboot caused problems. For example, it was still possible to backup the current ESXi configuration even if the boot medium was damaged.
Layout of an ESXi Boot media before version 7
Layout of the boot media up to ESXi 6.7
In principle, the structure was nearly always the same: A boot loader of 4 MB size (FAT16), followed by two boot banks of 250 MB each. These contain the compressed kernel modules, which are unpacked and loaded into RAM at system boot. A second boot bank allows a rollback in case of a failed update. This is followed by a “Diagnostic Partition” of 110 MB for small coredumps in case of a PSOD. The Locker or Store partition contains e.g. ISO images with VM tools for all supported guest OS. From here VM tools are mounted into the guest VM. A common source of errors during the tools installation was a damaged or lost locker directory.
The subsequent partitions differ depending on the size and type of the boot media. The second diagnostic partition of 2.5 GB was only created if the boot medium is at least 3.4 GB (4MB + 250MB + 250MB + 110MB + 286MB = 900MB). Together with the 2.5 GB of the second diagnostic partition, this requires 3.4 GB.
A 4 GB scratch partition was created only on media with at least 8.5 GB. It contains information for VMware support. Anything above that was provisioned as VMFS data store. However, scratch and VMFS partition were created only if the media was not USB flash or SDCard storage. In this case, the scratch partition was created in the host’s RAM. With the consequence that in the event of a host crash, all information valuable for support was lost as well.
Structure of the boot media from ESXi 7 onwards
The layout outlined above made it difficult to use large modules or third-party modules. Hence, the design of the boot medium had to be changed fundamentally.
Changes of the partition layout between version 6.x and 7.x
First, the boot partition was increased from 4 MB to 100 MB. The two boot banks were also increased to at least 500 MB. The size is flexible, depending on the total size of the medium. The two diagnostic partitions (Small Core Dump and Large Core Dump), as well as Locker and Scratch have been merged into a common ESX-OSData partition with flexible size between 2.9 GB and 128 GB. Remaining space can be optionally provisioned as VMFS-6 datastore.
There are four different boot media size classes in vSphere 7:
4 GB – 10 GB
10 GB – 32 GB
32 GB – 128 GB
> 128 GB
Dynamic partitioning in vSphere 7 depending on media capacity.
The partition sizes shown above are for freshly installed boot media on ESXi 7.0, but what about boot media migrated from version 6.7?
Backing up and restoring an ESXi host configuration is a standard procedure that can be used when performing maintenance on the host. Not only host name, IP address and passwords are backed up, but also NIC and vSwitch configuration, Object ID and many other properties. Even after a complete reinstallation of a host, it can recover all the properties of the original installation.
Recently I wanted to reformat the bootdisk of a host in my homelab and had to fresh install ESXi for this. The reboot with the clean installation worked fine and the host got a new IP via DHCP.
Now the original configuration was to be restored via PowerCLI. To do this, first put the host into maintenance mode.
The command prompts for a root login and then automatically reboots. At the end of the boot process, an empty DCUI was welcoming me.
I haven’t seen this before. I was able to log in (with the original password), but all network connections were gone. The management network configuration was also not available for selection (grayed out). The host was both blind and deaf.
One of the new features of vSphere 7.0 Update 3 is that you can now manage NSX-T directly from the vSphere Client. In the new menu of the vSphere client UI, you will now find a section dedicated to NSX.
Opening this section currently brings up an NSX-T status information page. At this current stage, we are able to deploy new NSX-T instances, but existing NSX-T installations won’t be discovered.
Why is that?
As usual, a look at the Release Notes helps. There you’ll find the following statement for vCenter 7 Update 3:
You can see the vSphere Client NSX-T home page that enables the feature, but it does not work with NSX-T Data Center 3.1.x or earlier.
The most recent NSX-T version is 3.1.3 [as of 11/15/2021]. This means we have to wait for NSX-T version 3.2 until the integration works.
