NSX

Configure NSX-T Edge to run on AMD Ryzen CPU

05/06/2020 by William Lam 1 Comment

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 56 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 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!

Simulating the VMware Cloud on AWS API using Stoplight Prism Tool

01/06/2020 by William Lam Leave a Comment

As more customers and partners on-board the VMware Cloud on AWS service, the topic of Automation has been coming up more frequently. There are a number of resources that are available to help users get started including here, here, here, here and here to just name a few.

Customers and partners can spin up 1-Node SDDC which includes the full stack (vSphere, vSAN and NSX-T), fully configured and ready for use for less than $8/hour (list price) and start exploring the rich APIs provided by the VMware Cloud on AWS service. Nothing beats playing with the real thing but we definitely have heard from customers and new developers that it would be nice to have the ability to test out some of the Automation prior to running against a real SDDC.

The VMware Cloud APIs is based on OpenAPI (formally Swagger) and has a very rich eco-system of tools that are available to developers and end-users. One really cool thing you can do with OpenAPIs is to "mock" or simulate the APIs just based on your API specification. This is really useful for API development but it can also come in handy for end users to be able to try out your APIs. Prism Mock by Stoplight is an OpenAPI mocking tool that was introduced to me by Jake Robinson.

Over the break, I finally found some time to play with this tool and I think this could be really useful for those wanting to get a taste of the various VMware Cloud APIs. As I have mentioned already, nothing beats the real APIs and there are some limitations with the mocking tool, so you should still consider using the real APIs when you are ready.