vSphere

ESXi on 11th Gen Intel NUC (Panther Canyon) & (Tiger Canyon)

01/13/2021 by William Lam 17 Comments

The highly anticipated 11th Generation Intel NUCs based on the new Tiger Lake processors has just been announced by Intel and I am excited to share my first hand experience with this new NUC platform. There are currently two models in the new 11th Gen lineup: the Intel NUC 11 Performance codenamed Panther Canyon (pictured on the left) which is the successor to the 10th Gen (Frost Canyon) NUC and the Intel NUC 11 Pro codenamed Tiger Canyon (pictured on the right) which is the successor to the 8th Gen (Provo Canyon) NUC.

There are a number of new improvements and capabilities that will make these new NUCs quite popular for anyone looking to build or upgrade their vSphere environment in 2021.

Before diving right in, I must say I love the new aesthetic look of the NUC chassis. In previous versions, the lid had a glossy and shiny finish, which easily left hand prints. These new models now have a clean matte finish. The NUC 11 Performance has a smoother feel compared to the NUC 11 Pro which has more of a texture to the finish, which I personally prefer. The other noticeable change is the power adapter, which is now half the size now which is nice for those looking to have several of these new kits sitting next to each other.

Which VM was this vSphere VM cloned from?

01/11/2021 by William Lam Leave a Comment

This was a question that I saw back in December on the VMware {code} Slack which was quickly answered by the always awesome Luc Dekens. The solution is to look at vCenter Server Events, which are super rich in information and can be used for a number of things including identifying the source VM that it was cloned from. When I was a customer, this was something I did all the time, using events for auditing purposes but also identifying who, what and when a certain operation was performed including source VMs for cloning operations.

Although this information maybe known to some, there is still not an elegant solution that can help someone quickly identify the source VM for a specific vSphere VM that was cloned. This topic also intrigued me as I have seen this question come up in the past. I figure I might as well add this to my random scripting backlog and take a look when I had some time.

Before taking a look at the solution, it is important to understand the different types of clones that exists in vSphere today and also the respective vCenter Server events that can help us correlate to both the source VM but also the specific clone type.

Cloning Types

Full Clone - An independent copy of a virtual machine that shares nothing with the parent virtual machine after the cloning operation. Ongoing operation of a full clone is entirely separate from the parent virtual machine
Linked Clone - A copy of a virtual machine that shares virtual disks with the parent virtual machine in an ongoing manner. This conserves disk space, and allows multiple virtual machines to use the same software installation
Instant Clone - An independent copy of a virtual machine that starts executing from the exact running state of the source powered on virtual machine. Instant Clone uses rapid in-memory cloning of a running parent virtual machine and copy-on-write, simliar to that of Linked Cloning to rapidly deploy virtual machines

Record and Replay vSphere Inventory using govc and vcsim

01/04/2021 by William Lam 2 Comments

Happy New Year! 🥳

I wanted kick off 2021 with something I had just learned about right at the end of 2020 which I think this will be useful going into the new year for a number of different use cases. Back in 2017, I wrote about a new and lighter weight version of the vCenter Simulator (vcsim) which had been developed as part of the govmomi (vSphere SDK for Go) project. Since then, the govmomi project has grown exponentially and is now integral to a number of popular open source projects such as Packer builder for vSphere, Terraform provider for vSphere and Kubernetes Cluster API for vSphere (CAPV) to just name a few.

Govmomi is also heavily used internally by VMware for both development and testing purposes. In fact, it has been used to build a number of new VMware features such as the vSphere Integrated Containers (VIC) solution and most recently the vSphere with Tanzu capability that was introduced in vSphere 7.0.

Getting back to vcsim, this has been an invaluable tool for both our VMware developers but also the general VMware community. The ability to "simulate" a mocked vSphere environment with a basic inventory can be extremely useful for learning about the vSphere API and interacting with this endpoint using any vSphere SDK including PowerCLI. For automation folks, this can be useful for designing and creating your scripts in an offline mode before testing it against a real environment. For folks building 3rd party solutions that includes a visual interface, this is an easy way to test out your UI and ensure that there are no issues for large vSphere inventories which can be difficult to validate in a development environment.

Simulating a fake vSphere inventory is great, but it also has its limitations. There are so many unrealized use cases if you could capture a real vSphere inventory and then replay that back using vcsim. Just think about a bug reproduction use case and being able to share a real vSphere inventory with a development or QA team without needing to provide them direct access to the production environment?

In my opinion, this was the missing key feature from the original vcsim. To my surprise, this functionality was actually added to govc/vcsim earlier last year and I was quite happy with its implementation! Let's now take a closer look at how the record and replay functionality of govc/vcsim works.

