WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

Introduction to the new ESXi Configuration Store CLI (configstorecli)

07.19.2021 by William Lam // 10 Comments

I was looking into a customer inquiry this morning and found myself looking at the configstorecli, which is an ESXi Shell CLI that enables access to the new ESXi Configuration Store (ConfigStore). The goal of the ConfigStore, initially introduced in ESXi 7.0 Update 1, is to centrally manage all configurations for an ESXi host instead of relying on different methods including a variety of configuration files. There is actually not much documentation out there for configstorecli, other than this blog post by Duncan and these two VMware KBs (here and here).

While searching online, I ended up clicking Duncan's blog as I figured it probably has the best information and I do recall this topic awhile back on the change in behavior for renaming a standard virtual switch. I started to play with the configstore CLI and what was not immediately clear was how to actually use it, especially identifying some of the parameters it was looking for. I figured I might as well share some of my findings as I explore configstorecli a bit more.

My first observation is that the Config Store is a JSON document store and each configuration is stored as individual JSON documents. Before you can access a specific configuration, you first need to understand the schema. To view the entire schema, run the following command:

configstorecli schema list

Since the output is JSON, you can actually save the contents to a file on your desktop and use any JSON supported tool such as jq to explore further. In the example below, I have loaded an online copy of the configstorecli output from ESXi 7.0 Update 2 using my Chrome browser, which has this JSON Viewer extension installed. The benefit with a visual tool, is that you can easily expand or collapse specific nodes within the JSON document.

[Read more...]

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // Automation, ESXi, vSphere 7.0 Tags // configstorecli, ESXi 7.0 Update 2

Simplified Nested ESXi installation in ESXi 7.0 Update 2 using HTTP Boot over VirtualEFI

03.22.2021 by William Lam // 19 Comments

Deploying an ESXi scripted installation aka Kickstart running within a VM (Nested ESXi) has a number of benefits, especially for testing and development purposes. This was something I did regularly as a customer, especially with new releases of ESXi to ensure our existing automation scripts and processes continued to work before rolling out into production. ESXi kickstart itself is pretty straight forward, but the required supporting infrastructure (PXE Server, DHCP, TFTP, etc) that needs to be configured, especially for a greenfield deployment can often be challenging for new comers.

Even with an existing PXE infrastructure, it can often be difficult to configure or troubleshoot depending on your level of access which does not add any value in actually testing or automating the ESXi scripted installation process. In ESXi 7.0 Update 2, an enhancement was made to the Virtual Machine's UEFI firmware called VirtualEFI that would enable ESXi to perform an HTTP Boot given the ESXi bootloader URL and without requiring any of the traditional PXE infrastructure.

To take advantage of this new capability, you just need to have a physical server running ESXi 7.0 Update 2 and a VM that is configured with the latest vHW19 compatibility. To configure HTTP boot, you will need to add the following two VM Advanced Settings:

  • networkBootProtocol - httpv4 or httpv6
  • networkBootUri - HTTP URL to the ESXi bootloader (bootx64.efi)

Disclaimer: Nested ESXi and Nested Virtualization is not officially supported by VMware

[Read more...]

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // Automation, ESXi, Nested Virtualization, vSphere 7.0 Tags // efi, ESXi 7.0 Update 2, Nested ESXi, nested virtualization, UEFI, vSphere 7.0 Update 2

ESXi 7.0 Update 2 enhancement for USB NIC only installations

03.16.2021 by William Lam // 9 Comments

The USB Network Native Driver for ESXi Fling has been an extremely popular Fling that has allowed customers to easily add additional networking capabilities by using a supported USB-based network adapter even though ESXi traffic over USB networking is not officially supported.

In most deployments, the USB network adapter is usually a supplement to the existing onboard network adapter of a system. However, there have been scenarios where the onboard network adapter is either not available or functional and customers would still like to be able to install ESXi and have it running over just the USB network adapter.

Although installing ESXi using just a USB network adapter is possible today, one downside is that an additional workflow is needed to fix the network binding after installing ESXi.

During the interactive ESXi installation, you will see the following error at 81% which will cause installer to get stuck

Exception: No vmknic tagged for management was found.

At this point, the installer has completed and you need to switch to the console (Alt+F1) and perform a reboot. Once ESXi reboots, you will need to go into the DCUI and manually bind the vusb0 interface for ESXi management for connectivity. To persist this USB NIC binding, you will need to add small snippet of code as outlined here.


Obviously, this was not an ideal user experience and I personally had to use this workaround on several occasions, especially for newer hardware platforms where the onboard network adapter may not be recognized by ESXi and being able to use the USB Network Fling definitely came in handy.

With the release of ESXi 7.0 Update 2, we have improved the user experience for installing ESXi with just a single USB NIC. This enhancement was added by Songtao after mentioning the undesirable behavior. A new ESXi kernel boot option called usbBusFullScanOnBootEnabled can be added which removes the need for the workaround mentioned above. This new kernel option forces a full bus scan to claim all USB NICs that are attached since USB device claiming is slow compared to PCIe devices.

[Read more...]

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // ESXi, Home Lab, vSphere 7.0 Tags // ESXi 7.0 Update 2, vSphere 7.0 Update 2

  • 1
  • 2
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Support

Recent

  • A first look at the new vSphere+ & vSAN+ Cloud Service 07/01/2022
  • Quick Tip - Prepare VMware Photon OS for use with vSphere Guest OS Customization and cloud-init 06/29/2022
  • Using the new vSphere Guest OS Customization with cloud-init in vSphere 7.0 Update 3 06/27/2022
  • How to forcefully disconnect a vSphere VM Console session? 06/24/2022
  • Quick Tip - Using ESXi Scripted Installation (kickstart) to configure IPv6 networking 06/21/2022

Advertisment

Copyright WilliamLam.com © 2022

 

Loading Comments...