Series: Post-Broadcom Focus: Execution Physics Publishing Now

POST-BROADCOM SERIES

Control Plane & Execution Physics Transition Model


Rack2Cloud - Post-Broadcom Series
Post-Broadcom Series dependency layer model — five-layer migration stack showing Identity, Backup, Monitoring, Storage, and Compute in order with Compute highlighted as the last layer to move
The dependency-first migration model: control plane layers abstract before compute moves.

>_ Architecture Principle

Migration is a control-plane and execution-physics transition. Relocating the VMDK is the absolute last layer you should move.

Platform transitions — VMware to Nutanix AHV, sovereign KVM, or hybrid-cloud exit ramps — consistently produce catastrophic Day 2 operational and performance regressions for the same reason: engineers execute them as VM moves. That framing ignores two structural anchors that govern whether the migration succeeds or stalls.

The first is control-plane coupling — the backup APIs, IAM integrations, and monitoring hooks that remain tightly bound to ESXi long after the workloads nominally move. The second is execution physics — the fact that moving from a centralized SAN to HCI turns your Top-of-Rack switches into the storage backplane, and if you haven’t modeled the CVM tax and scheduler rules before cutover, you will encounter Migration Stutter.

This series treats migration as a dependency graph and an execution translation. Each part covers one layer of that model — in the order you should actually address them.

>_ GitHub Repository

Broadcom Exit Strategy — Working Models & Decision Artifacts

Canonical architecture references, blast-radius maps, dependency-first migration model, and the PDF Playbook.

Post-Broadcom Migration Architecture: The Dependency Model

Migration must proceed in reverse order of compute dependencies.

The dependency layer order below is not a project phase sequence — it is the architectural reality of how these systems are coupled. Moving compute before the foundation layers are abstracted produces exactly the three failure signatures this series exists to prevent.

Layer 1 Identity / RBAC Who can authorize
Layer 2 Backup & DR How we survive failure
Layer 3 Monitoring & Automation How we observe state
Layer 4 Storage & Network Fabric Where data lives and transits
Layer 5 Compute / VMDK This moves last

Failure Signature 01

The API Break

Recovery gaps emerge when backup controllers can’t reach new hypervisor APIs — missing vCenter hooks, broken snapshot chains.

Failure Signature 02

Migration Stutter

I/O spikes during rebuild saturate East-West switches. P99 tail latency stalls databases. The CVM controller tax was never modeled.

Failure Signature 03

The IAM Mismatch

Operational tooling fragments because RBAC policies don’t translate 1:1 between vCenter and Prism/KVM. Automation breaks silently.


The Series

Five parts. One execution layer each. Read in sequence.

Part 01 — Active Execution Physics Layer

Beyond the VMDK: Translating Execution Physics

“Lift-and-shift” is a business term, not an engineering one. When you migrate from vSphere to AHV, you are re-homing an execution thread into a fundamentally different kernel environment. This part covers the ESXi vs. AHV scheduler model, the shift from %RDY to %st as the contention metric, and why treating AHV as “vSphere with a different UI” is how you end up in a Migration Stutter at 2am.

>_ Read Part 01
Part 02 — Up Next Resource Contention Layer

The Controller Tax: Modeling Hyperconverged Resource Contention

The CVM is the most consistently under-modeled component in a Nutanix migration. It is a resident tenant on every node — consuming CPU, memory, and network bandwidth to manage the storage fabric. This part covers CVM sizing physics, the performance overhead it introduces under I/O load, and how to model it accurately before production exposes it.

>_ Publishing soon — subscribe via The Dispatch to be notified

Part 03 — Locked High-I/O Cutover Layer

Migration Stutter: Handling High-I/O Cutovers Without Data Loss

East-West network saturation, storage rebuild amplification, and I/O sequencing during live cutovers — modeled before the maintenance window opens.

Part 04 — Locked Policy Translation Layer

Policy Translation: Mapping VMware DRS & SRM to Flow

DRS affinity rules, SRM failover policies, and micro-segmentation logic don’t port automatically. The translation physics and where gaps require re-architecture.

Part 05 — Locked Validation Layer

Upgrade Physics: Designing for Rolling Maintenance

Post-migration Day 2 operations — rolling upgrade sequencing, rebuild traffic modeling during maintenance windows, and drift detection on the new platform.


Canonical Architecture References

The strategic and performance foundations this series builds on.

>_ Strategic Blueprint

Broadcom Exit Strategy

The decision framework — which exit path fits your environment and the fiscal case for acting now vs. deferring.

>_ Read the Blueprint

>_ Execution Reality

Why Licensing Isn’t the Real Risk

Where migrations actually fail — not at the pricing layer, but at the operational coupling layer.

>_ Read the Analysis

>_ Data Physics

Sizing for the CVM: The HCI Controller Tax

Why mis-sized CVMs kill AHV performance under load and how to validate sizing before production cutover.

>_ Read the Model

>_ Connected Architecture

The Full Execution Stack

The series is the execution layer. The pages below are the architectural targets, performance foundations, and platform deep dives.