Dell Private Cloud First Impressions: Deploying DPC with VMware

What is Dell Private Cloud (DPC)?

Dell Private Cloud (DPC) is a validated, integrated infrastructure platform that combines Dell's compute, storage and networking hardware with leading cloud management software stacks into a pre-engineered, turnkey solution. Rather than requiring organizations to independently source, validate and integrate individual components, Dell Private Cloud delivers a prescriptive architecture designed to simplify deployment and reduce time-to-value.

DPC supports multiple hypervisor and cloud management frameworks, including VMware Cloud Foundation (VCF), Microsoft Azure Local (formerly Azure Stack HCI), Nutanix AHV and Red Hat OpenShift, which allows IT teams to standardize on their preferred operational model while using a consistent, Dell-validated hardware foundation.

The underlying hardware is familiar: Dell PowerEdge nodes for compute, Dell switches for networking and Dell PowerStore or PowerFlex for storage.

What is DPC trying to solve?

Dell Private Cloud directly addresses the core pain points enterprises face with traditional private cloud infrastructure: operational complexity, hyperconverged infrastructure (HCI) cost constraints, vendor lock-in and the growing demand to support AI workloads alongside conventional applications. By automating and streamlining the deployment process, the platform reduces provisioning steps by 90% and can deliver workload-ready clusters in as little as 2.5 hours, cutting the manual overhead of on-premises operations.

Unlike traditional HCI architectures that tightly couple compute and storage, Dell Private Cloud's disaggregated model allows each to scale independently, with Dell claiming up to 65% cost savings over conventional HCI approaches. The platform is also designed to be hypervisor-agnostic, which allows any supported compute node to be used with any validated hypervisor without swapping out any hardware.

Taken together, Dell positions the platform as a "no compromise" solution that delivers the simplicity and automation customers expect from public cloud, while preserving the control, data sovereignty and long-term cost advantages of on-premises infrastructure.

Our DPC lab

World Wide Technology (WWT) and Dell partnered to bring a fully featured, small-scale Dell Private Cloud environment into the WWT Advanced Technology Center (ATC). The solution consists of:

• (5) Dell PowerEdge R670 servers
• (1) Dell PowerStore 1200T storage array
• (2) Dell S5248F-ON top-of-rack Ethernet switches
• (5) Dell Private Cloud server licenses

There are two main ways the DAP controller can be implemented: on-premises or Dell-hosted. We decided to go with the on-premises deployment so we could get the full install experience for a customer with strict on-site requirements. Here are the technical implications of each option:

On-premises (customer-hosted)

The entire solution lives in the customer's own data center. The Dell Automation Platform (DAP), the management layer, can be deployed as a virtual appliance or on a Kubernetes cluster running on-site. The customer owns and operates the physical environment; Dell provides the software stack and lifecycle management tools. If you choose the on-premises deployment, be aware that you must also provide a vSphere cluster to host the DAP controller virtual machines (VMs) that live outside the DPC instance itself. This is worth keeping in mind: you may need to acquire additional servers if your environment does not already include a VMware cluster that can serve this purpose.

SaaS-managed (Dell-hosted control plane)

The compute and storage hardware still sits on-premises, but the management and automation platform is delivered as a SaaS service hosted by Dell. An on-premises proxy/accelerator bridges the customer's infrastructure to Dell's cloud-hosted control plane. This reduces the burden of managing the platform itself while keeping the data and compute local.

Implementation prep

As part of the solution, Dell included its "ProDeploy Dell Private Cloud - VMware with PowerEdge" service. The implementation began with Dell identifying the data and fields we needed to provide so their team could deploy the environment. We used Dell's EPS tool to collect the following:

• Host IPs/subnets/virtual local area networks (VLANs)
• Storage IPs/subnets/VLANs
• Account names and passwords
• Network Time Protocol (NTP) and DNS servers
• Details regarding external vSphere host

Additionally, we worked internally to plan cable runs, rack space and power, and to identify an existing vSphere cluster to host the DPC controller VMs. An important point to note upfront is that you will need participation from your compute, virtualization, network and storage teams, since each of them will contribute to the data-gathering portion of the project.

Implementation walkthrough: DAP deployment

With the data-gathering phase complete, deployment day itself broke down into a few distinct phases.

