Cluster Retreat Mode gone wrong – vSphere Client lockout

With the release of vSphere 7.0 Update 1, vSphere Cluster Services VMs (vCLS) appeared in vSphere clusters for the first time. This made cluster functions such as Distributed Resource Scheduler (DRS) and others independent of the availability of the vCenter Server Appliance (VCSA) for the first time. The latter still represents a single point of failure in the cluster. By outsourcing the DRS function to the redundant vCLS machines, a higher degree of resilience has been achieved.

Retreat Mode

The vSphere administrator has little influence on the provisioning of these VMs. Occasionally, however, it is necessary to remove these VMs from a datastore if it is to be put into maintenance mode, for example. There is a procedure for setting the cluster to retreat mode. This involves setting temporary advanced settings that lead to the deletion of the vCLS VMs by the cluster.

According to the VMware procedure, the Domain ID must be determined to activate Retreat Mode. The domain ID is the numerical value between ‘domain-c’ and the following colon. In the example from my lab, it has the value 8, but the number can also have four digits or more.

The domain ID has to be transferred to the Advanced Settings of the vCenter.

config.vcls.clusters.domain-c8.enabled = false
Correct Retreat Mode settings.

Admin error occured during activation of retreat mode.

After activating retreat mode on a vSAN cluster, administrators had lost all privileges to all objects in the vSphere Client.

A review of the services showed that the vCenter Server Daemon (vpxd) was not running.

Continue reading “Cluster Retreat Mode gone wrong – vSphere Client lockout”

Project Arctic – Delivering Benefits of the Cloud to On-Prem Workloads

In the last few years we’ve seen a clear trend to adopt cloud strategies on customer side. Some already pusue a multi cloud strategy to get the most benefit from different offerings. But we may not forget, that infrastructure on-premises – the so called private cloud – is still the most common kind of virtual infrastructure. This is no surprise because on-premises infrastructure has without doubt some advantages. It’s not alone aspects of data privacy, data security and data sovereignty. There are also performance aspects such as low latency that keep customers from migration special workloads to the (public) cloud.

On the other hand there are some advantages of cloud offerings too. Such as flexible consumption, minimal maintenance, built in resilience, developer agility and the possibility to manage from anywhere.

To bridge the gap between on-premises needs and cloud based offerings, VMware has announced Project Arctic during VMworld 2021. Delivering benefits of the cloud to on-premises workloads.

Introducing vSphere+ and vSAN+

Continue reading “Project Arctic – Delivering Benefits of the Cloud to On-Prem Workloads”

vCenter Server 7.0 Update 3e released

VMware has released a patch update 3e for vCenter. This is a maintenance release and primarily adds updates for vSphere with Tanzu. There are also separate release notes for vSphere with Tanzu.

What’s New?

  • Added Network Security Policy support for VMs deployed via VM operator service – Security Policies on NSX-T can be created via Security Groups based on Tags. It is now possible to create NSX-T based security policy and apply it to VMs deployed through VM operator based on NSX-T tags.
  • Supervisor Clusters Support Kubernetes 1.22 – This release adds the support of Kubernetes 1.22 and drops the support for Kubernetes 1.19. The supported versions of Kubernetes in this release are 1.22, 1.21, and 1.20. Supervisor Clusters running on Kubernetes version 1.19 will be auto-upgraded to version 1.20 to ensure that all your Supervisor Clusters are running on the supported versions of Kubernetes.

Check before update

If you upgraded vCenter Server from a version prior to 7.0 Update 3c and your Supervisor Cluster is on Kubernetes 1.9.x, the tkg-controller-manager pods go into a CrashLoopBackOff state, rendering the guest clusters unmanageable

Read KB 88443 for a workaround.

Test K8s Version

Make sure you’re on a supported K8s version.

Menu > Workload Management > Subervisor Clusters

The image above indicates we’re already on version 1.21, which is good for an update.

Update

Before updating your VCSA make sure you have a configuration backup! An optional VM snapshot is a good idea too. It might help to revert settings fast in case something goes wrong.

You can either apply the update from VAMI or from the shell. The image below shows an overview of the new packages with this update.

After the update is installed you will have an option to deploy a new Kubernetes version in your Supervisor Control Plane.

VMware vSphere 7.0 U3c released

What happened to vSphere 7.0 U3 ?

vSphere 7.0 Update 3 was initially released on October 5, 2021. Shortly after release, there were a number of issues reported by customers, so on November 18, 2021, all ESXi versions 7.0 U3a, U3b, U3c, as well as vCenter 7.0 U3b were withdrawn from VMware’s download area. VMware explains details of the issue in KB 86191.

The main reason was a duplicate driver i40en and i40enu for Intel 10 GBit NICs X710 and X722 in the system. A check on the CLI returns a result quickly. Only one result may be returned here.

esxcli software vib list | grep -i i40
one result good – two results bad 😉

Hosts with both drivers will potentially have HA issues when updating to U3c, as well as issues with NSX.

What’s new with Update 3c ?

On 27 January 2022 ( 28 January 2022 CET) the new Update 3c was released and is available for download. Besides fixing the issues from previous Update 3 versions (KB 86191), the main feature is the fix for the Apache Log4j vulnerability (VMSA-2021-0028.10).

All users and customers who had installed one of the withdrawn updates 3 at an early stage are highly recommended to update to version U3c.

Continue reading “VMware vSphere 7.0 U3c released”