The name MysticMarvin was always a nod to a platform that made perfect sense back in its time, a blend of EMC’s ‘Mystic’ and VMware’s ‘Marvin’, two code names that eventually converged into what we know as VxRail.”
- Mystic was EMC’s internal project name for what eventually turned into VxBlock.
- Marvin was VMware’s code name for EVO:RAIL, the short-lived hyper-converged appliance that paved the way for VxRail.
Those two worlds merged, and the result became Dell EMC VxRail: hardware engineered to run VMware’s software-defined data center stack. That heritage is why VxRail still sits at the heart of many datacenter strategies today.
Fast forward to 2025, and VxRail is facing another turning point with VCF 9.
From “special integration” to “one platform”
VxRail has its own flavor of VCF. Integration between SDDC Manager and VxRail Manager gave it a slightly different operational model: VxRail Manager looked after cluster creation and hardware upgrades, while SDDC Manager focused on VMware’s software layers.
With VCF 9, that distinction goes away:
- There’s now a single VCF release across all OEM platforms, no separate build just for VxRail.
- VxRail nodes are treated in the same category as vSAN Ready Nodes.
- SDDC Manager no longer talks directly with VxRail Manager for lifecycle tasks.
- Instead, Dell evolves VxRail Manager into a new component, internally referred to as VxRail.next, which focuses on hardware lifecycle and firmware.
In other words: VxRail is moving from a “special case” to being part of the unified VCF model.
How the new VxRail.next works
- A primary Vx0 Manager is deployed in the management domain. This is the only interface administrators will typically use, and it handles orchestration with SDDC Manager.
- Secondary Vx0 Managers are deployed alongside other clusters. They take care of day-to-day node management, upgrades, and firmware tasks.
- The design shifts responsibility: VMware software lifecycle is handled by VCF, while Dell maintains control over the underlying hardware lifecycle.
Paths forward: greenfield vs brownfield
Two main customer journeys are emerging:
-
Fresh deployments (greenfield):
- VxRail with VCF 9 can already be deployed in specific cases, but requires Dell approval.
- The solution is available as part of Dell’s co-engineered portfolio for new installs.
-
Existing systems (brownfield):
- Customers on VCF on VxRail 5.x will need to wait for VCF 9.1 to move forward.
- The migration involves introducing the new Vx0 Manager, switching from vSphere Update Manager (VUM) to vSphere Lifecycle Manager (vLCM), and effectively transforming the cluster into the VxRail.next model.
- This isn’t a simple patch: it’s a structured conversion process that spans VMware and Dell components, and it’s expected to involve Dell professional services.
Guidance for customers
- No more “VxRail-only” builds: With VCF 9, everyone; VxRail, vSAN Ready Nodes, other OEM servers runs on the same VCF release train.
- Prepare for the transition: If you’re still on 5.x, plan around VCF 9.1 or later for your upgrade path.
- Dell PS involvement: Expect professional services to be part of the migration, especially for existing environments.
- Watch the roadmap: Timelines may shift, but the trend is clear, Dell and VMware are aligning under one VCF code base.
A new chapter for VxRail
The separate VCF-on-VxRail track is now closed, and with VCF 9 the path forward is clear: a single, unified platform where VxRail sits alongside other hardware options under the same code base. Dell’s role continues on the hardware lifecycle side, but the days of a distinct software integration are over.
And that leaves us with the real question: in this new standardized world, what is the true value of VxRail today?