William Lam

ESXi-Arm Licensing Options

12/12/2020 by William Lam Leave a Comment

The the adoption of the ESXi-Arm Fling has skyrocketed since its initial launch back in October and has already surpassed over 10K+ downloads in its first month of release!

Just got an update from the @vmwflings team that the #ESXionARM Fling has already surpassed 10K+ downloads since its release! 🤯

Thank you to everyone in the community who’s participated, especially those who’ve shared their feedback & those doing some really stuff with it!

— William Lam (@lamw) November 18, 2020

One interesting observation that I have noticed lately has been an increased in inquiries related to licensing ESXi-Arm. This week alone, I have seen this question come up at least a dozen plus times across various communication channels.

VMware Cloud on AWS 1.13 adds support for VMRC vCenter Proxy

12/09/2020 by William Lam Leave a Comment

VMware Cloud on AWS (VMConAWS) 1.13 was just released and although it is an optional release, it does introduce a pretty interesting capability that I think our customers will really appreciate and benefit from, especially when this capability also makes its way into an on-premises vSphere release.

VMware Remote Console (VMRC) vCenter Proxy

VMware Remote Console connections will now be proxied through the SDDC’s vCenter, and clients no longer require connectivity to ESXi hosts. This simplifies connectivity requirements, and allows for the use of VMRC over VPN when a DX or vTGW is also being used with the SDDC.

Historically, when you wanted to interact with a Virtual Machine using the vSphere UI in vCenter Server, you had two options. You can either use the HTML5 Remote Console within your browser or you could use the standalone VMware Remote Console (VMRC) application. For basic functionality, the HTML5 console is generally preferred but for cases where you might need to mount a local device from your computer such as a USB, bluetooth or CD-ROM device, you had to use the VMRC client.

Intel NUC with 512GB memory

12/03/2020 by William Lam 7 Comments

Yes, you read that correctly. 512 gigabytes of memory on an Intel NUC. Not only is this pretty 🤯 but this is actually possible today with an already released Intel NUC!

A few months back, I was made aware of some really cool technology from Intel called Intel Memory Drive Technology (IMDT) which leverages Intel Optane SSDs to extend memory of a system beyond its physical memory (DRAM) capacity. This technology is made possible with their IMDT software, which is a purpose built Hypervisor whose sole purpose is to just manage memory and this Hypervisor runs on top of the Intel Optane SSD. You can think of this like a Software-Defined Memory (SDM) solution. In fact, SDM was actually coined in this performance white paper evaluating IMDT with scientific-based applications back in 2018.

Note: This should not be confused with Intel Optane and its Datacenter Persistent Memory (PMEM) solution which vSphere already supports today.

The target use case for this type of technology is for memory intensive applications such as SAP HANA, Oracle, Redis, Memcache and Apache Spark to just name a few. These workloads can easily gobble up 10's of terabytes of memory that can bring a number of challenges when needing to scale up these solutions. High capacity memory DIMMS are not only expensive, but once you exhaust the number of physical DIMM slots, your only option for scale up is to add additional servers which is very costly.

Using IMDT, customers can expand their physical DRAM capacity from 8x to 15x, which can significantly improve cost, performance but also the operational overhead in managing additional systems. Putting aside the in-memory based workloads, I think there is also huge potential for general purpose workloads that can also get the exact same benefits, especially when you think about constraints like power, cooling and location such as Edge or ROBO locations. Since this solution works on an Intel NUC, a really interesting use case for this technology that immediately came to mind was for a vSphere/NSX/vSAN homelab environment.

Programmatically interact with the VMware Product Lifecycle Matrix

12/01/2020 by William Lam 1 Comment

I recently came across a really cool automation solution from Dale Coghlan who built a PowerShell module to interact with the VMware Configuration Maximum (Config Max) Tool.

So, I published a thing today.... VMware.CfgMax - A PowerShell module to interact with https://t.co/NBrbCO3hcf https://t.co/RRQkh7ma1q

— Dale Coghlan (@DaleCoghlan) December 1, 2020

Although the Config Max tool does not currently provide an API, there is still a way to interact with it programmatically. Behind the scenes, the application uses JSON for its payload which can then be retrieved programmatically using PowerShell or any other language for that matter to perform an HTTP GET. I also know the Config Max team quite well, as I had worked with them to incorporate the VMware Cloud on AWS configuration maximums which also required a few enhancements to the tool. If you have any feedback, feel free to drop a comment and I will be happy to share it with them and one of my first asks when I met the team, was to provide a public REST API 🙂

After sharing Dale's tweet, I saw a question about doing something similiar for the VMware's Product Lifecycle Matrix, which is a website that helps customers understand the support lifecycle of a given VMware product/solution. The product lifecycle site has also been recently revamped and although it also does not have a public API, using Chrome Developer Tools (super useful tool) to quickly inspect, it looks like you can also programmatically grab the payload which also happens to be using JSON 🙂

Disclaimer: The VMware Product Lifecycle Matrix does not provide a public API, this also means there are no guarantees or compatibility that the trick outlined below will continue to work going forward. This is why you want to have a public, documented and supported API.

How to run Kali Linux on ESXi-Arm

11/30/2020 by William Lam 6 Comments

A few folks have been trying to get Kali Linux, a Debian-derived Linux distribution designed for digital forensics and penetration testing, to run on ESXi-Arm. Similiar to Raspberry Pi OS, the techniques outlined in this blog post can be used to convert the image-based system to a Virtual Machine that ESXi-Arm can then run natively. However, there is an issue when attempting to install grub during Step 16 where it can not locate an EFI partition.

With the help of Cyprien Laplace, we can now run Kali Linux on ESXi-Arm! You can find the detailed instructions below including installing VMware Tools for Kali Linux running on ESXi-Arm.

How to deploy Knative to a Tanzu Kubernetes Grid (TKG) Cluster on both vSphere with Tanzu and TKG Multi-Cloud?

11/23/2020 by William Lam Leave a Comment

This weekend I spent some time installing Knative, which is an open source framework that is built on top of Kubernetes. Knative is actually made up of two core components, serving and eventing. This quote from Ram Gopinathan, Principal Technology Architect, T-Mobile really sums up Knative quite nicely:

Knative helps our developers focus on building the business logic rather than worrying about building low-level platform capabilities such as build, deploy, autoscaling, monitoring, and observability.

There are a number of tutorials online for setting up Knative, most of which using Kubernetes in Docker (KinD) for easy local development. Since I have been spending quite a bit of time lately with both our vSphere with Tanzu and Tanzu Kubernetes Grid (TKG) Multi-Cloud solution, which both support deploying conformant and production grade Kubernetes (K8s) Clusters called a TKG Guest Cluster, I figure I might as well learn how to install Knative using these infrastructures.

The instructions below will be focus on deploying the Knative serving components. Once you have that setup, it is easy to deploy the eventing components which you can follow the official Knative documentation.