esxi

VMworld Startup: Hivecell – Stackable Edge Computing

09/05/2019 by William Lam Leave a Comment

One thing I really enjoy at VMworld when I have a few minutes to spare between sessions and customer meetings is to walk around the Solutions Exchange and learn about what our partners are doing in the VMware eco-system. I usually do not make it in very far before bumping into an old colleague or customer before having to run to my next engagement, but some times I get lucky.

While walking the show floor, I came across a really interesting company that immediately caught eye and you can probably guess why from the picture I took below.

The company is called Hivecell and they make it super easy for Global 500 companies to deploy and maintain software at the Edge without requiring a large IT team to manage the deployments which can be spread across hundreds if not thousands of sites with very little to no IT staff.

One of the biggest challenges with Edge Computing is being able to process the large quantity of data being generated in all of these remote locations on a daily basis. In some cases, the dataset can grow up to several Terabytes and it is no longer feasible to send all of this data to the Cloud or back to your Datacenter to extract the business intelligence and value. In fact, depending on the connectivity of your remote site, it can take weeks before the data is available. For any type of real or near-real time applications, the window where the data is of value can literally be hours if not minutes and it must be processed immediately at the Edge.

Speaking of use cases, here are some of the scenarios where Hivecell believes they can really help with their solution, more details about each use case can be found here.

Petrochemicals
Renewable Energy
Quick Service Restaurant Chains
Manufacturing
Healthcare
Weather
Data Science
Hotels

Apple Mac Mini on VMware HCL!

08/01/2019 by William Lam 8 Comments

For the past 6 years, the Apple Mac Mini has been one of the most popular hardware platforms for Virtualizing MacOS running on VMware vSphere enabling our customers to develop and build iOS and MacOS applications. With that said, VMware has historically only supported two Apple hardware platforms: Xserve (now EOL'd) and the Mac Pro (6,1) which is officially listed on VMware's Hardware Compatibility list and this has been officially supported by VMware since 2012 when we first introduced support for MacOS Virtualization with the vSphere 5.0 release.

As many of you know, I have been a huge advocate of this platform for a number of years now and I have been working with various Engineers over the years to ensure that we have the exact same user experience when working with ESXi on the Mac Mini as you do with the Mac Pro. I still recall in the early days where it took several "hacks" to get ESXi to successfully boot and install.

Today, ESXi installs on the Mac Mini just like any other x86 platform. It runs amazing well for our customers, especially for a consumer device, who have deployed them in their datacenters ranging from a couple hundred to several thousands for some of our larger Enterprise customers, one such example is MacStadium, the largest Apple Infrastructure-as-a-service provider which many of the Fortune 100/500 companies are leveraging to provide them with a platform to build and develop for the Apple eco-system.

How to prevent physical CD-ROM from ejecting after installing or upgrading ESXi?

07/15/2019 by William Lam Leave a Comment

While catching up on some news over the weekend, I had noticed a VMware Reddit thread asking a pretty interesting question on how to prevent the physical CD-ROM tray from ejecting after installing or upgrading ESXi? This behavior occurs whether you are using a physical CD-ROM media or a "Virtual" ISO image via an out-of-band interface like an iDRAC or iLO. If you are automating the installation or upgrade using Auto Deploy or network installation such as Kickstart, this is not a problem.

However, I was a bit surprised to hear that this was still a pain point in 2019, as many of the new servers in market do not even include an option for CD-ROM. Some of the suggestions really brought me back to the early 2000's including physically taping up the CD-DROM tray, which I have definitely seen customers doing but this is not a scalable solution and it requires a visit to the datacenter.

One easy solution that I had suggested was to take advantage of ESXi's scripted installation capability also known as Kickstart and use the supported ESXi --noeject option after reboot. Since the install/upgrade was being done manually, the added benefit of this solution is that you can now have it automated 🙂 The other nice thing about this option is that you can specify the kickstart using the default ESXi ISO or you can take it a step further and embed the Kickstart with a custom ESXi ISO.

Automated ESXi Installation to USB using Kickstart

07/09/2019 by William Lam 5 Comments

I frequently re-install ESXi on my physical host for various types of testing as I normally work with a number of future releases. Although the process just takes a couple of minutes, having to enter the exact same information each time and also requiring a keyboard and monitor is not really ideal. For the majority, this is really not a problem and manually going through the install workflow is fine for most folks, especially as this is an infrequent operation.

However, with some recent customer conversations, I thought it was worth while to re-visit this topic and demonstrating just how easy it is to automate the installation of ESXi with just a single bootable USB device and embedding an ESXi Kickstart Script. Even for infrequent installation and/or upgrades of ESXi for home labs, this can be a time saver, especially if you do not have monitor and keyboard just lying around. Below are instructions including a reference Kickstart example that folks can use as a starting point. For more advanced automation, please take a look at my ESXI Kickstart Resources as well as the official VMware documentation for ESXi Scripted Installations.

Aquantia 10GbE ESXi Driver for Apple 2018 Mac Mini

04/10/2019 by William Lam 10 Comments

I know many of you have been anxiously waiting for ESXi to be fully functional on the latest Apple Mac Mini (2018), unfortunately I do not have any news to share with you on that front. Without help from Apple, we are still challenged with Apple's new T2 chip, which prevents us from accessing the underlying NVMe device.

Having said that, I do have some exciting news regarding the built-in 10Gigabit Ethernet adaptor on the 2018 Mac Mini. The 10GbE adaptor uses an Aquantia chipset, this is also the same chipset used in Apple's high end iMac Pro which was released earlier in the year. Over the past few weeks, I have been working with the Aquantia team and they have successfully ported over their open source Atlantic driver to a VMKlinux driver for ESXi, which they have published here. Although the local NVMe device can not be used to run any VMs, with the network fully enabled, customers could take advantage of this model and connect to IP-based storage to start leveraging the new Mac Mini platform.

The easiest way to incorporate the driver into the latest ESXi release is to use Image Builder within the vSphere H5 Client UI, below are the step-by-step instructions.

Revisiting prompting for user input during an interactive or scripted install of ESXi

01/10/2019 by William Lam 3 Comments

For those that have a need to prompt for additional user input during an installation of ESXi, whether that is an interactive session or using a scripted install (Kickstart) may have noticed the solution posted in my 2015 blog post no longer works with recent releases of ESXi (newer than 6.0).

I was recently contacted by VMTN community cacheman, who authored the original snippet after my 2011 post with an updated solution that would work with newer releases of ESXi (e.g. 6.5 or newer). Thanks to Chris, he discovered the following after taking another look at the initial hack:

It seems that the tty1 techsupport.sh which I had commented out in /etc/inittab is having no effect in these versions and the login prompt is starting on tty1. As far as I can tell this is because for versions >= 6.5, the init process starts before the extras.tgz is unpacked, so it reads the /etc/inittab that comes natively with ESXi rather than the modified one in extras.tgz.