WilliamLam.com

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

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

UPDATE (08/23/21) - For those interested in purchasing the Intel NUC 11 Expansion Module, GoRite is a vendor who is now selling this accessory that I was recently made aware of.

UPDATE (02/17/21) - The Community Networking Driver for ESXi Fling has been released and is required for ESXi to recognize the new onboard 2.5GbE network adapter on all Intel NUC 11 models

[Read more...]

Which VM was this vSphere VM cloned from?

by // 4 Comments

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

[Read more...]

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.2.1

by // 6 Comments

Check out the newest release of the Tanzu Kubernetes Grid (TKG) Demo Appliance Fling which includes the following new features:

  • Support for the latest TKG 1.2.1 release
  • Support for TKG Workload Cluster upgrade workflow from Kubernetes v1.18.10 to v1.19.3
  • Updated embedded Harbor to use self-sign TLS certificate

One of the biggest feature I was excited for in the new TKG 1.2.1 release was support for an external container registry that was configured with a self-signed TLS certificate. Previously, TKG only supported container registries that were configured with a trusted CA signed certificate and that made it difficult for proof of concept/testing but also for environments that were air-gapped.

With previous releases of the TKG Demo Appliance, a valid TLS certificate was acquired from Let's Encrypt (LE) with the help of my good friend Ryan Johnson who owns the domain rainpole.io. The one downside to LE-based certificates is the short expiry period, which is every 90 days. This meant that any TKG Demo Appliance deployed after the expiry would stop functioning due to the certificate no longer being valid. Although I have been able to manage this by updating the appliance roughly every 90 days, usually in-conjunction with new release of TKG, it was less than ideal.

[Read more...]