The Dell Automation Platform orchestrator, the management layer that drives everything, was deployed first, hosted on our existing external vSphere cluster rather than inside the DPC environment itself. It took about 90 minutes to bring the orchestrator fully online and route it through our management network. One prerequisite worth flagging for anyone planning their own deployment: Dell's team needs your support account to be a "full business account," shown as a black checkmark next to your name in the portal, before license entitlements can be pulled during orchestrator setup. Ours was already provisioned correctly, but it's worth verifying ahead of time rather than discovering it mid-deployment.

Implementation walkthrough: VMware cluster deployment

The entire next phase (ESXi imaging across all five R670 nodes, cluster provisioning, PowerStore volume creation and storage integration, and deployment of the Dell Private Cloud Extension) was driven by kicking off the "VMware Cluster Deploy" blueprint offer. In tandem, it kicks off its associated utility blueprints. This is the essential feature of DPC: what would traditionally be a series of separate, manual workflows across compute, virtualization and storage teams runs instead as a single orchestrated sequence.

The blueprint handled ESXi imaging across all five nodes, followed by cluster provisioning and the migration from a standard vSwitch to a distributed vSwitch (VDS). During the latter part of this same blueprint phase, PowerStore volumes were automatically created and iSCSI-mapped to each of the five nodes, another capability built directly into the blueprint for DPC's VMware use case.

In that same window, the blueprint also deployed the Dell Private Cloud Extension itself, a plugin running as its own VM that registers directly into the vSphere Client. Once in place, it gives us per-node hardware visibility (service tags, iDRAC addresses, health, rack location, chassis views) and cluster-level status (cluster identifier, vCenter mode, install date, vSphere Lifecycle Manager (vLCM) status, ESXi version, DPC software version) right inside vCenter, along with dedicated Compliance, Desired State and Updates pages.

PowerStore is managed day-to-day through the Dell Virtual Storage Integrator (VSI) plugin, deployed as its own VM and registered into vCenter. Once deployed, VSI showed both PowerStore volumes as mapped Virtual Machine File System (VMFS) datastores under its Mapped Datastores view, each reporting capacity, free space and health status. VSI also adds its own actions to the cluster's context menu, including Create Datastore, Apply Host Best Practices and Run Space Reclamation. We validated this ourselves by live-expanding a datastore from 4 TB to 5 TB without disruption.

Once the cluster build blueprint completes, you have a fully configured, deployed 5-node vSphere cluster that is ready to manage. This took approximately 2.5 hours once our NTP and secrets issues were resolved.

Implementation walkthrough: vLCM pass

