Heads up! Watch your NIC order when adding more hosts to VCF

VMware Cloud Foundation is a unified SDDC platform for the hybrid cloud. It is based on VMware’s compute, storage, and network virtualization.

VCF can be expanded with more workload domains by adding further hosts, or it can be stretched over two availability zones (AZ). The expansion is initiated by and under control of the SDDC-Manager. The procedure is fairly straightforward and SDDC-Manger does all the configuration tasks in the background, i.e. forming vSAN clusters, networks, kernel ports, vCenters and NSX control planes.

  • setup hosts with ESXi base image
  • confige a management IP address
  • set root credentials
  • configure DNS and NTP
  • import new hosts into SDDC-Manager
  • deploy new WLD

There is a pitfall that can be easily overseen: The order of the new host’s NICs. Before we can import new hosts, we’ll get to see a checklist about the host requirements. The hosts need to have two NICs with at least 10 GBit.

While reading the list there’s a little detail that is often overlooked. Traditional numbering means that both NICs must have numbers vmnic0 and vmnic1. Unfortunately this seems to be hard coded and cannot be changed (as of current version 4.2). To make matters worse, many server systems have onboard 1 GBit network adapters. There’s a KB article that explains how VMware ESXi determines the order in which names are assigned to network devices. It’ll start with onboard NICs and then continues with PCIe cards. As a result you’ll might end up with two 1 GBit onboard NICs as vmnic0 and vmnic1. In this case the bringup of the VCF expansion will fail.

While you can choose NICs during initial VCF bringup, this is not possible during expansion and this time there’s no such thing as a bringup sheet. You can’t select more than two NICs either when using SDDC-Manager. In that case you’ll need to use API-calls.

Workaround

Currently there’s no other way than to disable onboard NICs in the system BIOS. If your desired NICs still show a higher number you’ll need to put the PCIe card into a lane with lower number.

Reset and re-use VCF 4 Cloud Builder Appliance

As part of a VMware Cloud Foundation (VCF) greenfield deployment, the Cloud Builder appliance is used for one-time use. It automatically deploys the management infrastructure of a VCF cluster and can be discarded afterwards.

The ideal situation is that the previously created workbook or JSON is processed and the cluster is successfully created.

In the UI of the Cloud Builder, however, there is no option to reset the wizard and restart it from zero. For example, when requirements have changed and a new or adapted workbook is to be used. Or you want to use the appliance for another rollout. In this case, the appliance would have to be completely redeployed. Any errors in the JSON file cannot be corrected this way either.

However, there is a trick to reset the Cloud Builder to zero and feed it with a modified JSON file. This is thanks to an API call that may have been ‘forgotten’ during development. In order to do so, we have to log in to the console of the Cloud Builder as user root.

[Optional] It may be easier to grant the root user temporary SSH access. Log in to the VM console as root and edit the sshd configuration.

sudo vi /etc/ssh/sshd_config

Browse the sshd_config and look for the line PermitRootLogin no. Disable the line by putting a # in front of it.

# PermitRootLogin no

Save the configuration and open a SSH session as user root. We now can execute an API call as user root.

curl -X GET http://localhost:9080/bringup-app/bringup/sddcs/test/deleteAll

Login to the web UI of the Cloud Builder appliance. You now can start from the beginning.

Links

VMware Cloud Platform Tech Zone – Re-use Cloud Builder for Another Deployment

vSphere with Kubernetes

What’s new in v7U1?

VMware will release vSphere 7 Update 1 shortly. Once update 1 is released users will be able to run Kubernetes workloads natively on vSphere. So far that was only possible for installations with VMware Cloud Foundation 4 (VCF). Beginning with update 1 there will be two kinds of Kubernetes on vSphere:

  • VCF with Tanzu
  • vSphere with Tanzu

VCF offers the full stack but has some constraints regarding your choices. For example VCF requires vSAN as storage and NSX-T networking. NSX-T offers loadbalancer functionality for the supervisor cluster and Tanzu Kubernetes Grid (TKG). Additionally it provides overlay networks for PodVMs. These are container pods that can run on the hypervisor by means of a micro-VM.

In contrast to VCF with Tanzu, vSphere with Tanzu has less constraints. There’s no requirement to utilize vSAN as storage layer and also NSX-T is optional. Networking can be done with normal distributed switches (vDS). It’s possible to use HA-proxy as loadbalancer for supervisor control plane API and TKG cluster API. The downside of this freedom comes with reduced functionality. Without NSX-T it is not possible to run PodVMs. Without PodVMs you cannot use Harbor Image Registry, which relies on PodVMs. In other words: if you want to use Harbor Image Registry together with vSphere with Tanzu, you have to deploy NSX-T.

VCF with TanzuvSphere with Tanzu
NSX-Trequiredoptional, vDS
vSANrequiredoptional
PodVMsyesonly with NSX-T
Harbor Registryyesonly with PodVM, NSX-T
LoadbalancerNSX-THA-proxy
CNICalicoAntrea or Calico
Overlay NWNSX-T

Tanzu Editions

In the future there will be 4 editions of vSphere with Tanzu:

  • Tanzu Basic – Run basic Kubernetes-clusters in vSphere. Available as license bundle together with vSphere7 EnterprisePlus.
  • Tanzu Standard – Same as Tanzu Basic but with multi cloud support. Addon license for vSphere7 or VCF.
  • Tanzu Advanced – Available later.
  • Tanzu Enterprise – Available later.

Links

vSphere Blog – What’s New with VMware vSphere 7 Update 1

vSphere Blog – Announcing VMware vSphere with Tanzu

Cormac Hogan – Getting started with vSphere with Tanzu

VMware Tanzu – Simplify Your Approach to Application Modernization with 4 Simple Editions for the Tanzu Portfolio

Announcement of VMware Cloud Foundation 4.1

Together with vSphere7 and vSAN7, VMware Cloud Foundation (VCF) 4.0 with Tanzu was released in March this year. Now VMware has announced VMware Cloud Foundation 4.1 along with vSphere 7.0 Update1 and vSAN 7 U1, which builds on some of the new features of vSAN.

What’s new?

  • vSAN Data Persistence Platform – This is an important feature for manufacturers of virtual appliances and container solutions that run on vSAN or VCF. Not all Container workloads are stateless. Some of them like object storage or NoSQL are stateful applications. Until now, separate replication mechanisms by the application were necessary. With vSAN Persistence Platform the providers are able to directly use the high availability of vSAN. First providers are for example MinIO, DataStax, Dell EMC ObjectScale or Cloudian.
  • VMware Cloud Foundation Remote Clusters – A feature based on vSAN HCI Mesh. With this feature vSAN Datastores of other clusters can be integrated. This is especially interesting for remote locations.
  • vVols in workload domains – Now you can deploy workload domains on vVol enabled storage. Supported protocols are FC, iSCSI and NFS.
  • Automatic deployment of vRealize Suite 8.1 – vRealize Suite Life Cycle Manager (vRSLCM) now integrates with SDDC manager. You can deploy and update vRealize products from vRSLCM.
  • New features and bugfixes in SDDC manager.
  • VMware Skyline support for VCF.

The update is expected in early October during or shortly after VMworld2020.