virten.net

Shared Service Engine Groups in VMware Cloud Director with NSX Advanced Load Balancer

by Florian Grehl
October 26, 2021
1 Comment

In the Getting Started with NSX Advanced Load Balancer Integration in VMware Cloud Director 10.3 Guide, I've explained how to enable "Load Balancing as a Service" in VCD with dedicated Service Engines. With this Service Engine deployment model, each Edge Gateway is statically assigned to a dedicated NSX-ALB Service Engine Group. That means, for each EGW you create in VCD, you have to create a Service Engine Groups, which consists of multiple Service Engines (Virtual Machines).

Service Engine Groups can also be deployed in a shared model. Shared Service Engine groups can be assigned to multiple Edge Gateways. In this deployment model, a single Service Engine (Virtual Machine) can handle traffic for multiple customers. For obvious security reasons, and to prevent problems with overlapping networks, VRFs are used inside the SE to fully separate the data traffic.

This article explains how to use Shared Service Engine Groups in VMware Cloud Director 10.3.

Getting Started with NSX Advanced Load Balancer Integration in VMware Cloud Director 10.3

by Florian Grehl
October 24, 2021October 26, 2021

When you are using NSX-T as network backend for VMware Cloud Director, you can't use the Native Load Balancer included in NSX-T. Since Cloud Director 10.2, the NSX Advanced Loadbalancer (ALB), previously known as AVI Vantage Platform, has been integrated to allow customers to create Self-Service Load Balancers.

This article explains all steps required to integrate NSX ALB into VMware Cloud Director.

Windows 11 on VMware ESXi - This PC can't run Windows 11

by Florian Grehl
October 17, 2021October 23, 2021
2 Comments

The latest release of Windows 11 requires a Trusted Platform Module (TPM) 2.0 chip. When you try to install Windows 11 as a Virtual Machine on VMware ESXi, the installation fails with a "This PC can't run Windows 11" error. There is no further information on why the setup fails.

By using SHIFT + F10 and notepad x:\windows\panther\setuperr.log or type x:\windows\panther\setuperr.log, you can verify that the reason for the failed setup is a missing TPM Chip:

This article explains two options to install Windows 11 by either disabling the TPM check, or by adding a Virtual Trusted Platform Module (vTPM) to the Virtual Machine.

ESXi on ASRock Industrial NUC 1100 Series (11th Gen Intel "Tiger Lake" CPU)

by Florian Grehl
October 13, 2021

ASRock Industrial has a NUC-like small form factor (SFF) system in their portfolio, which is very similar to Intel's latest 11th Gen NUC Series. With the global shortage of microchips the availability of 11th Gen NUCs, especially the Dual-NIC "Pro" models, is still limited. While looking for alternatives, the ASRock Industrial NUC1100 Series came out as a great alternative to the original NUC Series.

SFF systems (also known as Barebone, Nettop, SoC, or Mini-PC) like Intel's or ASRocks's NUC are not officially supported by VMware but they are very widespread in the homelab community. They are small, silent, transportable, and have very low power consumption, making them great servers in your homelab. The ASRock 1100 Series is available with i3, i5, or i7 CPU and supports up to 64GB of Memory. All models are equipped with two Network adapters, one with 1 Gigabit and a second adapter with 2.5 Gigabit support. Both adapters can be used with the latest VMware ESXi 7.0.

NUC BOX-1165G7 (Intel Core i7-1165G7 - 4 Core, up to 4.7 GHz)
NUC BOX-1135G7 (Intel Core i5-1135G7 - 4 Core, up to 4.2 GHz)
NUC BOX-1115G4 (Intel Core i3-1115G4 - 2 Core, up to 4.1 GHz)

Will ESXi run on the ASRock Industrial NUC 1100 Series?
Yes. It is possible to install ESXi. Due to missing i219V and i225LM drivers in the original image, it is required to create a custom Image using a community-created driver. Instructions on how to create the Image are included in this article. This problem is not specific to ASRock's 11th Gen. The custom image is also required for Intel's 11th Gen NUC and some older models.

Installing or removing packages fails with "BOOTx64.EFI not found" error - ESXi 7.0

by Florian Grehl
October 6, 2021

While preparing my ESXi Hosts for the recently released ESXi 7.0 Update 3, I came across a strange issue. When I try to install or remove any packages using esxcli, the update failed with the following error message:

[KeyError]
"filename 'var/db/payloads/boot_loader_efi/BOOTx64.EFI' not found"
Please refer to the log file for more details.

