vSphere 6.7

Instant Clone Microsoft Windows & VM Keystroke VMworld demo and code posted

01/08/2019 by William Lam 1 Comment

Apologies for the delay in getting my VMworld 2018 demo and code posted online, I know a number of you have been asking about the Windows Instant Clone samples to get an idea on how to create your own customization scripts for managing more "recent" Microsoft Windows releases 😉 and perhaps you might even consider submitting a pull request to share with the community. I have posted both the videos and code samples below. Enjoy and happy Automating!

Instant Clone Microsoft Windows

To demonstrate the power of the newly re-architected Instant Clone feature in vSphere 6.7 and to help make the point clear that the Instant Clone feature is really Guest Operating System agnostic, meaning you can Instant Clone any to Virtual Machine that can run VMware Tools, I thought it would be fun to see how old of a Microsoft OS that I could Instant Clone. After a bit of trial/error, that turned out to be Windows 98 and Windows 2000 🙂

Windows 98 Demo

Windows 2000 Demo

All vSphere 6.7 Update 1 release notes & download links

10/16/2018 by William Lam 10 Comments

The highly anticipated vSphere 6.7 Update has officially GA'ed! Below is an aggregation of all the related release notes and downloads for this vSphere release. I have also created a short URL which you can use to access this exact same page using vmwa.re/vsphere67u1

The downloads are currently being staged, so please be patient.

vCenter Server 6.7u1

ESXi 6.7u1

vSAN 6.7u1

Enhancements to Hybrid Linked Mode (HLM) in VMC using the new vCenter Cloud Gateway

10/04/2018 by William Lam Leave a Comment

It has been almost a year since VMware introduced the Hybrid Linked Mode (HLM) capability, which provides customers with a consistent operating experience for managing and consuming resources from both their on-premises and VMware Cloud on AWS (VMC) environments. Feedback from customers on HLM has been fantastic, especially when new or prospective VMC customers learn about HLM for the very first time. Customers were pleasantly surprised at how seamless the experience was when consuming VMC resources, using a familiar interface, the vSphere UI.

Here is a quick recap of what HLM provides today:

HLM allows customers to link a single VMC instance to a single on-prem SSO Domain which can contain one or more vCenter Servers (Enhanced Linked Mode) while maintaining separate administrative domains (e.g. on-prem user is Administrator while VMC user is CloudAdmin only)
SSO Domains will be different between on-prem and VMC, however it is a 1:1 relationship
A trust is established where the on-prem vCenter Server trusts the incoming connections from VMC as they share the same Active Directory identity source. Data is sync'ed uni-directionally from on-prem to VMC
Can be configured at any point in the on-prem vCenter Server lifecycle, no restrictions to initial install and can easily be un-linked unlike ELM
Both Embedded & External vCenter Server deployments are supported
HLM supports different versions of vCenter Server between on-prem (6.5d+) and VMC, especially as VMC will almost always run a newer version of vSphere
Users MUST login to VMC vCenter Server for single-pane of glass management (H5 Client supported only), logging into on-prem vCenter Server will NOT show VMC vCenter Server
Roles are NOT replicated due to the restrictive access model in VMC

VSAN Managed Object Browser (MOB) in vSphere 6.7 & vSphere 6.7 Update 1

09/10/2018 by William Lam 1 Comment

If you have ever spent any time using the vSphere API, you probably have heard of or have used the vSphere Managed Objected Browser (MOB) which is an extremely useful learning and debugging tool when working with the vSphere API. The vSphere MOB is accessed through a web browser connecting to either vCenter Server or ESXi and provides a graphical interface, allowing you to discovery/explore the underlying vSphere API and its data in a very intuitive manner.

As an avid user of the VSAN Management API since its release, I have always wanted something similar, especially when I first got started. I was quite happy when I found out in vSphere 6.7 and VSAN 6.7, the VSAN team has added a VSAN MOB interface directly on ESXi, for the VSAN specific APIs that are available only on an ESXi host. Just like the vSphere MOB which is also available on ESXi host, it is disabled by default and must be enabled.

The following ESXCLI commands can be used to enable/disable the VSAN MOB on ESXi 6.7:

esxcli vsan debug mob start
esxcli vsan debug mob stop

However, when I tried to enable the VSAN MOB, I ran into the following error message:

hostname 'localhost.localdomain' doesn't match '192.168.30.10'

It turns out there is an issue where it fails to match the IP Address of the ESXi host to the default localhost.localdomain and hence it fails to start the VSAN MOB. This issue is fixed in the upcoming vSphere & VSAN 6.7 Update 1, but in the mean time, there is a workaround.

Automatically retrieve CVE CVSS score for all ESXi security bulletins

07/20/2018 by William Lam 9 Comments

I always enjoying learning new things, especially when it is outside of my immediate domain expertise and if I can thrown in some Automation to help solve a solution, it is a win for everyone. I bring this up because, yesterday I had noticed an interesting question from one of our field folks where their customer is looking to implement a process for applying ESXi security patches to help determine compliance timeline (e.g. when a specific security update will be applied to infrastructure).

To do this, the customer would like to use the Common Vulnerability Scoring System (CVSS) score which ranges from 0-10, 0 being low and 10 being high. The CVSS score is part of the Common Vulnerabilities and Exposures (CVE) which is also referenced for every ESXi security patch (bulletin) that is published by VMware. The question that came up was how easily it would be to determine the CVSS score for a given ESXi security patch. First, I will outline the "manual" process and once that is understood, I will demonstrate an automated solution which customers can take advantage of to easily retrieve this information for all ESXi security patches.

Using ESXi Kickstart %firstboot with Secure Boot

06/26/2018 by William Lam 5 Comments

If you install ESXi via a Kickstart script and make use of the %firstboot option to execute commands on the first boot of the ESXi host after installation, you should be aware of its incompatibility with the Secure Boot feature. If you install ESXi where Secure Boot is enabled, the Kickstart will install ESXi normally only execute up to the %post section. However, it will not execute the %firstboot scripts and if you look at the /var/log/kickstart.log after the host boots, you should see the following message:

INFO UEFI Secure Boot Enabled, skipping execution of /var/lib/vmware/firstboot/001.firstboot_001

If you have Secure Boot enabled, %firstboot is not supported. The reason for this is Secure Boot mandates only known tardisks which can hold executable scripts, and a kickstart script is an unknown source so it can not run when Secure Boot is enabled. If you wish to continue using %firstboot scripts, the only option is to disable Secure Boot and then re-enable it after the installation. A preferred alternative is to convert your %firstboot logic into an external script which can then be applied using the vSphere API (recommended method) and this way you can still customize your ESXi host after the initial installations. I have already filed an internal documentation bug to add a note regarding Secure Boot and %firstboot, hopefully that will roll out with the net documentation refresh.