Adobe Flash is going away, is your VMware environment and IT Organization ready for it?

10/29/2020 by William Lam 9 Comments

Hopefully this news should not come as a surprise to anyone but at the end of this year (December 31, 2020), Adobe and all mainstream web browsers will remove Flash functionality preventing users from interacting with any Flash-based web applications. This will also impact usage of VMware products that still uses Flash such as older versions of vSphere with the vSphere Flash Web Client or vCloud Director with their Flash-based Tenant UI as an example.

The large majority of VMware customers have already migrated off to newer versions of VMware products that no longer rely on Flash and this announcement will be a no-op for them. However, the reality is that not every customer has been able to meet this deadline for one reason or another will still have VMware products running in their Production environment that uses Flash even after the official end of life.

For these customers, it is really important to understand what are some of the implications and considerations to be aware of leading up to end of the year.

Using ESXi-Arm Fling as a lightweight vSphere Automation environment for PowerCLI and Terraform

10/09/2020 by William Lam 1 Comment

A set of use cases that I was really excited for when I first heard about ESXi-Arm a few years ago was around the topic of vSphere Automation and Development. I speak with many customers who are just starting out on their Automation journey whether that is using PowerCLI, one of our many vSphere Automation SDK or even directly to the new vCenter REST API which all new features are being exposed through these days.

One of the biggest challenge for new comers is simply getting access to hardware that they can start playing around with and although there are is plethora of vSphere Homelab choices, it does require some amount of investment, which is definitely worth it in the long run. However, if you are just getting started and maybe you want something that is a bit more lighter weight, there are not too many options outside of an Intel NUC. I know many consultants actually carry around an Intel NUC that contains several VM images that they use to with their clients, including demos.

With the small form factor, low cost and reduced power consumption of the Raspberry Pi, I think this really opens up the door for some interesting creative solutions:

Basic vSphere footprint that can be used for work or learning purposes
Easy way to learn and explore the vSphere API with an actual host and enabling real VM deployments
Trying out Infrastructure-as-Code (IaC) tools such as Terraform and Ansible
Quick way to run through basic demos in front of customers
On-demand and self-contained lab environment for small Hackathon at your local VMUG or even at VMworld

Something I was really interested in early on was to be able to use ESXi-Arm with the Raspberry Pi to not only have a basic ESXi environment but also have PowerCLI environment up and running in an Arm VM. My first thought was to get this setup using Photon OS, which not only has Arm distribution but also has support for Powershell and PowerCLI. I was hoping with some tinkering, I could easily get Powershell for Arm to run on PhotonOS (which it did) but I then ran into issues installing PowerCLI itself.

I decided to give up for now and take a look at Ubuntu which also supports Powershell for Arm, but the Microsoft documentation only listed instructions for 32-bit and ESXi-Arm requires a 64-bit. Taking a look at the Powershell release files, I noticed there was 64-bit package and with a few minor adjustments to the commands, I got PowerCLI installed and connected back to my rPI which was attached to my x86 vCenter Server!

vSAN Witness using Raspberry Pi 4 & ESXi-Arm Fling

10/08/2020 by William Lam 29 Comments

As hinted in my earlier blog post, you can indeed setup a vSAN Witness using the ESXi-Arm Fling running on a Raspberry Pi (rPI) 4b (8GB) model. In fact, you can even setup a standard 2-Node or 3-Node vSAN Cluster using the exact same technique. For those familiar with vSAN and the vSAN Witness, we will need to have at least two storage devices for the caching and capacity tier.

For the rPI, this means we are limited to using USB storage devices and luckily, vSAN can actually claim and consume USB storage devices. For a basic homelab, this is probably okay but if you want something a bit more reliable, you can look into using a USB 3.0 to M.2 NVMe chassis. The ability to use an M.2 NVMe device should definitely provide more resiliency compared to a typical USB stick you might have lying around. From a capacity point of view, I had two 32GB USB keys that I ended up using which should be plenty for a small setup but you can always look at purchasing large capacity given how cheap USB devices are.

Disclaimer: ESXi-Arm is a VMware Fling which means it is not a product and therefore it is not officially supported. Please do not use it in Production.

With the disclaimer out of the way, I think this is a fantastic use case for an inexpensive vSAN Witness which could be running at a ROBO/Edge location or simply supporting your homelab. The possibilities are certainly endless and I think this is where the ESXi-Arm team would love to hear whether this is something customers would even be interested in and please share your feedback to help with priorities for both the ESXi-Arm and vSAN team.

In my setup, I have two Intel NUC 9th Pro which make up my 2-Node vSAN Cluster and then an rPI as my vSAN Witness. Detailed instructions can be found below including a video for those wanting to see vSAN Witness in action by actually powering on an actual workload 😀