NSX

Retrieving network statistics on VMware Cloud on AWS using NSX-T Policy API

07/16/2020 by William Lam 1 Comment

One question that has come up lately from VMware Cloud on AWS customers is to understand their network traffic usage, especially as it pertains to traffic that exit or egress their SDDC. There are a number of graphical tools that can be used today to get insights into this information, one is the popular vRealize Network Insight Cloud solution which many of our VMware Cloud on AWS customers are taking advantage of to not only understand traffic usage and flow data history but is also instrumental in aiding customers when planning workload migrations from their on-premises datacenter to VMware Cloud on AWS.

While researching this topic, I also came to learn that this information can be retrieved using the NSX-T Policy API which is available to all customers to use. We are going to be leveraging the Tier-0 statistics interface API from NSX-T which will give us both transmit and receive stats on all supported interfaces. From the diagram below, we can see the interfaces that are applicable to VMware Cloud on AWS is the Internet interface which includes VPN traffic, VPC interface which includes traffic going to Linked VPC and Direct Connect interface which includes traffic when using AWS Direct Connect.

As you might expect, these exact same three interface types is then represented as logical interfaces within the NSX-T Policy API which uses the following IDs:

cross-vpc
public
direct-connect

Note: Statistics on the Direct Connect interface will also include traffic if you are using the new VMware Transit Connect with AWS Transit Gateway feature.

These interface can be discovered by performing a GET on /policy/api/v1/infra/tier-0s/vmc/locale-services/default/interfaces and then you would then identify the two NSX-T Edge (Active/Passive) and construct the T0 URL to retrieve the statistics. I will not bore you with the details and have implemented this as a new PowerShell function called Get-NSXTT0Stats and for those interested in the implementation, please see the code here.

Note: For those wanting to see the full NSX-T Policy REST URLs, simply append -Troubleshoot flag and that will output additional information on how I am retrieving the various pieces of information required to call into the T0 Stats API.

Configure NSX-T Edge to run on AMD Ryzen CPU

05/06/2020 by William Lam 4 Comments

The vast majority of VMware Homelabs is still Intel-based today but I have been seeing a slow rise of AMD-based kits being adopted, especially with AMD's desktop line of CPUs known as Ryzen. One of the considerations on whether you could use an AMD processor was whether you were planning to deploy NSX-T and in earlier releases, only Intel was supported as the NSX-T Edge required support for Data Plane Development Kit (DPDK) and this was only supported with Intel-based processors.

With the latest NSX-T 3.0 release, AMD-based processors are now supported and per the release notes, the following CPUs can be used:

AMD EPYC 7xx1 Series (Naples)
AMD EPYC 3000 Embedded Family and newer
AMD EPYC 7xx2 Series (Rome)

You will notice that only AMD's server line of CPUs known as EPYC are currently supported, which makes sense for running Production workloads. If you attempt to deploy an NSX-T Edge Node running on a non-EPYC platform, you will get an error message stating the CPU is not supported and I figured this was probably due to the lack of DPDK support in the consumer CPUs.

Yesterday, in our internal "Homelab" Slack channel, I came across an interesting tidbit from Andrea Spagnolo, a Sr. Field Engineer in our Cloud Native Business Unit who shared a pretty neat trick on how to get latest NSX-T 3.0 release to work with a Ryzen-based CPU.

Disclaimer: This is not officially supported by VMware. The behaviors described here can change in the future

First off, I want to thank Andrea for sharing but also credit to Beniamino Guarnaschelli and his blog post here which actually gave Andrea the idea to take a closer look as he was trying to get this setup in his own personal homelab.

NSX-T Edge OVF property to automatically join NSX-T Management Plane

04/20/2020 by William Lam 2 Comments

After publishing my vSphere 7 with Kubernetes automation lab deployment script, I was looking at my NSX-T Edge code which leverages the vSphere VM Keystroke API to automate the joining of the the NSX-T Edge to the NSX-T Management Plane. This technique is used to avoid the need for SSH access to both NSX-T Edge and Manager which is the official VMware method as outlined in the documentation for configuring the Edge.

