Yellow Bricks

by Duncan Epping

esxi

vSphere 8.0 U2 and vSAN 8.0 U2 just shipped, learn all about it here!

· ·

vSphere 8.0 U2 and vSAN 8.0 U2 just shipped, and of course the Unexplored Territory Podcast has already covered this. If you want to learn all about it make sure to listen to the episode below. Or of course read the release notes (vCenter, ESXi, vSAN).

You can find the vSAN 8.0 U2 episode on Spotify (https://bit.ly/3QNjpFk), and Apple (https://bit.ly/3QPt7XL), as well as any other podcast app, or simply listed via the embedded player below!

You can find the vSphere 8.0 U2 episode on Spotify (https://bit.ly/3snOh5l), Apple (https://bit.ly/45lRK2Q), as well as any other podcast app, or simply listed via the embedded player below!

Can I boot ESXi from an SD card while placing OSDATA on my SAN?

· ·

I see this question popping up all the time, literally twice a day on our VMware internal slack, can I boot ESXi from an SD card while placing OSDATA on my SAN? I guess people are confused after reading this article. It is probably a result of skim-reading as the article is in-depth and spells it out to the letter. If you look at the following table then it mentions FCoE and iSCSI:

However, FCoE, iSCSI, and FC would only be supported when you boot from SAN, only then is OSDATA supported on a SAN device. When you boot from USB/SD, OSDATA will need to reside on a locally attached device. In other words, the answer to the original question is: no you cannot boot ESXi from an SD card and place OSDATA on your SAN. Again, for details, read this excellent document.

How do I change the name of a vSwitch with vSphere 7.0 U2 and higher?

· ·

Some of you may have noticed it already, and some may not, but a lot of the configuration details that were traditionally stored in “esx.conf” have now moved elsewhere. The question is where did it go? Well it went into “configstore” and with “configstore” now also comes a commandline interface called “configstorecli”. I briefly mentioned this in a previous post a few weeks ago. Today I noticed a question on VMTN around renaming a vswitch on a host and how you can do this now that the vswitch details have disappeared from esx.conf.

I figured I should be able to test this in my lab and write a short howto. So here we go.

You can look at the current network configuration for your vSwitch using the following command:

configstorecli config current get -c esx -g network_vss -k switches

Then what you can do is dump the info in a json file, which you will then be able to edit:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

The file will look something like this:

After you made the required changes, you then load the configuration using the json file:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

I changed the name of my vSwitch0 to “vSwitchDuncan” and as you can see below, the change worked! Although do note, you will need to reboot the host before you see the change!

For those who prefer video content, I also created a quick demo which shows the above process:

Running ESXi in “Degraded Mode”, what does that mean?

· ·

I received a question today, and I didn’t have the answer so I reached out to one of the developers.  This person found this line in the ESXi documentation where it states the following, and the question was what does running ESXi in degrade mode actually means, or what is the impact?

If a local disk cannot be found, then ESXi 7.0 operates in degraded mode where certain functionality is disabled and the /scratch partition is on the RAM disk, linked to /tmp. You can reconfigure /scratch to use a separate disk or LUN. For best performance and memory optimization, do not run ESXi in degraded mode.

In other words “degrade mode” is a situation where you are running ESXi with a boot disk configuration which is undesired. In this case, the boot disk configuration (size, etc) results in the fact that /scratch is not stored on persistent media, but rather in RAM, which means that state is lost during a reboot. This could lead to various problems, hence it called degraded mode or state. Note that although you are now running in “degraded” mode, it could easily prevent you from upgrading potentially in the future.

So how do you resolve this problem? Follow the recommendations VMware provides for the ESXi configuration:

  • An 8 GB USB or SD and an additional 32 GB local disk. The ESXi boot partitions reside on the USB or SD and the ESX-OSData volume resides on the local disk.
  • A local disk with a minimum of 32 GB. The disk contains the boot partitions and ESX-OSData volume.
  • A local disk of 142 GB or larger. The disk contains the boot partitions, ESX-OSData volume, and VMFS datastore.

Although not a requirement, I would urge to read and follow the next sections from the documentation:

  • Although an 8 GB USB or SD device is sufficient for a minimal installation, you should use a larger device. The additional space is used for an expanded core dump file and the extra flash cells of a high-quality USB flash drive can prolong the life of the boot media. Use a 32 GB or larger high-quality USB flash drive.
  • If you install ESXi on M.2 or other non-USB low-end flash media, delete the VMFS datastore on the device immediately after installation.

If you want to mitigate the situation after upgrading to ESXi 7.0 you can add a new local disk and enable “autoPartition=TRUE” and reboot. At reboot, the disk will be partitioned and populated for usage. The use of this advanced setting, and others which relate to ESXi 7.0, are described in this KB article here.

For those wondering, “ESXi-OSData” is the partition where we now store the content of what was previously stored in “scratch”, “core”, and “locker”. Niels wrote a deep-dive on the vSphere blog here, go check that out.

Enabling maintenance mode via esxcli

· ·

I have been having to place my lab host into maintenance mode a few times now via the command-line, for whatever reason I just keep forgetting the command that I should use to place my host into maintenance mode using esxcli, so I figured I would dump it here so I can find it easily. Hopefully, now it sticks…

enter maintenance mode:

esxcli system maintenanceMode set --enable true

exit maintenance mode:

esxcli system maintenanceMode set --enable false