WilliamLam.com

Search Results for: supermicro

How to create a custom Tanzu Kubernetes Grid (TKG) Node OVA based on Photon OS Real Time Kernel?

by // 7 Comments

One really cool feature of Tanzu Kubernetes Grid (TKG) is the ability to bring your custom images (BYOI) which can then be used to deploy TKG Workload Clusters. To do so, customers will need to use Kubernetes (K8s) Image Builder tool to author new OVA images and then make TKG aware by updating the Tanzu Kubernetes Release (TKR) Build of Materials (BOM) configuration.

I had played around with Image Builder awhile back during the TKG 1.2 release and it definitely was not very easy to use. I have been meaning to kick the tires on Image Builder again as I know with the latest 1.3.x release, there have been a number of improvements. This week I saw an inquiry from my buddy Alan Renouf who was looking to see if there was a way to use the new Photon OS Real Time Kernel as a base image for a K8s-based application that he was working with that had requirements for the real time kernel.

Interestingly enough, there was another inquiry with a similiar customer request for their edge deployment and I thought this would be a good opportunity to try out Image Builder again, which has been overhauled and the build process can be completely consumed as a Docker container, which definitely made things much easier than before. I also had never played with real time version of Photon OS, so this gave me a reason to try that out which was initially introduced with Photon OS 4.0 but it also looks like real time kernel was added to 3.0 recently, which is the version I had used to test.

Note: vSphere with Tanzu currently does not support the ability to bring your own image like TKG, I know this is something that has been asked about and is being considered in the future.

The BYOI process for TKG is comprised of two steps:

  • Create Custom TKG OVA
  • Update TKG with new TKR BOM

Although there are detailed documentation for this process, I still ran into a number of issues which I think the documentation could be improved with a complete working example rather than using generic values which lead to some interpretation, which I did not interpret correctly the first time through. After posting some questions in the Image Builder Slack Channel, I was able to finally connect the dots with the help from Scott Rosenberg, who I also knew, as a customer of our VMware Event Broker Appliance (VEBA) Fling. Putting everything together, I figure it would be useful to document the process I took and hopefully this can benefit other customers looking to build and consume their own OVA images with TKG.

[Read more...]

Complete vSphere with Tanzu homelab with just 32GB of memory!

by // 43 Comments

Since the release of vSphere 7.0 Update 1, the demand and interests from the community on getting hands on with vSphere with Tanzu and the new simplified networking solution, has been non-stop. Most folks are either upgrading their existing homelab or looking to purchase new hardware that can better support the new features of the vSphere 7.0 release.

Although vSphere with Tanzu now has a flavor that does not require NSX-T which helps reduces the barrier on getting started, it still has some networking requirements which may not be easily met in for all lab environments. In fact, this was actually the primary reason I had started to look into this since my personal homelab network is very basic and I do not have nor want a switch that can support multiple VLANs, which is one of the requirements for vSphere with Tanzu.

While investigating for a potential solution, which included way too MANY hours of debugging and troubleshooting, I also thought about the absolute minimal amount of resources I could get away with after put everything together. To be clear, my homelab is comprised of a single Supermicro E200-8D which has 128GB of memory and that has served me well over the years and I highly recommend it for anyone that can fit that into their budget. With that said, I did set out with a pretty aggressive goal of using something that is pretty common in VMware homelabs which is an Intel NUC and with just 32GB of memory.

UPDATE (07/02/24) - As of vSphere 8.0 Update 3, you no longer have the ability to configure a single Supervisor Control Plane VM using the minmaster and maxmasters parameters, which have also been removed from /etc/vmware/wcp/wcpsvc.yaml in favor of allowing users to control this configuration programmatically as part of enabling vSphere IaaS (formally known as vSphere with Tanzu). The updated vSphere IaaS API that allows users to specify number of Supervisor Control Plane VM will not be available until the next major vSphere release. While this regressed capability is unfortunate, it was also not an officially supported configuration and for users who wish to specify the number of Supervisor Control Plane VM using YAML method, you will need to use an earlier version of vSphere.

[Read more...]

OVFTool 4.4.1 - Upload OVF/OVA from URL using upcoming "pull" mechanism

by // 12 Comments

I was helping a fellow colleague yesterday with an OVA question and I came to learn about an upcoming feature in the popular OVFTool utility that would allow for a new method of uploading a remote OVF/OVA to either a vCenter and/or ESXi endpoint.

Historically, when you upload an OVF/OVA whether that is stored locally or remotely from a URL, the data path will actually transfer through the system running the OVFTool between the source and destination, which is ultimately the ESXi host which performs the actual download. Although the OVF/OVA data is not actually stored on your local system, the traffic is proxied through your system and can add an unnecessary hop if the remote OVF/OVA URL can directly be accessed by ESXi host.

A new --pullUploadMode flag has been introduced in the latest OVFTool 4.4.1 release, which will allow ESXi host to directly download (pull) from the remote OVF/OVA URL, assuming it has connectivity. In addition to version of OVFTool, you will also need to have either ESXi 6.7 or 7.0 environment for this new feature to work.

Disclaimer: Although this feature is available in latest OVFTool release, it is still under development and should be considered a Beta feature in case folks are interested in trying it out.

Since the ESXi host is directly downloading from the remote source, there are two additional security verification that has already been implemented. The first is an additional vSphere Privilege called "Pull from URL" which is under the vApp section. Without this, you will get a permission denied error.


Secondly, in addition to specifying the new CLI option, you will also need to provide another flag called --sourceSSLThumbprint which should include the SHA1 hash of endpoint hosting the OVF/OVA. This is an additional verification to ensure the validity of the server hosting the OVF/OVA.

Here is an example of deploying my latest ESXi 7.0 Update 1 Virtual Appliance OVA which is remotely hosted. The quickest way to obtain the SHA1 thumbprint is simply opening browser to based URL which is https://download3.vmware.com/


You will need to replace the space with ":" (colon), so the final string should look like BA:C6:4E:D9:AD:D4:53:B5:86:5A:5D:70:36:CF:89:93:D1:6C:F9:63

Note: The SHA1 thumbprint example shown above is only valid as of Oct 2020, as TLS certificates are replaced periodically, the SHA1 hash will change.

Here is an example OVFTool command to deploy from the remote URL

ovftool \
--X:logFile="ovftool.log" \
--acceptAllEulas \
--allowAllExtraConfig \
--allowExtraConfig \
--noSSLVerify \
--sourceSSLThumbprint="B2:52:9E:4D:57:9F:EA:53:4D:A0:0B:7F:D4:7E:55:91:56:C0:64:BB" \
--name="Nested-ESXi-7.0-Update-1-Appliance" \
--datastore=sm-vsanDatastore \
--net:"VM Network"="VM Network" \
--pullUploadMode \
https://download3.vmware.com/software/vmw-tools/nested-esxi/Nested_ESXi7.0u1_Appliance_Template_v1.ova \
'vi://*protected email*:[email protected]/Primp-Datacenter/host/Supermicro-Cluster'

If we switch over to the vSphere UI, we should see a new task called "Download remote files" which indicates the new pull method is being leveraged. One thing to note is that because ESXi is now performing the download directly, progress may not be known by the OVFTool client, since it is not longer the source for the data transfer. Another thing to be aware of is that OVFTool itself has built-in retry logic in case there is a slight interruption during the data transfer with the current mechanisms. In the "pull" scenario, there is no retry by ESXi and so depending on connectivity, its possible deployments can fail and complete re-transfer would be required.