virtuallyGhetto

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.1.3

08/10/2020 by William Lam 1 Comment

It has been awhile since I have updated my Tanzu Kubernetes Grid (TKG) Demo Appliance Fling, which is a virtual appliance that enables anyone to go from zero to Kubernetes in less than 30 minutes with just an SSH client and a web browser. For VMware Cloud on AWS customers interested in running TKG, this is a great way to quickly get started on a proof of concept, demo or for development and testing purposes. One great benefit is that everything required for TKG is self contained within the appliance including an embedded Harbor registry and the respective TKG container images, great for air-gapped or non-internet accessible environments.

Here is a summary of what is new:

Support for latest TKG 1.1.3

There have been several of smaller releases to TKG since their 1.0.0 release but due to their short lifecycle, I decided to hold off. Behind the scenes, I have actually been working closely with TKG team on the latest TKG 1.1.3 release which was just release last week. One really cool feature that was introduced in TKG 1.1.2 is the ability to upgrade an existing TKG Workload Cluster to a newer version of Kubernetes.

With TKG 1.1.3, support for Kubernetes v1.18.6 and v1.17.9 is now possible and the latest version of the demo appliance will also support this workflow. In fact, I have also updated my TKG Workshop Guide to include all new updates including the upgrade workflow. To reduce the maintenance burden on myself, the TKG Demo Appliance 1.0.0 will be removed in the near future, for now it has been deprecated but all existing content is still available. I highly recommend checking out the latest version as you will get all the latest features of TKG.

Other Intel and AMD small form factor (SFF) systems for vSphere Homelabs

08/06/2020 by William Lam 26 Comments

When it comes to selecting a platform for a vSphere Homelab, there are many options which include building your own "whitebox" system. For the large majority of folks, the preference is to purchase a ready to use kit such as an Intel NUC or Supermicro which both extremely popular. These systems not only work well but their form factor is also ideal for home offices where space is always at a premium.

With that said, there are many other small form factor (SFF) platforms that exists out in the market and not just Intel-based systems, but also AMD SFF kits which are being introduced and have been getting many inquiries about. As someone who keeps a close eye on this market for new and interesting platforms, I have been re(sharing) some of these new updates on Twitter.

Although Twitter is great way to share and discuss news, it is not the best place to consolidate this type of information that can easily be searched. This was one the motivation for putting together this post for both informational awareness but also something that can be updated over time. This was certainly a challenge when asked about other SFF options, especially in the AMD space where I was not able to easily point folks to. Below is a collection of SFF for both Intel and AMD that I have come across, some of which are currently being used for vSphere Homelabs and others having the potential given their specification. In addition, I suspect many of the kits below which report 32GB of memory as their max should be able to go up 64GB as I have shown in the past with NUC platform.

If folks have other SFF kits they would like to share or confirm that works with latest versions of vSphere, feel free to leave a comment which can help others in the VMware Community.

Enhancements to the community ne1000 VIB for Intel NUC 10

08/03/2020 by William Lam 11 Comments

As many of you know, the onboard Intel NIC (8086:0d4f) found in the 10th generation of the Intel NUC (Frost Canyon) is not automatically recognized by ESXi and requires an updated ne1000 VIB which was released earlier this year. An unfortunate side affect after patching or upgrading an ESXi host which contains this modified ne1000 VIB is that it will be replaced by a newer version of the VIB and causes the NIC to no longer be recognized again.

A quick workaround is to simply re-install the modified ne1000 VIB and network connectivity will be restored which is less than ideal. A new vSphere Image Profile can also be created that contains both the patch/upgrade you intend to apply along with the modified ne1000 VIB, ensuring that you remove the newer version which may not be ideal as well. In speaking with Songtao, a VMware Engineer who I worked with on the USB Network Native Driver for ESXi, about this issue and he came up with a very simple solution. Lets choose a different name for the VIB module which removes all the complexity mentioned above. This solution would allow for both drivers to coexists and more importantly, it is persistent across patching and upgrades of ESXi.

Integrating VMware Cloud Notification Gateway with VMware Event Broker Appliance (VEBA)

07/29/2020 by William Lam Leave a Comment

I previously wrote about the VMware Cloud Notification Gateway (NGW) which provides curated notifications delivered to VMware Cloud on AWS users. By default, NGW supports several types of notification channels such as email, VMware Cloud Console UI, VMware Cloud Activity Log, vRealize Log Intelligence Cloud (vRLIC) and the vSphere UI when using the vCenter Cloud Gateway. A lesser known feature of NGW is the ability to extend into even more channels by leveraging its webhook functionality which is available when using NGW API.

