WilliamLam.com

Guest Customization support for Instant Clone in vSphere 7

by // 2 Comments

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

by // 10 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.

[Read more...]

Deploying a minimal vSphere with Kubernetes environment

by // 9 Comments

A very useful property of automation is the ability to experiment. After creating my vSphere 7 with Kubernetes Automation Lab Deployment Script, I wanted to see what was the minimal footprint in terms of the physical resources but also the underlying components that would be required to allow me to still a fully functional vSphere with Kubernetes environment.

Before diving in, let me give you the usual disclaimer 😉

Disclaimer: This is not officially supported by VMware and you can potentially run into issues if you deviate from the official requirements which the default deployment script adheres to out of the box.

In terms of the physical resources, you will need a system that can provision up to 8 vCPU (this can be further reduced, see Additional Resource Reduction section below), 92GB memory and 1TB of storage (thin provisioned).


which translates to following configuration within the script:

  • 1 x Nested ESXi VM with 4 vCPU and 36GB memory
  • 1 x VCSA with 2 vCPU and 12GB memory
  • 1 x NSX-T Unified Appliance with 4 vCPU and 12GB memory
  • 1 x NSX-T Edge with 8 vCPU and 12GB memory

Note: You can probably reduce memory footprint of the ESXi VM further depending on your usage and the VCSA is using the default values for "Tiny", so you can probably trim the memory down a bit more.

Another benefit to this solution is by reducing the number of ESXi VMs required, it also speeds up the deployment and in just 35 minutes, you can have the complete infrastructure fully stood up and configured to try out vSphere with Kubernetes!


The other trick that I leveraged to reduce the amount of resources is by changing the default number of Supervisor Control Plane VMs required for enabling vSphere with Kubernetes. By default, three of these VMs are deployed as part of setting up the Supervisor Cluster, however I found a way to tell the Workload Control Plane (WCP) to only deploy two 🙂


This minimal deployment of vSphere with Kubernetes has already been incorporated into my vSphere with Kubernetes deployment script, but it does require altering several specific settings. You can find the instructions below.

[Read more...]