Three weeks after releasing patches for a critical vulnerability in VMware vCenter, thousands of servers that are reachable from the internet remain vulnerable to attacks. VMware vCenter is used by enterprises to manage virtual machines, the VMware vSphere cloud virtualization solution, ESXi hypervisors, and other virtualized infrastructure components.

Remote code execution and authentication bypass
On May 25, VMware published a critical advisory and released patches covering two serious vulnerabilities that stem from the use of VMware vCenter plug-ins. The first vulnerability, tracked as CVE-2021-21985, is caused by improper input validation in the Virtual SAN (vSAN) Health Check plug-in that’s enabled by default in vCenter Server.

VMware vSAN is used for storage virtualization, but even if the plug-in is not actively used, the presence of the plug-in on the server is enough to enable attacks. A hacker with access to the server over port 443 (HTTPS) can exploit this issue without authentication to execute commands with unrestricted privileges on the operating system that hosts vCenter Server versions 6.5, 6.7 and 7.0, as well as VMware Cloud Foundation 3.x and 4.x, which include vCenter Server.

The second vulnerability, tracked as CVE-2021-21986, is rated as medium severity and impacts the Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager and VMware Cloud Director Availability plug-ins. Attackers with access to a server over port 443 can perform actions allowed by the affected plug-ins without authentication.

Publicly exposed VMware servers
Researchers from security firm Trustwave recently performed a scan using SHODAN and identified 5,271 instances of VMware vCenter Server that are configured to be accessible from the internet. The vast majority of them (5,076) operate over port 443.

The researchers managed to connect to 4,969 of those servers and download information from their greeting banner, which includes more details about the specific version of the server such as build number and underlying operating system. The collected information revealed that 4,019, or 80.88%, of the scanned servers had not yet been patched for these flaws and that most of the remaining ones are running much older versions of the software that are considered end-of-life and are likely vulnerable to a variety of older issues.

If the ratio of unpatched servers is so high among publicly accessible servers, which are generally easier to attack and should be carefully monitored, it’s fair to assume that many vCenter Servers remain unpatched on private networks. However, attackers have many ways of gaining access to corporate networks, so attacking such servers would not be hard.

Proof-of-concept exploits and urgent need to patch
Since the patches were released in May, security researchers have developed and published proof-of-concept exploits for these issues, so potential attackers don’t have to spend much effort to start exploiting these issues in the wild. VMware warned users from the start that these vulnerabilities need to be patched as soon as possible and even published manual workarounds that involve editing the compatibility-matrix.xml file to disable the vulnerable plug-ins.

“If you ARE a vSAN customer, disabling the vSAN plugin will remove all ability to manage vSAN,” VMware said in a blog post. “No monitoring, no management, no alarms, nothing. This might be fine for your organization for very short periods of time but we at VMware cannot recommend it. Please use caution.”

“In this era of ransomware it is safest to assume that an attacker is already inside the network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible,” the company said.

Overview

In October 2020, Dell Technologies announced a broad set of integrations and enhancements designed to deepen its support for VMware environments. The announcements coincided with VMware’s release of updated versions of vSphere, vSAN, and VMware Cloud Foundation (VCF) — all extended to support VMware Tanzu, VMware’s portfolio for running Kubernetes workloads on vSphere infrastructure.

Jeff Boudreau, President and General Manager of the Infrastructure Solutions Group at Dell Technologies, framed the initiative around multi-cloud complexity: “Customers looking to accelerate their digital transformation need trusted, proven solutions that can help them navigate today’s multi-cloud landscape while managing their IT and business needs. Dell Technologies and VMware are raising the bar with tightly integrated solutions, designed to help customers and partners better manage and protect traditional and modern applications.”

What Was Announced

Dell extended VMware support across multiple product lines in its infrastructure portfolio:

• Dell Technologies Cloud — hybrid cloud platform updated to support VCF and Tanzu
• Dell EMC VxRail — hyperconverged infrastructure (HCI) system jointly engineered with VMware
• Dell EMC PowerProtect — data protection platform with VMware environment support
• Dell EMC PowerEdge — server line validated for updated vSphere and Tanzu deployments

