WilliamLam.com

Automated Nested Lab Deployment on SDDC Part 1: VMware Cloud on AWS

by // 2 Comments


While preparing for this years VMworld, I had the unique opportunity to work across a number of VMware Cloud SDDC solutions such as VMware Cloud on AWS (VMConAWS), Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE) and Oracle Cloud VMware Solution (OCVS). During the the development of several demos, I found it invaluable to be able to deploy a Nested vSphere environment to validate my configurations prior to connecting our real vSphere on-premises infrastructure.

Putting aside VMworld demos, this can certainly be extended to other use cases such as accelerated pilots, proof of concepts and lab/development purposes. Customers have been leveraging Nested Virtualization technology for more than a decade plus now and it definitely makes sense that they would also want to do the same for certain workloads running within a VMware Cloud SDDC. With that said, Nested ESXi is not officially supported by VMware or on any other VMware-based platform.

As part of building my VMworld demos, I also had spent some time on creating some automation that would make it easier for me to re-deploy these Nested Lab environments and also being aware of the specific VMware Cloud SDDC solutions, so that I only have a single script to maintain. In case folks are also interested in being able to do this, you can follow this 4-part blog series which I will be kicking it off with VMware Cloud on AWS (VMConAWS).

[Read more...]

USB Network Native Driver now supports ESXi 7.0 Update 1

by // 8 Comments

I know many of you have been asking about this and today I am happy to share that the USB Network Native Driver for ESXi Fling is now supported with ESXi hosts running the latest 7.0 Update 1 release.

Note: The USB Network Native Driver is only supported with x86 ESXi and NOT with the ESXi-Arm Fling, there seems to be some confusion since these are two different CPU architectures.

In addition, there are a couple of minor enhancements (see changelog for details), but one feature that I am super excited to see incorporated into this version of the Fling is the automatic persistency of USB NIC binding, which maps physical USB NICs to either a Standard or Distributed Virtual Switch. Previously, this required users to update the local.sh script on ESXi to automatically restore the NIC bindings since the processing of these interfaces happens much later in the boot up process. These tweaks are no longer required when using this version of the Fling!

This enhancement was the direct result from Andrei Warkentin and his work on the ESXi-Arm Fling with the Raspberry Pi! Huge thanks to him for this contribution and hopefully we can repay that back one day with the integration of the USB Network Native Driver into the ESXi-Arm Fling 😉

Automated network scripted installation of ESXi-Arm without SD Card

by // 5 Comments

A topic that I have been working on even before the release of the ESXi-Arm Fling is the ability to perform a network scripted installation (Kickstart) of ESXi-Arm for the Raspberry Pi (rPI) but doing so without the need of an SD Card plugged into the rPI itself. The latter point is critical as today, the SD Card is used to house the required UEFI files to allow the rPI to boot the ESXi-Arm installation files which can be served from a local USB device or remotely over the network using HTTP, NFS or even iSCSI boot, which Andrei had recently blogged about.

Running through the SD Card preparation is not a difficult process and if you only have a single ESXi-Arm host, this may not be all that interesting other than learning about how this works and setting up a basic Kickstart environment. However, if you have several rPI and maybe you do not have spare SD Card and you prefer to make it easy to deploy additional ESXi-Arm host, this is a pretty cool solution. The precursor to this work was actually from a blog post I had published a few weeks ago on copying the rPI UEFI files and booting ESXi-Arm off of a USB device.

Once I figured out how that worked, it was simply figuring out the automation required during the %post section of a scripted installation of ESXi-Arm to pull down a copy of the UEFI files which is then copied onto the first partition of the USB device and thus allowing you to completely boot off of the USB device after installation. This took some trial and error playing around with mcopy which is a tool I have written about to help copy files to and from a USB device using the ESXi Shell. The other trick that we are taking advantage of here is that the USB device that you intend to use are mostly the same from a UEFI point of view and by disabling all other boot option, we ensure that after the UEFI files are copied over to ESXi-Arm host, it will boot from USB device rather than over the network.

[Read more...]