Any updates using Update Manager / Lifecycle Manager did also fail. ESXi was running at 7.0.2 build-17867351, which correlates to ESXi 7.0 Update 2a. Using "esxcli software profile list" reveals that this was a fresh installation and no packages have been updated yet. The image was customized by adding the vmkusb-nic-fling using PowerCLI Image Builder. After some troubleshooting, I was able to reproduce the Issue which helped me to identify the root cause and I also found a solution to make updates functional again.

vCenter 7.0 Update Issues

by Florian Grehl
October 5, 2021
4 Comments

Patching the vCenter Server Appliance in vSphere 7.0 has become a lucky bag. When you try to update using the vCenters VAMI, you either have greyed out STAGE ONLY and STAGE AND INSTALL buttons:

The installation fails with "Exception occurred in install precheck phase" errors, rendering the VAMI unusable:

Or the installation gets stuck on Downloading RPM vsphere-ui-[version].rpm:

Direct Org Network to TKC Network Communication in Cloud Director 10.2

by Florian Grehl
May 18, 2021

Since VMware has introduced vSphere with Tanzu support in VMware Cloud Director 10.2, I'm struggling to find a proper way to implement a solution that allows customers bidirectional communication between Virtual Machines and Pods. In earlier Kubernetes implementations using Container Service Extension (CSE) "Native Cluster", workers and the control plane were directly placed in Organization networks. Communication between Pods and Virtual Machines was quite easy, even if they were placed in different subnets because they could be routed through the Tier1 Gateway.

With Tanzu meeting VMware Cloud Director, Kubernetes Clusters have their own Tier1 Gateway. While it would be technically possible to implement routing between Tanzu and VCD Tier1s through Tier0, the typical Cloud Director Org Network is hidden behind a NAT. There is just no way to prevent overlapping networks when advertising Tier1 Routers to the upstream Tier0. The following diagram shows the VCD networking with Tanzu enabled.

With Cloud Director 10.2.2, VMware further optimized the implementation by automatically setting up Firewall Rules on the TKC Tier1 to only allow the tenants Org Networks to access Kubernetes services. They also published a guide on how customers could NAT their public IP addresses to TKC Ingress addressed to make them accessible from the Internet. The method is described here (see Publish Kubernetes Services using VCD Org Networks). Unfortunately, the need to communicate from Pods to Virtual Machines in VCD seems still not to be in VMware's scope.

While developing a decent solution by using Kubernetes Endpoints, I came up with a questionable workaround. While I highly doubt that these methods are supported and useful in production, I still want to share them, to show what actually could be possible.

Access Org Network Services from TKC Guest Cluster in VMware Cloud Director with Tanzu

by Florian Grehl
May 17, 2021May 18, 2021
2 Comments

Many applications running in container platforms still require external resources like databases. In the last article, I've explained how to access TKC resources from VMware Cloud Director Tenant Org Networks. In This article, I'm going to explain how to access a database running on a Virtual Machine in VMware Cloud Director from a Tanzu Kubernetes Cluster that was deployed using the latest Cloud Service Extension (CSE) in VMware Cloud Director 10.2.

If you are not familiar with the vSphere with Tanzu integration in VMware Cloud Director, the following diagram shows the communication. I have a single Org VCD that has a MySQL Server running in an Org network. When leaving the Org Network, the private IP address is translated (SNAT) to an public IP from the VCD external network (203.0.113.0/24). The Customer also has a Tanzu Kubernetes Cluster (TKC) deployed using VMware Cloud Director. This creates another Tier1 Gateway, which is connected to the same upstream Tier0 Router. When the TKC communicates, it is also translated on the Tier 1 using an address from the Egress Pool (10.99.200.0/24).

So, both Networks can not communicate with each other directly. As of VMware Cloud Director 10.2.2, communication is only implemented to work in one direction - Org Network -> TKC. This is done using automatically configuring a SNAT on the Org T1 to its primary public address. With this address, the Org Network can reach all Kubernetes services that are exposed using an address from the Ingress Pool, which is the default when exposing services in TKC.

VMware Cloud Director 10.2.2 and vSphere with Tanzu Enhancements

by Florian Grehl
May 14, 2021
2 Comments

VMware Cloud Director 10.2.2 brings a couple of enhancements to the vSphere with Tanzu integration. While we are still waiting for VRF support in vSphere with Tanzu to fully separate Supervisor Namespaces, the implementation introduced in VCD 10.2.2 should be valid for production workloads.

This article explains new features and issues I had during the implementation:

VCD with Supervisor Control Plane communication
Tanzu Certificate Issues
Tanzu Kubernetes Cluster Tenant Network Isolation
Publish Kubernetes Services using VCD Org Networks