This is certainly unfortunate as most customers normally disable SSH by default and only enable it for troubleshooting/debugging purposes. As far as I know, there are no remote NSX-T APIs for configuring an NSX-T Edge that has been deployed outside of NSX-T Manager, which has its own implications.

I recently had a chance to revisit some research I had made a note of when I had first started working with NSX-T. While inspecting the NSX-T Edge OVA, I found several OVF properties that begin with mp which per the description was referring to the NSX-T Manager. At the time, I was not able to figure out which the required combination of keys and values. Taking a closer look and poking around the appliance and logs, I was able to finally figure out the correct combination which turned out to be easy, once you knew what it was expecting.

To help demonstrate this functionality, I have created a basic PowerCLI script edge-auto-join-nsxt-management-plane.ps1 which uses information from your already deployed NSX-T Manager to automatically deploy the desired number of NSX-T Edge(s) which will automatically join the NSX-T Management Plane upon initial setup.

The way this works is that the following four OVF properties must be filled as part of the NSX-T Edge deployment:

Automated vSphere 7 and vSphere with Kubernetes Lab Deployment Script

04/13/2020 by William Lam 90 Comments

I know many of you have been asking me about my vSphere with Kubernetes automation script which I had been sharing snippets of on Twitter. For the past couple of weeks, I have been hard at work making the required changes between the vSphere 7 Beta and GA workflows, some additional testing and of course documentation. Hopefully the wait was worth it (I think it is) and if you enjoy the script or have benefited, please consider adding 🌟to the Github repo to show your support! Thanks and enjoy

Had to make some updates to one of my vGhetto Automated Lab Deployment Scripts

💥44min to automate all required #vSphere7 infrastructure! 🤛🎤🥳

1 x VCSA 7.0
3 x ESXi + vSAN 7.0
1 x NSX-T 3.0 UA
1 x NSX-T Edge

Need to clean up #ProjectPacific wording but its working great! pic.twitter.com/ZInPgVgbGS

— William Lam (@lamw) April 4, 2020

The Github repository:

https://github.com/lamw/vghetto-vsphere-with-kubernetes-external-nsxt-automated-lab-deployment

Before getting started, please carefully read through the requirements section along with the complete sample end-to-end execution if you are new to vSphere with Kubernetes. You will need to have a VMware Cloud Foundation (VCF) 4.0 license before you can get started and specifically an NSX-T Advance license which is one of the required parameters within the script. If you do not have access to a VCF 4 license, I strongly recommend taking part in the recent VMUG Advantage Homelab Group Buy effort which I had started to easily get access to the latest VMware releases along with a nice 15% discount!

The script supports deploying both a standard vSphere 7 environment with just VCSA, ESXi and vSAN as well as the complete solution which includes NSX-T to support vSphere with Kubernetes. For more details, please refer to the FAQ.

Automating the creation of NSX-T “Disconnected” Segments for DR testing on VMware Cloud on AWS

03/05/2020 by William Lam 1 Comment

Disaster Recovery (DR) and Disaster Avoidance (DA) on VMware Cloud on AWS is still one of the most popular use case amongst our customers, just second to Datacenter Migration and Evacuation. The VMware Site Recovery service makes it extremely easy and cost effective for customers to protect their critical workloads without having to worry about the underlying infrastructure. Most often, the biggest cost of having a dedicated DR site is the on-going operational and maintenance cost of that infrastructure.

Most recently I have seen several requests come in where customers were looking to streamline their DR testing which is fantastic to hear. Just having a DR solution is not enough, you actually need to exercise it and verify that your workloads and applications are functioning as expected. Today, customers can verify that their applications are functioning as expected by creating NSX-T network segments that are "Disconnected" and then using a VM-based router to provide internal connectivity between these isolated environments.

Here is a screenshot of the VMware Cloud console and under the Networking & Security tab, when creating a new segment you can specify whether the segment is "Connected" (Routed) or "Disconnected".

Obviously, the NSX-T UI is just one way of creating a segment. In fact, most customers that have asked about this is wanting to do this via Automation which not only brings speed to testing but also consistency! With that, I have updated my NSX-T PowerShell Community Module for VMC to include two new updates. If you have never used this VMC module before, please take a look at the Getting Started guide here.

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

01/07/2020 by William Lam 26 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!