vSphere 7.0

Setup custom login banner when logging into a vSphere with Kubernetes Cluster

05/20/2020 by William Lam Leave a Comment

While working on my PowerCLI module for enabling workload management for a vSphere with Kubernetes (K8s) Cluster, I came to discover a pretty cool feature that is only available when using the vSphere with K8s API to enable Workload Management on a vSphere Cluster.

As part of the enablement spec, there is a new property called login_banner. Taking a closer look, this property allows you to specify a custom message that would be displayed as part of the initial login to your vSphere with K8s Cluster using the vSphere kubectl plugin. This is similar to an SSH login banner which can be used to provide internal disclaimers and/or additional instructions for your end users.

Here is an example of what the login banner can look like. Yup, vSphere with K8s supports emojis or rather the terminal you are using to login can potentially render emojis 😀

The good news is that I have already added this feature into the new New-WorkloadManagement function and you can specify a message by adding the -LoginBanner parameter.

For those interested in rendering emojis within their banner, you can take a look at the following example and you can find the complete list of emoji unicodes here.

$LoginBanner = "

" + [char]::ConvertFromUtf32(0x1F973) + "vSphere with Kubernetes Cluster enabled by virtuallyGhetto " + [char]::ConvertFromUtf32(0x1F973) + "

"

$LoginBanner = "

" + [char]::ConvertFromUtf32(0x1F973) + "vSphere with Kubernetes Cluster enabled by virtuallyGhetto " + [char]::ConvertFromUtf32(0x1F973) + "

Workload Management PowerCLI Module for automating vSphere with Kubernetes

05/19/2020 by William Lam Leave a Comment

One of the last things on my to-do list after creating my Automated vSphere 7 and vSphere with Kubernetes Lab Deployment Script which is still the quickest and most reliable way to have a fully deployed and configured environment to try out vSphere with Kubernetes using Nested ESXi, was to also automate the enablement of Workload Management for a given vSphere Cluster.

There are two new vCenter Server REST APIs to be aware of as it pertains to vSphere with Kubernetes:

namespaces = Manages the lifecycle and access control to a vSphere Namespace
namespace-management = Despite the name, this refers to lifecycle and management of a Workload Management Cluster

I also have to mention that Vikas Shitole, who works on vCenter Server, has fantastic blog series covering various parts of the new vSphere with Kubernetes API along with Python examples if you want to dive further. Since Vikas has done a great job covering Python, I figure I will demonstrate how to consume these new vSphere with Kubernetes API using PowerCLI, which many of our customers use to automate.

I have created a new WorkloadManagement.psm1 PowerCLI module which includes following functions:

Get-WorkloadManagement
New-WorkloadManagement
Remove-WorkloadManagement

Below are the two steps required to get started with the Workload Management PowerCLI Module.

Step 1 - Download and import the WorkloadManagement PowerCLI Module by running the following command:

Import-Module ./VMware.WorkloadManagement.psm1

Step 2 - A connection to the vCenter REST API endpoint using the Connect-CisServer cmdlet is required for enabling and disabling Workload Management Cluster

Connect-CisServer -Server pacific-vcsa-2.cpbu.corp -User *protected email* -Password VMware1!

A connection to vCenter Server using Connect-VIServer cmdlet is only required if you wish to retrieve information about an existing Workload Management Cluster

Connect-VIServer -Server pacific-vcsa-2.cpbu.corp -User *protected email* -Password VMware1!

Guest Customization support for Instant Clone in vSphere 7

05/14/2020 by William Lam 1 Comment

vSphere Instant Clone was re-architected back in vSphere 6.7 and has been enhanced to be made more powerful and flexible. These enhancements not only power solutions like VMware Horizon but it also unlocks new customer use cases including things like Instant Cloning of Nested ESXi and Apple MacOS Guests.

Although the possibilities are truly endless with Instant Clone, this also means that any customization including basic guest identity such as hostname and networking must now use an alternative workflow. For application-level customization, it is expected that customers will create and manage these custom scripts but for basic networking configuration, it would be ideal to leverage the existing and well known vSphere Guest Customization Engine.

While downloading a file from MyVmware the other day, I came across an interesting set of packages called Guest Customization Engine for Instant Clone. Upon further investigation, I came to learn that these guest packages actually enable support for native vSphere Guest Customization for Instant Clone in vSphere 7 for the following Linux guest OSes:

CentOS 7.4 or higher
RHEL 6.8 or higher
RHEL 7.4 or higher
Ubuntu 16.04
SUSE 11SP4
SUSE 12SP3 or higher

In addition, there is also new set of vSphere (SOAP) APIs that you will need to interact with to use the new Instant Clone Guest Customization feature. The GuestCustomizationManager is a new vSphere 7.0 API which includes the following three API methods:

AbortCustomization_Task
CustomizeGuest_Task
StartGuestNetwork_Task

If you are interested in taking advantage of the new Instant Clone Guest Customization in vSphere 7, you can refer to the official VMware documentation which has step by step instructions.

Troubleshooting tips for configuring vSphere with Kubernetes

05/05/2020 by William Lam 3 Comments

With more and more folks trying out the new vSphere with Kubernetes capability, I have seen an uptick in questions both internally and externally around the initial setup of the infrastructure required for vSphere with Kubernetes but also during the configuration of a vSphere Cluster for Workload Management.

One of the most common question is why are there no vSphere Clusters listed or why a specific vSphere Cluster is showing up as Incompatible? There are a number of reasons that this can occur including vCenter Server not being able to communicate with NSX-T Manager to retrieve the list of NSX pre-checks which would cause the list to either be empty or listed as incompatible. Not having proper time sync between vCenter Server and NSX-T which can also manifest in a similar behavior among other infrastructure issues.

Having ran into some of these issues myself when developing my automation script, I figure it might be useful to share some of the troubleshooting tips I have used when trying to figure out what is going on whether that is during the initial setup or actually deploying workloads using vSphere with Kubernetes.

Quick Tip – Suppress new core dump warning in ESXi 7.0

05/04/2020 by William Lam 1 Comment

You may have noticed new warning message after installing ESXi 7.0, this can happen if your ESXi installation is on a smaller local disk (Nested ESXi Appliance would also be affected) which does not have enough capacity for setting up a core dump target or if ESXi is booting from USB which also does not support core dumps by default.

No coredump target has been configured. Host core dumps cannot be saved.

It is certainly recommended that you have a core dump target configured, especially for Production systems. However, if you wish to suppress the warning, there is an ESXi Advance Setting which you can toggle called UserVars.SuppressCoredumpWarning (can be configure using Embedded ESXi Host Client or vSphere UI in vCenter Server) as well as ESXCLI. Below is the command to suppress the warning:

esxcli system settings advanced set -o /UserVars/SuppressCoredumpWarning -i 1

Changing the default size of the ESX-OSData volume in ESXi 7.0

05/02/2020 by William Lam 7 Comments

In ESXi 7.0, a new partition scheme was introduced which also brings along a new set of storage requirements. These changes are explained in the official documentation here and the following VMware KB 77009 also contains some additional info which can be helpful. Storage changes are not easy but this was necessary to not only better support some of the current capabilities but more importantly, it setups the foundation for future ESXi capabilities.

The biggest change to the partition layout is the consolidation of VMware Tools Locker, Core Dump and Scratch partitions into a new ESX-OSData volume (based on VMFS-L). This new volume can vary in size (up to 138GB) depending on a number of factors including the current ESXi boot media (USB SD-Card, Local Disk) but also the size of the device itself, which is explained in the official documentation.

From some of the comments on Twitter, Reddit and the direct inquiries that I have received, this new behavior seems to be most impactful to smaller homelabs where a fresh install of ESXi 7.0 has been performed. Folks have shared that their ESX-OSData volume has taken up 120GB which can be quite significant if you have a smaller disk which can be quite common. I normally install ESXi on a USB device and I also use vSAN, which has a different behavior and I have also not upgraded my physical ESXi host (E200-8D) to 7.0 yet.

I performed a fresh installation of ESXi 7.0 (running as Nested ESXi VM) that was configured with 1TB of storage and here is what the filesystem layout now looks:

We can see that the ESX-OSData volume takes up ~119.75GB, which is not too bad for 1TB volume but I can understand this may not be ideal if you have something smaller such as 250GB to 512GB disk. Due to the size of the local device, the boot options mentioned in the KB would not be helpful and I was curious myself if this ESX-OSData volume size could be configurable. In doing some research it looks like the size of the ESX-OSData can be specified using the following ESXi boot option (SHIFT+O during the initial boot) called autoPartitionOSDataSize

Disclaimer: This may not be officially supported by VMware as it deviates from the system defaults and can have other unintended behaviors. Use at your own risk.