VxRail and VMware Tanzu Integration

A centerpiece of the announcement was VxRail’s integration with vSphere with Tanzu. Dell positions VxRail as the only HCI system jointly engineered with VMware, and at the time of the announcement, it was described as the first system to be fully integrated with vSphere with Tanzu. This integration was designed to enable:

• Rapid Kubernetes adoption without the need to manage separate infrastructure layers
• Automated deployment and provisioning of containerized workloads
• A single management plane for both virtual machines and containers

For organizations not yet ready for a full HCI approach, Dell also offered validated architecture options and the Dell Technologies Cloud Platform as alternative on-ramps to running Tanzu workloads.

Dell Technologies Cloud Platform: Subscription Pricing and Deployment Speed

Dell introduced subscription-based pricing for the Dell Technologies Cloud Platform to lower the barrier to hybrid cloud adoption with Tanzu. Key claims from the announcement included:

• Starting price of $70 per node, per day — designed to eliminate large upfront capital expenditure
• Initial deployment in as few as 14 days
• Capacity expansion in as few as five days

The subscription model shifts cost from a capital expense (CapEx) to an operational expense (OpEx) model, which can simplify budgeting and reduce forecasting risk — a recurring theme in enterprise IT procurement at the time.

Storage and Application Management

Beyond compute and HCI, Dell also highlighted storage innovations aimed at simplifying how organizations manage both traditional (VM-based) and modern (container-based) applications within VMware environments. Specific storage product updates were not enumerated in the original source material.

VMware’s Perspective

Lee Caswell, Vice President of Marketing for the Cloud Platforms Business Unit at VMware, commented on the partnership: “VMware and Dell Technologies, together, are delivering solutions that help customers manage traditional and modern applications, whether they reside in a traditional data center, at the edge or in clouds. Today’s announcements from Dell Technologies are the latest examples of the tight integration between our teams, and the benefits our customers see as a result.”

Why This Matters for Infrastructure and DevOps Teams

For platform engineers and DevOps teams operating on-premises or in hybrid environments, the Dell–VMware integration points raised at the time remain relevant context for understanding how enterprise Kubernetes adoption has evolved:

• vSphere with Tanzu allows teams to provision Kubernetes namespaces directly through vCenter, reducing the need to maintain separate Kubernetes clusters outside the existing VMware estate.
• HCI-based Kubernetes (via VxRail) reduces the infrastructure operations burden by converging compute, storage, and networking into a single, jointly supported stack.
• Subscription models for cloud platform hardware make it easier to scale Kubernetes node counts without long procurement cycles.

These patterns — converged infrastructure, subscription consumption, and integrated Kubernetes — have since become mainstream in enterprise platform engineering and remain relevant considerations when evaluating on-premises Kubernetes strategies.

This article is based on Dell Technologies and VMware press materials from October 2020. Product capabilities, pricing, and availability may have changed since publication. Consult current Dell Technologies and VMware documentation for up-to-date specifications.

What Is HCI and Why Automate It?

Hyper-Converged Infrastructure (HCI) collapses traditional three-tier data-centre architecture — separate compute, storage, and networking layers — into a single, software-defined building block. By pooling commodity x86 servers running VMware vSphere and vSAN, organisations can scale out storage and compute together, reduce cabling complexity, and manage the entire stack through a single pane of glass.

Despite its operational simplicity at runtime, initial deployment of an HCI stack can still be tedious and error-prone when performed manually. Applying DevOps principles — infrastructure-as-code, idempotent configuration management, and continuous validation — to the bring-up process eliminates configuration drift, accelerates time-to-production, and makes the environment fully reproducible.

The VMware SDDC Stack in Focus

The automation approach described in the original VMware blog post targets a full Software-Defined Data Centre (SDDC) stack composed of four main products:

• VMware vSphere (ESXi + vCenter Server) — the compute and hypervisor layer that hosts all workloads.
• VMware vSAN — software-defined storage distributed across vSphere hosts, eliminating the need for external SANs or NAS.
• VMware NSX — software-defined networking and security, providing micro-segmentation, logical switching, routing, and load balancing independent of physical hardware.
• VMware Integrated OpenStack (VIO) — an enterprise-supported OpenStack distribution that sits on top of vSphere and NSX, exposing a standard OpenStack API surface for tenant self-service.

Together these components form an HCI platform capable of running both traditional VM workloads and cloud-native tenant environments, all on the same converged hardware.

Applying DevOps Principles to HCI Bring-Up

A DevOps-style deployment pipeline for this stack typically involves several stages, each automated and version-controlled:

1. Infrastructure-as-Code for Configuration

All cluster parameters — host IP addresses, vSAN disk groups, NSX controller counts, VIO sizing — are captured in declarative configuration files (for example, YAML or JSON). This means every environment, from a lab proof-of-concept to a production cluster, is described in source control and can be peer-reviewed before deployment begins.

2. Scripted Deployment with VMware APIs

VMware exposes rich APIs across its product portfolio — the vSphere API (accessible via PowerCLI or the vSphere SDKs), the NSX REST API, and the VIO management API. Automation tooling can chain calls to these APIs to:

• Configure ESXi hosts, vCenter clusters, and HA/DRS settings.
• Claim vSAN capacity and cache disk groups and verify the vSAN health checks pass.
• Deploy NSX Manager, register it with vCenter, and provision controllers and transport zones.
• Bootstrap VIO, connect it to the vSphere and NSX backends, and validate the OpenStack services come up healthy.

3. Idempotency and Validation Gates

Each automation step should be idempotent — running it a second time should produce the same outcome without creating duplicate objects or failing with errors. After each major phase (vSphere cluster ready, vSAN healthy, NSX control plane up, VIO services active), automated validation tests confirm the expected state before the pipeline advances. Failures at any gate halt the pipeline and surface a clear error, rather than allowing a misconfigured component to propagate into later stages.

4. Version-Controlled and Repeatable

Because the entire bring-up procedure lives in a version-controlled repository, teams can:

• Reproduce the exact same environment in a new data centre or a disaster-recovery site.
• Roll back to a known-good configuration definition if a change introduces problems.
• Audit exactly what changed between deployments using standard diff and pull-request workflows.

Key Benefits for Operations Teams

• Reduced deployment time: Multi-day manual bring-up processes can be compressed into hours when fully scripted.
• Consistency: Every cluster built by the pipeline is configured identically, removing the variability introduced by different engineers following a run-book.
• Self-documenting infrastructure: The configuration files and pipeline code serve as living documentation of the environment’s intended state.
• Faster recovery: If a cluster must be rebuilt, the same pipeline re-creates it to spec without relying on tribal knowledge.
• Compliance-friendly: Change history is captured in Git; automated validation gates can enforce security baselines at deploy time.

Tooling Considerations

Common tooling choices for automating this type of VMware SDDC stack include:

• PowerCLI — VMware’s PowerShell module for vSphere automation, well suited for cluster configuration and vSAN management tasks.
• Ansible — agentless automation that can orchestrate multi-product workflows using VMware and NSX modules from Ansible Galaxy.
• Terraform — the VMware vSphere provider can manage vCenter objects declaratively; NSX-T also has a Terraform provider.
• Python with the vSphere Automation SDK — useful for custom tooling or integrating with existing CI/CD pipelines.
• CI/CD platforms (Jenkins, GitLab CI, etc.) — orchestrate pipeline stages, enforce gate checks, and provide audit trails.

Further Reading

For the full implementation walkthrough, scripts, and architecture diagrams, refer to the original VMware Virtual Blocks blog post:

HCI Automated Deployment & Configuration: vSphere, vSAN, NSX, VIO The DevOps Way — VMware Virtual Blocks Blog