vSphere

Cross vCenter Workload Migration Fling v3.1

01/22/2020 by William Lam 1 Comment

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.

Intel NUC 9 Pro & Extreme – First “Modular” NUC

01/07/2020 by William Lam 21 Comments

The highly anticipated "modular" Next Unit of Computing (NUC) has just been announced at the Consumer Electronic Show (CES) this week, dubbed the Intel NUC 9 Pro (codename Quartz Canyon) and NUC 9 Extreme (codename Ghost Canyon). Boy am I super excited for this new platform and what it could mean for the VMware Community! 😍

Immediately off the bat, you can see that this is not your typical NUC "cube" form factor. Intel has completely redesigned the system from the inside and out, more on this in a bit. The key difference between the two NUC 9 variants (Pro and Extreme) are the CPU options, which are detailed below. For the remainder of this article, I will be focusing on the Pro version of the NUC 9 and I will call out any differences where applicable.

The use of the word "Pro" is also quite fitting as Intel is positioning this system as a high-end prosumer to Mid-Enterprise device compared to the traditional NUC. The NUC 9 Pro is targeting more demanding workloads such as Digital Content Creation, CAD/Manufacturing and Financial Service applications that either require a high-end graphics card or AI module for computing. When I first heard about this system from Intel, it conceptually reminded me of Apple's recent 2019 Mac Pro, which is also designed with modularity in mind and can cater to a variety of use cases.

Speaking of use cases, although Virtualization is not a target use case for this new platform, VMware customers have been taking advantage of the Intel NUCs for a number of years now and it is still by far the most popular platform for running a vSphere/vSAN/NSX Home Lab. However, one common complaint I often hear about the current generations of NUCs has been its CPU and I think the new NUC 9 Pro/Extreme will be a nice contender for current alternatives like the popular Supermicro E200-8D. Thanks to Intel, I was able to get my hands on a pre-production NUC 9 Pro unit for testing, so lets take a closer look at what this new platform has to offer!

Application Discovery in vSphere with VMware Tools 11

12/22/2019 by William Lam 10 Comments

The holidays are just around the corner and hopefully everyone is taking some time off to spend with their families, I know I certainly will! As I start to wind down 2019, I like to use this time catch up on things in my backlog that I was not able to get to in the year. This can range from blog posts that I still need to read, to session recordings that I have attempted to watch but have only made it half way to random notes on topics to potentially investigate in.

When VMware Tools 11 was released back in September, I had noticed an interesting feature that was delivered as part of that release:

Added appInfo to publish information about running applications inside the guest.

I thought this might be something worth looking at when I found some time. One of the nice benefits of having VMware Tools de-coupled from a specific vSphere release is that VMware can now ship additional GuestOS capabilities to customers without requiring them to upgrade the entire vSphere infrastructure, which brings us to the new appInfo feature.

AppInfo is a new plugin within VMware Tools that enables the collection of the "raw" running application processes within a GuestOS. Once enabled, this information is then published into new VM guestinfo property called guestinfo.appinfo which can then be consumed by standard vSphere Automation Tools. This has been one of the most common VM Automation questions I have received over the years from customers and we can now provide additional insights to our administrators on the underlying applications and its version running within a Virtual Machine.

By default, this new AppInfo capability is enabled by default after installing VMware Tools 11 and is supported with both Windows and Linux GuestOS. If you wish to disable this feature, you can find the instructions here. Below is a Windows Server 2016 which I have Active Directory among other applications running which has the appInfo collection enabled.

Once enabled, the default collection period runs every 30 minutes which can be changed following the instructions mentioned earlier. To make this easier to consume, I wrote a quick PowerCLI function called Get-VMApplicationInfo.ps1 which expects a VM object and then retrieves the appInfo details. As part of the output, the results also includes the last discovered time along with an update counter which can be used to track the number of times the collection has ran since enabling.

Listing all Events for vCenter Server

12/16/2019 by William Lam 2 Comments

I had a conversation with one of our VMware Cloud on AWS field leaders a couple of weeks ago at reInvent on his initial experience with the vCenter Event Broker Appliance (VEBA) Fling. There were lots great feedback but one thing that stood out to me which looks to have been a barrier to getting started was being able to figure out a specific vCenter Event and its respective identifier. Although the list of "default" vCenter Events are documented in the vSphere API, it is definitely not the first place most folks would go to look nor is it very intuitive to browse.

To be honest, this is not a unique ask for VEBA. I have also seen this requests come up from customers who are automating vCenter Alarms, which can also be based off of vCenter Events and the same question has come up on before. One challenge with such a request is that the number and the types of vCenter Events will vary from customer to customer depending on the number of 2nd and 3rd party solutions deployed, not to mention it will also vary from version to version. In addition, as a customer, you can also publish your own custom Events into vCenter Server which makes this difficult to provide a single list that would cover all possible scenarios.

Ultimately, this ask is completely valid and I started to look at the vSphere API to see if there was something that could help. It did not take look before I stumbled onto the EventDescription which is part of the EventManager, which provides a nice registry for all currently registered vCenter Events. Time for some Automation 🙂

Supermicro E300-9D (SYS-E300-9D-8CN8TP) is a nice ESXi & vSAN kit

11/23/2018 by William Lam 27 Comments

Supermicro kits such as the E200-8D is a very popular platform amongst the VMware community and with powerful Xeon-based CPUs and support for up to 128GB of memory, it is perfect for running a killer vSphere/vSAN setup!

Earlier this Fall, Supermicro released a "big daddy" version to the E200-8D, dubbed E300-9D and specifically, I want to focus on the 8-Core model (SYS-E300-9D-8CNTP) as this system actually listed on the VMware HCL for ESXi! The E300-9D can support up to half a terabyte of memory and with the 8-Core model, you have access to 16 threads. The E200-8D is also a supported platform by VMware, you can find the VMware HCL listing here.

I was very fortunate to get my hands on a loaner E300-9D (8-Core) unit, thanks to Eric and his team at MITXPC, a local bay area shop specializing in embedded solutions. In fact, they even provided a nice vGhetto promo discount code for my readers awhile back, so definitely check it out if you are in the market for a new lab. As an aside, when doing a quick search online, they also seem to be the only ones actually selling the E300-9D (8-Core) system which you can find here and in general, they seem to be priced fairly competitively. This is not an endorsement for MITXPC, but recommend folks to compare all prices when shopping online, especially as today is Black Friday in the US and Cyber Monday is just a few days away.

Is vCenter Server & ESXi hosts using VMware Certificate Authority (VMCA) or custom CA certificates?

10/23/2018 by William Lam Leave a Comment

Customers have two primary methods of managing TLS certificates for their ESXi hosts, they can either use the built-in VMware Certificate Authority (VMCA) which is part of vCenter Server or Custom CA Certificates. I will not go into the gory details, but you can read more about the options here in our documentation.

A question that I had received recently was whether you can determine the type of certificate an ESXi host was provisioned with and whether this could be programmatically retrieved using the vSphere API? The answer is yes. In vSphere 6.0, we introduced a CertificateInfo property which contains a number of fields including status, issuer, expiry and subject details and by inspecting either the issuer or subject property, you can determine the type of certificate on the ESXi host.

Here is a screenshot of the data using the vSphere MOB for an ESXi host that has VMCA-based certificate:

Here is a screenshot of the data using the vSphere MOB for an ESXi host that has custom CA certificate:

As you can see, for VMCA-based certificate the issuer's OU will have value of "VMware Engineering" and subject's emailAddress will have value of "*protected email*".