The VCF Signal — Issue #1

Welcome to the first issue of The VCF Signal.

Every week I'll send you one field-tested breakdown on VCF 9, VKS, and enterprise data protection. No vendor spin. No release note summaries dressed up as insight. Just what I'm actually seeing in production and the frameworks I use to make decisions when the stakes are real.

You're here because you work in enterprise infrastructure and you're tired of reading docs that tell you what a feature does but not what happens when it meets your environment. That's what this is for.

Let's get into it.

VCF 9.1 went GA last week. Everyone's reading the release notes.

Here's the number you should be writing on a whiteboard right now: 517.

That's the number of days until ESX 8.0u3 hits End of Support (October 11, 2027).

517 days sounds like a long runway. It isn't — not in enterprise. Factor in:

You're looking at a real planning window of 12–18 months if you want to do this right. Which means the window opens now, not when the EoS notice hits your inbox.

The teams I've seen struggle through VMware upgrades are always the ones who treated the EoS date as the start line. It's the finish line. Plan accordingly.

The official release notes are 40 pages. Here's what I'm actually paying attention to as someone building on this stack.

1. Multi-Version Offline Depot

This one looked like a footnote. It isn't.

VCF 9.0.1, 9.0.2, and 9.1.0 can now coexist in a single Offline Depot. The VCF Download Tool (VCFDT) handles the metadata and binary management. What this actually means for architects: you're no longer forced into a single upgrade path. Environments where not every workload domain is ready to move at the same time — which is most enterprise environments — just got significantly more manageable.

Previously you had to choose: upgrade the whole environment or manage multiple depot instances. Now you can stage 9.0.2 and 9.1.0 side by side and move workload domains independently. That's a genuine operational win.

2. Topology-Aware Scheduling for AI Workloads

The headline is AI. The substance is workload placement.

Topology-aware scheduling in VCF 9.1 changes how you size and position supervisor clusters in a VKS environment. GPU-intensive workloads and AI inference jobs can now be placed with awareness of fault domain boundaries in a way that wasn't clean before. Zero-downtime vMotion for these workloads changes the operational guarantee for teams running AI in production on-prem.

If you're designing for private AI on VCF 9.1, this is the feature that makes the architecture defensible to your security and ops teams.

3. CyberRecovery + Continuous Compliance

The CyberRecovery integration story in VCF 9.1 is the most underappreciated part of this release.

Continuous compliance monitoring paired with air-gapped CyberRecovery in the same platform conversation means enterprise security teams can stop asking "but what about ransomware recovery?" as a blocking question. Dell PPDM + VCF 9.1 gives you protection at every layer — VM-level policy, Kubernetes workload protection inside VKS, and the air-gapped vault as the last line of defense.

This is the design answer I'm giving customers right now.

Before any VCF 9.1 upgrade, here's the framework I'm running through. Not the vendor checklist — the real one.

Check 1: VKS Supervisor Cluster Readiness

Run a supervisor health check before you touch anything. Verify namespace policy assignments are consistent across the cluster. Check VKS version compatibility against the 9.1 upgrade matrix — Broadcom's docs have improved here but they're still not complete on edge cases.

The thing most teams miss: the supervisor cluster initialization behavior changes under certain NSX configurations in 9.1. If your NSX segment topology has any drift from your original design doc, the upgrade will surface it. Better to find it before the maintenance window.

Check 2: PPDM Policy Alignment

Data protection policies do not auto-migrate. This is the one that bites teams the hardest.

You have two separate design tracks: VM-level protection via PPDM and Kubernetes workload protection inside VKS. If your HLD treats these as one conversation, your first DR test post-upgrade will show you why that's wrong. Before upgrading, audit both tracks independently and document which policies need manual review after the upgrade completes.

Check 3: NSX Segment Configuration Drift

NSX segment configuration drift is the hidden upgrade risk nobody puts in the project plan.

Run a configuration audit against your original NSX design before you move. Pay particular attention to segment profiles in workload domain environments — the upgrade process is sensitive to drift here in ways that aren't obvious until something breaks post-upgrade.

The rule I follow: if it wasn't documented, assume it drifted.

I want this newsletter to be useful, not just informative. So here's what I'm asking in Issue #1:

What's your biggest blocker to upgrading to VCF 9.1?

Reply to this email and tell me. I read every response and the most common answers will shape what I write about in Issue #2.

If you're not facing a VCF 9.1 decision right now, tell me what you are working through. This signal goes both directions.

Next week I'm going to write about the mental model shift that trips up almost every team moving from classic vSphere deployments into VCF: going from "I manage clusters" to "I consume workload domains." It sounds philosophical. The operational and design implications are very concrete.

If there's something specific you want me to cover — a decision you're wrestling with, a pattern you keep seeing, a question you can't get a clean answer to — reply and tell me.

See you next week.

— Adam

Broadcom Knight | VCF 9 + VKS | Dell CyberRecovery Certified @FirstWizardZed on X

You're receiving this because you subscribed at vcf.somerandomtech.com. To unsubscribe, click the link below.