The last major step outside the core blueprint was a vLCM compliance and remediation pass across the cluster, which took about 30 minutes, but only after generating a token through the Broadcom support portal to sync the image depot (a new requirement since Broadcom's VMware licensing changes). This task requires product administrator level access on the Broadcom portal, which meant looping in someone outside the core deployment team to get it done.

With the cluster built and storage connected, we closed out with a quick best-practice check: VMware recommends at least two heartbeat datastores for high availability (HA) to avoid a single point of failure. The blueprint had us running on one, so once our second PowerStore volume was in place, we mapped it as a second heartbeat datastore, a good reminder that even with DPC handling the heavy lifting, it's worth a final pass against your own VMware standards before calling a deployment "done." Finally, we validated call-home connectivity back to Dell's support backend.

A few gotchas worth knowing before you start

• Double-check your support account status (full business account) before deployment day. It gates license entitlement.
• Confirm NTP is correctly configured before ESXi imaging begins. We hit sync issues that caused imaging steps to retry silently, adding time we didn't need to lose.
• Enter credentials carefully during the secrets/locker setup step. Once saved, they're not readable again, and a wrong entry here stalls the whole blueprint run until corrected.
• Budget time to generate a Broadcom portal token before the vLCM step, and know who in your organization has the access required to generate it.

What we explored for Day 2 and demo scenarios

A few weeks after the initial deployment, we sat down with Dell again, this time to think through what a customer-facing demo of DPC's Day 2 capabilities could look like.

The framing that stuck with us most: DPC's value isn't the vSphere cluster you end up with. You could get a vSphere cluster a dozen ways. The value is that how it gets built and managed is identical no matter who deploys it or where, removing the variability that normally comes down to individual engineer experience.

That consistency shows clearly in how node lifecycle is handled. Removing a node from the cluster and repurposing it isn't a manual teardown. It's a single "reclaim node" blueprint that removes the node, cleans up any lingering dependencies in the orchestrator, factory-resets it and drops it back into a free pool, ready for its next job. No stray configuration left behind to trip up the next deployment.

That same free pool is what makes multi-OS flexibility real rather than theoretical. As of our conversation, OpenShift and Nutanix support were both generally available (GA), and Azure Local support followed shortly after; it has been fully supported since June 2026. Standing up an OpenShift cluster needs a minimum of three nodes. We talked through reclaiming a couple of nodes from our live 5-node cluster to test this ourselves, but decided the risk to a running environment we still needed was too high. This is a good reminder that a repurposing demo is far more comfortable with spare nodes than with nodes actively in use.

A couple of boundaries worth being upfront about: PowerStore firmware isn't yet managed through DPC blueprints the way server firmware is. That process still goes through PowerStore's native tools, with blueprint-driven support on Dell's roadmap. Separately, Simple Network Management Protocol (SNMP) on the switches isn't configured by default. If you want monitoring integration, that's a manual step on your end.

Finally, if you ever want to tear the whole thing down and start fresh, whether for re-testing or handing the lab to another team, DPC supports that too. A full reset blueprint wipes the cluster back to its initial state, and redeployment can reuse the exact same configuration by exporting it to JSON the first time around, rather than re-entering everything by hand. One manual step to know about: after a full teardown, leftover host objects can remain in PowerStore and need to be cleaned up there directly. Everything on the vCenter side is handled automatically by the blueprint.

Initial impressions of Dell Private Cloud

Once the implementation concluded, we had a new 5-node ESXi cluster running on Dell servers and storage. Now what can we do with it? DPC's main capabilities fall into two groups:

Day 1

• Automated setup
• Dynamic cluster composition
• Full-stack automation

Day 2

• Integrated management
• Proactive support
• Built-in security
• Graceful workload migration
• Full-stack lifecycle updates
• Drift detection and compliance
• Scalable operations
• Investment protection

Adding, removing and reimaging nodes are all turned into simple blueprints. The most compelling use case we see right now is for customers straddling multiple hypervisors or migrating to a new hypervisor. With a series of blueprints, an existing VMware node could be evacuated of VMs, reimaged with Red Hat OpenShift and added to a cluster, all online and on the exact same hardware.

Who is Dell Private Cloud for?

DPC is an obvious choice for customers who value the automated deployment and lifecycle management of VxRail but want more hypervisor freedom. It also fits customers who want to repurpose resources easily between multiple hypervisors. Finally, DPC is a natural choice for customers who want to fully automate host deployment with validated lifecycle management that is tightly coupled to the hardware.

Final words: Our verdict on Dell Private Cloud

Our first impressions of Dell Private Cloud (DPC) are positive. Once we resolved our NTP and secrets issues, a single blueprint took five PowerEdge R670 servers and a PowerStore array to a fully configured, ready-to-manage 5-node vSphere cluster in about 2.5 hours. What would traditionally be a series of separate, manual workflows across compute, virtualization and storage teams ran instead as one orchestrated sequence.

The cluster itself is not the differentiator, since there are many ways to build a vSphere cluster. The value of DPC is repeatability: the same blueprint-driven process builds, updates and repurposes infrastructure regardless of who runs it or where, which reduces the variability that usually comes down to individual engineer experience. Node reclamation, vLCM compliance and remediation, and teardown and redeployment from an exported JSON configuration all follow that same pattern.

DPC does have boundaries, and technical decision-makers should plan for them. An on-premises deployment requires an existing vSphere cluster outside the DPC instance to host the controller VMs, and a smooth deployment depends on participation from your compute, virtualization, network and storage teams, a properly provisioned Dell support account and someone with the right level of access to the Broadcom support portal. PowerStore firmware is not yet managed through DPC blueprints, SNMP on the switches must be configured manually and a full teardown leaves host objects in PowerStore that need to be cleaned up directly. We recommend raising each of these with Dell and your internal teams early in your evaluation.

We see DPC as the strongest fit for organizations that value the automated deployment and lifecycle management of VxRail but want more hypervisor freedom, that expect to run or migrate between multiple hypervisors or that want fully automated host deployment backed by validated lifecycle management tightly coupled to the hardware. For those customers, the ability to evacuate a VMware node, reimage it for Red Hat OpenShift and return it to a cluster on the same hardware is the use case we find most compelling.

This is only the beginning of our evaluation. Our team is excited to add more compute nodes to the lab and run blueprints with non-VMware hypervisors, such as Red Hat OpenShift, Nutanix AHV and Microsoft Azure Local, to test DPC's functionality more broadly. 

If you are considering DPC or would like to see it in action, contact a WWT expert or your WWT account team to discuss how it might fit your environment.