For a basic "pass through" of the NGW notification to another cloud service such as Slack or Microsoft Teams as example, you can simple setup an incoming webhook on Slack or Microsoft Teams, which I had covered in the previous blog post. From there, you can configure an NGW subscription and forward the NGW notification to the specified incoming webhook.

For more interesting scenarios where customers may want to perform some additional data processing when the NGW notification arrives or run some code/automation and integrate that with other systems which can include your on-premises infrastructure, the basic webhook workflow is not sufficient. Having said that, at the end of the previous blog post I did hint at a solution that would enable customers to support such scenarios which is by leveraging the VMware Event Broker Appliance (VEBA) solution.

The way this works is that we are still taking advantage of the NGW webhook capability but instead of forwarding the NGW notification to a cloud service that supports an incoming webhook, we are sending it to VEBA for processing. Once the notification has been received by VEBA, customers can apply additional logic by using any language of their choice which runs as an automated function and is then responsible for sending the final payload to its destination. This is really the power of VEBA which enables customers to perform any additional processing or business logic to an event before sending it out to its intended target.

Removable M.2 NVMe SSD PCIe enclosure by Icy Dock

07/27/2020 by William Lam 2 Comments

My homelab is a constant experiment and hardware components are moved around for various testing, especially when it comes to networking and storage. When needing to move around an M.2 NVMe SSD, complexity of taking apart a system will vary on the platform but generally it is inconvenience. When I came to learn that Icy Dock, a manufacturer of storage enclosures, will be releasing a removable M.2 NVMe SSD tray that is connected to PCIe expansion slot, I knew I had to get my hands on it.

The good folks over at Icy Dock were kind enough to send me an early evaluational unit of the upcoming MB840M2P-B which will be released in August and should retail for around $80 USD (final prices are still TBD). The use case above may not apply to most folks and is probably unique to my specific hardware usage but I think this is still a very interesting solution that is still useful to be aware of if you are your own homelab whitebox and have a spare PCIe slot. Icy Dock also produces many other types of storage enclosures that you might find interesting based your own needs.

For my setup, I installed the MB840M2P-B into my Intel NUC 9 Pro, which is definitely not easy to take apart. This is especially true for the two M.2 which is attached to the NUC Element but even more painful to get to the 3rd M.2 which is located under the baseboard. For my specific use case, this was well worth using up one of the PCIe slots on the NUC 9 Pro!

Using the new installation method for deploying OpenShift 4.5 on VMware Cloud on AWS

07/18/2020 by William Lam 1 Comment

I recently saw a tweet from Jason Shiplett who works over on the VMware Validated Design (VVD) team (also my former team before joining VMware Cloud) who shared a new validated design for running Redhat OpenShift 4.3 on VMware Cloud Foundation. Funny enough, a couple of days ago I was just researching into deploying OpenShift running on VMware Cloud on AWS from a customer inquiry.

Timing could not have been better as RedHat just announced their OpenShift 4.5 release a few days ago as and one of the major updates is support for vSphere using their full stack automation also known as te Installer Provisioned Infrastructure (IPI) option. Previous to this, customers who wanted to deploy OpenShift on vSphere had to use the User Provisioned Infrastructure (UPI) method, which the VVD design also uses, which is much lengthier and complex when compared to the native IPI method.

For someone who has never worked with OpenShift before, this was great news and I get to try out this new deployment method on an VMware Cloud on AWS infrastructure 🙂

Pre-Requisites:

Step 1 - You will need a Linux system to perform the installation and it should have access to the vCenter Server running in VMware Cloud on AWS (VMC). In my example, I am using an Ubuntu Server 20.04 VM which is also running in the SDDC and has outbound internet connectivity.

Step 2 - Login to VMware Cloud on AWS console and create a new NSX-T network segment that is DHCP enabled. In my example, I named it openshift-network with a 192.168.3.0/24 configuration.

Step 3 - Navigate to Inventory->Groups and create the following groups and replace the CIDR networks with that of your SDDC:

Group	Name	IP Address Members
Compute	OpenShift Network	192.168.3.0/24
Compute	SDDC Management Network	10.2.0.0/16
Management	OpenShift Network	192.168.3.0/24