William Lam

VMworld 2020 Demo – Voice activated workload migration to VMware Cloud SDDCs

10/19/2020 by William Lam Leave a Comment

One of my favorite but also most stressful part of preparing for a VMworld session is creating the demos. Even with a "virtual" VMworld this year, I personally felt it was even more stressful than a physical VMworld.

I have been presenting with Emad Younis for a number of years now and every year, we always end up with crazy ideas without thinking through all the feasibility aspects. This year was certainly no different and while working on our demo this year, I was seriously questioning my sanity and even the actual return on investment (ROI), if such a thing exists!? 😂

In case you have not watched our session, check out HCP132: Planes, Trains and Workload Mobility, you can watch it for free and see the full demo.

I was really floored by all the positive feedback that we had received from attendees which includes the VMworld survey but also on Twitter and Slack. This was one of my favorite tweet and response 😀

Best session I have seen so far👏😁

— Wesley Geelhoed (@wessieloerus) September 30, 2020

We really appreciate all the feedback and it definitely made up for some of the late nights where I was about to give up. I know a few of you were asking for more details about the demo and so this blog post will be focusing on some of the information I was not able to get to during the VMworld session.

Kubernetes on ESXi-Arm using k3s

10/16/2020 by William Lam Leave a Comment

The tiny form factor of a Raspberry Pi (rPI) is a fantastic hardware platform to start playing with the ESXi-Arm Fling. You can already do a bunch of fun VMware things like running a lightweight vSAN Witness Node to setting up basic automation environment for PowerCLI, Terraform and Packer to running rPI OS as VM, enabling some neat use cases like consolidating your physical rPI assets which might be running RetroPi and Pi-Hole which many home labbers are doing.

In addition to VMware solutions, its is also a great platform to learn and tinker with new technologies like Kubernetes (K8s) which I am sure many of you have been hearing about 🙂 Although our vSphere with Tanzu and Tanzu Kubernetes Grid (TKG) does not currently work with the ESXi-Arm Fling, I have actually been meaning to try out a super lightweight K8s distribution designed for IoT/Edge called k3s (pronounced k-3-s) which also recently joined Cloud Native Computing Foundation (CNCF) Sandbox level.

k3s is supported on rPI and you normally would have multiple rPI devices to represent the number of nodes, for example if you want a basic 3-Node cluster, you would need three physical rPI devices. With ESXi-Arm, you can now create these nodes as VM, using just a single rPI. This opens up the door for all sorts of explorations, you can create HA cluster or try out more advanced features which might be more difficult if you needed several physical devices. If you mess up, you can simply re-deploy the VM without much pain or simply clone the VM.

In my setup, I am using 3 x Photon OS VMs. One for the primary node and two for k3s worker nodes. You can certainly install k3s on any other Arm-based OS including rPI OS (which can now run as a VM as mentioned earlier).

Installing VMware Tools on Raspberry Pi OS for ESXi-Arm

10/15/2020 by William Lam 2 Comments

Now that you have Raspberry Pi (rPI) OS running as a VM on ESXi-Arm, the next thing you will probably want to install is VMware Tools, especially useful to see the IP Address of your Guest if you are using DHCP and for enabling guest "soft" shutdown using the vSphere UI. Below are the instructions

How to copy the Raspberry Pi UEFI files and boot ESXi-Arm using just USB device?

10/14/2020 by William Lam 2 Comments

There are actually a number of ways to boot and install the ESXi-Arm Fling, but the easiest method is already outlined in the official ESXi-Arm Raspberry Pi (rPI) documentation and the PDF can be downloaded from the Fling website. As a quick refresher, you only need to have two storage devices.

SD Card - Used to store the rPI UEFI files which is required to boot ESXi-Arm Installer
- ESXi-Arm can not run on SD Card and for these reasons, you do not need a large capacity SD Card
USB Device - Contains ESXi-Arm Installer / Installation
- After the ESXi-Arm installer boots, you can actually re-use the exact same USB device for the installation of ESXi-Arm itself. A separate USB device is not required unless that is your goal or if the capacity is not enough for running VMs

The boot process after the ESXi-Arm installation is that the UEFI firmware will first load on the rPI and then it will boot up the ESXi-Arm from the USB device. As mentioned, there are other variations but this is the most basic option. The other nice behavior is that if you need to re-install ESXi-Arm, you simply create a bootable USB device with the ESXi-Arm installer and then install that right on the same USB device without having to mess with UEFI image. This also allows you to perform scripted installation also known as Kickstart, which is something I will be covering in the future that takes UEFI image into consideration.

I have seen a few questions asked whether it is possible to have everything run off of the SD Card and/or USB Device and the answer is yes to certain degree.

It is possible to put the ESXi-Arm installer + UEFI on SD Card but ESXi-Arm will NOT be able to use it as installation media, so there is not a whole ton of value there.
It is possible to have both the UEFI image and ESXi Installation on the same USB device, especially if you do not have spare SD Cards which apparently has come up a few times

In this blog post, I will outline the instructions for booting an installed ESXi-Arm installation completely off of the USB device without the needing an SD Card containing the UEFI image.

OVFTool 4.4.1 – Upload OVF/OVA from URL using upcoming “pull” mechanism

10/14/2020 by William Lam 2 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

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

ovftool \
--X:logFile="ovftool.log" \
--acceptAllEulas \
--allowAllExtraConfig \
--allowExtraConfig \
--noSSLVerify \
--sourceSSLThumbprint="BA:C6:4E:D9:AD:D4:53:B5:86:5A:5D:70:36:CF:89:93:D1:6C:F9:63" \
--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.

How to run Raspberry Pi OS as a VM on ESXi-Arm

10/13/2020 by William Lam 9 Comments

It has only been a week since the ESXi-Arm Fling was released, but the amount of experimentation and frankly cool s*** that people have been able to do in such a short period of time has been pretty mind blowing. For example, did you know you could run ESXi-Arm on Nintendo Switch!?🤯

Andrei recently published a blog post on the official ESXi-Arm blog showcasing some of the really cool stuff the community has shared on Twitter, definitely worth checking digest post #1 it out if you have not seen it.

Something that really caught my eye which I did not see mentioned in Andre's blog post was from Twitter user Joakim Korhonen who shared that he was able to run Raspberry Pi's (rPI) OS (formally Raspbian OS) as a Virtual Machine running on top of the ESXi-Arm Fling!

running raspberry pi os on esxi on raspberry pi. nice.
needs uefi grub and debian kernel#raspberrypi #esxionarm pic.twitter.com/QcOxMAiSuC

— Joakim Korhonen (@korhojoa) October 8, 2020

This is pretty interesting because rPI OS was designed to run on a physical rPI and there are no installers other than the image file which you download and copy onto the SD Card to boot. What is really exciting about this news is that you can now run any of the popular rPI applications such as RetroPi or Pi-hole which traditionally may have required several rPI to host.

In addition, this can also benefit the rPI OS development community by making it easier to build and test applications on top of rPI OS as you can now spin these up as VMs and get all the benefits of vSphere and ESXi such as snapshots, cloning, etc. The possibilities are endless and wanted to give a huge thanks to Joakim for sharing his hack on getting this to work on ESXi-Arm. For those interested, I have documented the detailed instructions below.