WilliamLam.com

Decoding Intel NUC "Canyon" Generation with CPU "Lake" Generation Codenames

by // 9 Comments

Swift Canyon, Baby Canyon, Bean Canyon, Provo Canyon, Kaby Lake, Whiskey Lake, Coffee Lake ... these are just some of the Intel codenames that either refer to a NUC platform or CPU generation. I can understand the need for codenames, however for consumers, the various names are often confusing and being able to grok at which system is the "latest" is not always trivial. In some cases there are multiple updates to different generations of the platform all happening within a short period of time and most online sites may swap between codenames and the official "Nth" generation nomenclature.

I have been working with the Intel NUC platform from a VMware standpoint since the 6th Generation back in 2016 and even I still get confused at times on what is the latest "Canyon" NUCs and their respective "Lake" CPU generations. I can not imagine how complicated this might feel for some of our customers who are updating their VMware homelab every couple of years or someone who is just starting out for the first time. To not only help keep myself sane as I often get asked about Homelabs, literally on a weekly basis and to help educate others within out community, I have created a document which maps all Intel NUCs (full height) to their respective Nth generation along with the respective CPU architecture used in each platform.

[Read more...]

Cross vCenter Workload Migration Fling v3.1

by // 26 Comments

Here is a small update to the Cross vCenter Workload Migration Fling which includes a couple of commonly requested features along with some bug fixes.

What's New in v3.1

  • Support for disk format conversion between Thick (Lazy Zeroed), Thick (Eager Zeroed) and Thin provisioning
  • Support for VM rename pattern for Clone operation
  • Fixed duplicated network selection when performing bulk migration
  • Fixed startup failure when a new home vCenter is specified as a command line argument

vSphere HTML5 and Standalone UI Client Support

In our 3.0 release, we added support for a native vSphere HTML5 (H5) Client experience which leverages new remote plugin framework that was introduced in vSphere 6.7 Update 1 and enables customers who prefer to use the H5 Client for their day to day use to also take advantage of the Cross vCenter Workload Migration Tool directly from the same UI. However, the addition of this new consumption UI created some confusion as some folks assumed this was the only mechanism. As stated in the release notes, we support both the new H5 UI as well as the standalone UI which many customers have been using for quite some time.

I suspect the confusion was due to the new CLI syntax which now requires specifying a vCenter Server endpoint to register. It is true that if you wish to use the new H5 Client integration, you will need to have a vSphere 6.7 Update 1 environment and provide credentials to that "home" vCenter Server. However, if you do not wish to use the H5 Client and you wish to use the old standalone client, you simply omit the vCenter Server registration details and the standalone client will work. In fact, even if you decide to use the H5 Client UI, you can always use the standalone client as that is the actual backend of the system.

Option 1: vSphere H5 Client Plugin

The following command will register the Cross vCenter Workload Migration Fling plugin to the specified vCenter Server:

java -jar xvm-3.1.jar --vcenter.fqdn=VCENTER-IP-OR-FQDN --vcenter.user=ADMIN-USER --vcenter.pass=ADMIN-PASSWORD

You will need to logout and then log back in to see the plugin which is located under "Menu" as shown in the screenshot below.

Option 2: Standalone UI Client

The following command will start the Cross vCenter Workload Migration Fling in standalone mode:

java -jar xvm-3.1.jar

You can then access the standalone client by opening a browser to localhost and port specified (default is 8443). You can always access the plugin locally whether you are using Option 1 or 2.

ESXi on the new 2019 Apple Mac Pro

by // 86 Comments

Inquiries from customers on the support for ESXi on the latest 2019 Apple Mac Pro 7,1 has slowly been trickling in since the release of the system in late December. Officially, VMware currently does not support this platform and until we have a unit in-house to investigate further, this is the official stance.

With that said, several folks from the community have reached to me and shared some of their findings as it relates to ESXi with the new Mac Pro. A huge thanks goes out to Mike Rimmer who was able to go through the installation process and identified that the on-board NICs were not automatically detected by ESXI and the installation was unable to proceed. With the extensibility of the Mac Pro, Mike was able to add a supported Intel-based NIC to the system so that we could further understand the issue.

Upon closer investigation, it looks like the new Mac Pro uses two Aquantia based 10GbE NIC which is simliar to the 2018 Mac Mini which requires the Aquantia ESXi driver which was developed earlier last year.

AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
Vendor ID: 0x1d6a
Device ID: 0x07b1

Although Mike did not have a chance to confirm this assumption, I did get validation from another customer who made the same observation when he attempted to install ESXi and once the Aquantia ESXi driver was incorporated into the latest ESXi 6.7 Update 3 image, both on-board NICs were automatically picked up by ESXi and installation was successful.

UPDATE (09/02/21) - Per this official blog post, VMware will no longer pursue hardware certification for the Apple 2019 Mac Pro 7,1 for ESXi.

UPDATE (04/28/20) - ESXi 6.7 Patch 02 resolves a number of the issues mentioned below, please take a look at this blog post here for more details.

UPDATE 1 (01/16/19) - Thanks to our Graphics team who was kind enough to loan me their 2019 Mac Pro which literally came in yesterday! I had an idea which I wanted to run an experiment on which was to add a PCIe card w/M.2 NVMe SSD and see whether or not the Apple T2 Security Chip would have any affect on whether or not ESXi would be able to see the device. I was not super optimistic but I had a need for an additional M.2 device, so I went ahead and purchased a $15 PCIe adaptor. I was pleasantly surprise to see that ESXi not only detected the device but I was able to format a local VMFS volume and power up a functional VM! I guess this makes sense as only the Apple SSD's are cryptographically tied to the T2 chip and other PCIe devices would not be and this would allow customers to take advantage of this system right now for running non-MacOS guests (yes, T2 still affects the SMC).

I also ran another experiment by connecting a Thunderbolt 3 chassis which also had a supported M.2 NVMe to see if I was going to be lucky again. Although it looks like ESXi 6.7 Update 3 has resolved the PSOD'ing issue, ESXi was not able to see anything on the other end.

Note: Secure Boot must be disabled on the Mac Pro before you can install ESXi, you can find the instructions in this Apple KB.


This was certainly some good news but like the 2018 Mac Mini, the new 2019 Mac Pro also ships with the Apple T2 Security Chip which has proved challenging for ESXi as mentioned here along with some known caveats. For now, I would hold off making any purchases of the new Mac Pro if you intend to run ESXi. VMware does officially support ESXi on the last current generation of Mac Pro 6,1 along with Mac Mini 6,2 and Mac Mini 7,1 which are all on the official VMware HCL.

I will continue to update this article as new information and findings are shared with me.