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
[Read more...] about All vSphere 6.7 Update 1 release notes & download links
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:
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.
[Read more...] about VSAN Managed Object Browser (MOB) in vSphere 6.7 & vSphere 6.7 Update 1
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.
[Read more...] about Automatically retrieve CVE CVSS score for all ESXi security bulletins
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.
A really cool new capability that was introduced in vSphere 6.7 is the support for the extremely fast memory technology known as non-volatile memory (NVM), also known as persistent memory (PMem). Customers can now benefit from the high data transfer rate of volatile memory with the persistence and resiliency of traditional storage. As of this blog post, both Dell and HP have Persistent Memory support and you can see the list of supported devices and systems here and here.
PMem can be consumed in one of two methods:
Customers who may want to familiarize themselves with these new PMem workflows, especially for Automation or educational purposes, could definitely benefit from the ability to simulate PMem in their vSphere environment prior to obtaining a physical PMem device. Fortunately, this is something you can actually do if you have some additional spare memory from your physical ESXi host.
Disclaimer: This is not officially supported by VMware. Unlike a real physical PMem device where your data will be persisted upon a reboot, the simulated method will NOT persist your data. Please use this at your own risk and do not place important or critical VMs using this method.