esxi

ESXi on the new 2018 Apple Mac Mini

11/09/2018 by William Lam 33 Comments

Thanks to the Green Mini Host (Apple Mac Mini hosting and collocation provider) who were the first to publicly confirm that latest release of ESXi (6.7 Update 1) works on the recently announced 2018 Apple Mac Mini.

Conforming @VMware #ESXi runs on the new Mac Mini 2018! #macmini2018 @vGhetto @lamw pic.twitter.com/DRqQ4lsWn5

— Green Mini host (@macminihost) November 7, 2018

For vSphere/vSAN Home Lab enthusiasts, the price of the new Mac Mini, especially when it is fully loaded is probably a tough sale. However, for customers developing on MacOS including iOS development, CI/CD, build farms, gaming, etc. which benefit from running on vSphere. For these customers, support for ESXi on the new Mac Mini is extremely interesting, especially with the updated hardware giving these systems a significant boost in performance even when comparing to the current Mac Pro 6,1 and iMac Pro models. In fact, I had number of folks ping me after Apple introduced it during their keynote asking if ESXi would work on the Mini's.

Disclaimer: Apple Mac Mini (both old and new) hardware are NOT officially supported by VMware. The only officially supported Apple hardware platform is the Mac Pro 6,1 or Mac Pro 5,1. For more details, please refer to VMware's Hardware Compatibility List.

ESXi on a Raspberry Pi

11/07/2018 by William Lam 34 Comments

During the closing of the VMworld Europe Keynote on Tuesday, Ray O'Farrell (CTO of VMware) had one more "tiny" surprise for our CEO, Pat Gelsinger 😉 He handed him a tiny little device called the Raspberry Pi (rPI) which was running a prototype version of ESXi! This was completely unexpected even for VMware Employees, especially as we had just announced our ESXi on ARM initiative at VMworld US. You can watch the keynote replay here starting at 1:37:15.

As you can imagine, this created a TON of excitement and buzz at the VMworld but it also sparked some interesting conversations on why VMware would even do this? Was this just a marketing gimmick or was there something more significant in showing that ESXi could run on a rPI?

Interested in @VMware #ESXi on @Arm? Want to understand the VMware Edge vision? See Alex and Regis at the Virtualization at the Edge booth, in the #IoT and Edge Zone at #VMworld2018 in Barcelona! pic.twitter.com/qGO3AO76JD

— It's an Arm world (virtualized) (@WhatAintInside) November 6, 2018

Retrieving Apple hardware details (Model, Serial, Board & EFI Boot ROM & SMC Version) from ESXi

10/31/2018 by William Lam 2 Comments

For customers who run ESXi on Apple Hardware, retrieving the Apple hardware specific information such as the Board ID, EFI Boot Room and SMC Version for troubleshooting or auditing purposes can be challenging. Historically, this information is only available when running the hardware with an Apple MacOS operating system and customers would have to either boot the system into the MacOS Recovery Mode to run the system profiler tool from the command-line or install a full blown MacOS operating system to retrieve the necessary information as outlined in this Apple KB.

For some customers, this may not even be an option as Apple hardware does not provide any remote management capabilities and customers must physically be in front of the system to perform this process and imagine needing to do this across a fleet of Apple servers.

While working on a recent case with a customer, I was curious if the Apple specific information could be retrieved from within ESXi and remove the need to boot into MacOS? I reached out to one of the Engineers, Darius Davis, who I work with on a frequent basis when it comes to MacOS-related topics to see if this was possible.

How do you “log a reason” using PowerCLI when rebooting or shutting down ESXi host?

06/04/2018 by William Lam 2 Comments

I am sure many of you have seen this UI prompt asking you to specify a reason before issuing a reboot or shutdown of an ESXi host and I assume most of you spend a few seconds to type in a useful message and not just random characters, right? 😉

Have you ever tried performing the same reboot or shutdown operation using the vSphere API or PowerCLI (which leverages the API)? Have noticed, there is not a way to specify a message like you can in the UI?

Here is a table of the PowerCLI cmdlets and the respective vSphere API that is used to perform these two operations:

Operation	Cmdlet	vSphere API
Reboot	Restart-VMHost	RebootHost_Task
Shutdown	Stop-VMHost	ShutdownHost_Task

When looking at either the PowerCLI and/or vSphere API documentation, we can confirm that there are no fields to specify a message which can lead to an assumption that this is simply not possible or that the functionality might be provided by a private API. Fortunately, this is not the case and the functionality is in fact in the public vSphere API and has been for quite some time.

When you specify a message prior to rebooting or shutting down, this message is actually persisted and implemented as an Event within vCenter Server as shown in the screenshot below.

Instead of being able to specify a message that is only applicable to an ESXi host, I believe the original vSphere API designers thought that this functionality could also be useful and applied more broadly across any number of the vSphere Inventory objects, not just ESXi hosts. As such, this functionality which the vSphere UI uses is provided by the LogUserEvent() method which is part of the EventManager API. Customers or solutions can leverage this mechanism to log custom user defined events which is then persisted with the lifecycle fo the vSphere Inventory Object or as far back as your retention period for vCenter Server Events.

Going back to our original question, if you want to specify a message prior to rebooting or shutting down an ESXi host, the following snippet below demonstrates the use of the vSphere API via PowerCLI:

$eventManager = Get-View eventManager
$vmhost = Get-VMHost -Name 192.168.30.11
$message = "This message will be logged"

$eventManager.LogUserEvent($vmhost.ExtensionData.MoRef,$message)

$eventManager = Get-View eventManager

$vmhost = Get-VMHost -Name 192.168.30.11

$message = "This message will be logged"

$eventManager.LogUserEvent($vmhost.ExtensionData.MoRef,$message)

Quick Tip – What hashing algorithm is supported for ESXi Kickstart password?

05/21/2018 by William Lam 2 Comments

I had a question the other day asking whether the encrypted password which can be specified within an ESXi Kickstart file (denoted by the --isencrypted flag) can use a different hashing algorithm other than MD5? The answer is absolutely yes. In fact, MD5 as a default hashing algorithm has NOT been used for a number of releases, probably dating back to classic ESX (you know, the version that had the Service Console).

For all recent releases of ESXi including 5.5 to 6.7, the default hashing algorithm has been SHA512 for quite some time now. Below are two ways in which you can check which default hashing algorithm is currently being used:

Option 1 - SSH to ESXi host and take a look at /etc/pam.d/passwd

Option 2 - SSH to ESXi host and take a look at /etc/shadow and look at the field prior to the salt.

As a reference:

$1$ - MD5
$5$ - SHA256
$6$ - SHA512

New VMware Configuration Maximum Tool

04/13/2018 by William Lam 1 Comment

VMware has just released a new web-based tool that will enable customers to easily view and compare product configuration maximums across different VMware product versions. You can access the easy to remember URL by going to: https://configmax.vmware.com

In this first release of this tool, customers will have the ability to look up configuration maximums for vSphere (includes VSAN) which will initially support vSphere 6.0, vSphere 6.5, vSphere 6.5 Update 1 & the recently released vSphere 6.7 as well as comparing across versions. To view the existing vSphere configuration maximum, simply click on the "Get Started" button.

As you can see from the screenshot below, you now have a single place where you can view the vSphere configuration maximums across different versions. Once you have selected the target version, you can either view all maximums or you can selectively choose the sections you are interested in.

The other really neat feature is the ability to compare the configuration maximums across different vSphere versions. This is really useful for customers to be able to quickly tell what improvements and enhancements have been made, especially as customers plan for vSphere upgrades. To begin, simply click on the "Compare Limits" button at the top. Next, select the target vSphere version and then you can add one or more versions to compare against.

Once you click on the Compare button, a new window will popup providing you the comparison between the target and selected vSphere versions. You can quickly see how the maximums have changed across these vSphere versions. You can even export the results to Excel by click on export option on the upper right hand corner and you be prompted to save a CSV file.

I can tell you, this definitely beats having to manually Google for the correct vSphere configuration maximum document since I can never remember the long URL to the static PDF documents! I am excited to see the improved user experience when consuming our product maximums and I know the team will be working on adding more products and features in the future. Definitely keep an eye on this site and also be sure to update your bookmarks. If you have any feedback or things you would like to see, feel free to leave a comment and I will make sure it reaches the Product and Development teams.