VCF Operations as the Day-2 Operating Model: How to Actually Run a VCF 9.1 Fleet

This is Part 9 of an architect’s read of VCF 9.1. Parts 1–7 covered the platform architecture. Part 8 was the customer migration journey from vSphere + Aria Operations. This piece is about how the platform actually operates day-to-day — the Day-2 operating model that sits on top of everything else.

Most VCF 9.1 commentary so far has covered features. Real-time metrics. PromQL. Integrated logs. Security Posture Management. The features are real. What’s under-discussed is how they combine into a coherent operating model — and what that means for the teams who have to actually run the platform.

Broadcom’s own survey data tells one part of the story: 51% reduction in infrastructure management time, 46% reduction in monitoring time, 47% capacity efficiency improvement, 39% MTTR/MTTI improvement. Those are average benefits found in a March 2026 survey of 44 VCF 9 customers. The architectural reason behind those numbers is the unified operating model VCF Operations now provides. This piece is the architect’s take on it.

The Day-2 problem VCF used to have

Pre-9.x Day-2 operations meant orchestrating across multiple consoles:

• vCenter Server for VM and ESXi management

• SDDC Manager for VCF lifecycle, network pool management, password rotation

• NSX Manager for networking and security policy

• Aria Operations for monitoring, capacity, and analytics

• Aria Operations for Logs (Log Insight) for log management

• Aria Operations for Networks (Network Insight) for network observability

• Aria Automation for self-service and IaC

• Aria Suite Lifecycle for managing the Aria stack itself

Eight consoles. Each with its own RBAC, its own dashboards, its own API surface, its own lifecycle. Operations teams swivel-chaired across them, mentally correlating events that should have been correlated by the platform. The cost was time, errors, and slow problem resolution.

VCF 9.x consolidates this. VCF Operations is now the central console for the VCF fleet — dashboards, log analysis, reporting, licensing, fleet management, lifecycle, certificate management, password management. The eight consoles collapse into a smaller, coherent set, with VCF Operations as the primary surface.

The four-pillar console: Build, Manage, Operate, Protect

VCF 9.1’s VCF Operations console reorganises the entire operating surface into four segmented areas, each owning a distinct workflow class.

Build. Deployment and lifecycle workflows. Adding VCF Instances, deploying components, extending the fleet, importing existing environments, running upgrades. The Lifecycle workspace inside Build is where Fleet Update Service (Part 3) operations live — patches, upgrades, async patch management, parallel cluster orchestration. The Developer Center sits here too — API Explorer for SDDC Manager, NSX, and other APIs, with built-in templates for common automation tasks.

Manage. Fleet Management, Capacity, Cost, and Licensing. This is where the strategic-decision workflows live. Fleet-wide capacity insights including NVMe Memory Tiering recommendations (new in 9.1). Cost analysis and showback — including dedicated cost reporting for VKS / Kubernetes workloads. License usage tracking and the new programmatic license management (9.1 eliminates the manual 180-day license-usage acknowledgment cycle). Resource Efficiency views including Memory Tiering statistics. Automated license renewal.

Operate. Day-to-day operations, troubleshooting, alerting, health, and general configuration. This is where operations teams live most of the day. Real-time metrics (new in 9.1) for 2-second granular ESX, NSX, vSAN, and vCenter telemetry — essentially ESXtop integrated into VCF Operations. Active Findings for diagnostics across vSAN, NSX, and ESX via property- and log-based signatures. Alert configuration, performance dashboards, custom views.

Protect. Security, compliance, recovery, and audit. Security Posture Management with automated compliance scoring and one-click remediation against VCF security guidelines and PCI DSS benchmarks. Security audit logs integrated into the console (rather than living in a separate Logs UI). vSphere Protection and Recovery status. Confidential computing visibility — identifying confidential VM-capable hosts and monitoring confidential workloads. This pillar is the operational surface for the security architecture covered in Part 5.

The architecture choice behind the four pillars is to align the operating surface to operational intent rather than to platform components. An operator focused on protecting the fleet goes to Protect; an operator running performance investigation goes to Operate; a strategic capacity planner works in Manage. Components like vSAN, NSX, vCenter, and VKS surface inside each pillar where they’re relevant, rather than each having a dedicated console.

Real-Time Metrics: ESXtop in the platform console

Real-Time Metrics is the headline 9.1 observability feature. It deploys as a VCF Service component into the Management Services Cluster (a 12 vCPU / 24 GB worker node, plus optional control plane scaling), collecting ESX, NSX, vSAN, and vCenter metrics at up to 2-second granularity.

Architecturally, it brings the kind of granular telemetry previously only accessible through SSH-into-host ESXtop sessions into the VCF Operations console — directly correlatable with the platform’s wider observability surface. For HLD:

• Deploy the Real-Time Metrics component via Build > Lifecycle > VCF Management > Components

• Note the worker node footprint added to the Management Services Cluster

• Real-time collection is opt-in via VCF Operations policy — enable per host, per cluster, or globally

• Best practice: scope it tightly during normal operations (limit by policy) and broaden during specific troubleshooting windows

• Pair with PromQL for custom queries beyond the out-of-the-box dashboards

PromQL support and the AI-ready API surface

VCF Operations 9.1 adds PromQL as a query language — the same language used by Prometheus and the broader cloud-native observability ecosystem. This is structurally important:

• PromQL queries can be used in dashboards, alerts, and ad-hoc analysis

• Prometheus Server Management Pack integration brings external Prometheus data into VCF Operations

• AI workloads (Part 7) often emit Prometheus-compatible metrics natively — VCF Operations becomes the federation point

• Custom application metrics from node exporters can be correlated with infrastructure metrics in one place

On top of PromQL, VCF Operations 9.1 exposes APIs designed for AI integration. Customers building Retrieval-Augmented Generation (RAG) pipelines and Model Context Protocol (MCP) frameworks can pull infrastructure metric, log, and inventory data into AI workflows. The AIOps integration story is now a first-class platform capability rather than a custom-build.

Integrated log management

Log Insight as a separate product is gone. VCF Operations 9.x integrates log management directly into the unified console:

• Log exploration, log-based alerts, and log dashboards directly within VCF Operations

• Centralised log collection from a single UI — vCenter, ESX, NSX, VKS, applications

• Pre-installed Logs Agent on VCF Operations for Networks for unified log + flow telemetry

• Security audit logs surfaced in the Protect pillar

• Centralised log forwarding to third-party SIEM and log-analytics platforms

• Log partitioning and access control unified with VCF Operations RBAC

For Day-2 incident response, this is structural. An operator investigating a vSAN performance issue can pull the metric (Operate tab), correlate to the logs (same tab, log explorer), check the security audit trail (Protect tab), and assess capacity impact (Manage tab) without leaving the console. The legacy standalone Log Insight UI is still available for advanced log workflows during transition, but the integrated experience is where new operational habits should form.

Active Findings and diagnostic acceleration

Active Findings is VCF Operations’ evolution of the older Aria Operations alerts model. The change is from threshold-based alerts to signature-based diagnostics:

• Property-based signatures — known patterns in configuration, version, or state that indicate active or impending issues

• Log-based signatures — known patterns in log content that indicate specific failure modes

• Cross-component correlation — a finding can span vSAN, NSX, ESX, and vCenter in one root-cause narrative

• Single-pane-of-glass surfacing — the Diagnostic Findings view in VCF Operations consolidates active findings across the fleet

• Built-in remediation guidance — each finding includes KB references and recommended actions

The architectural effect is that operations teams stop “monitoring metrics” as their primary work mode and start “resolving findings.” The platform does the correlation; humans do the resolution. For HLD: assume Active Findings becomes the primary alerting surface. Custom alerts still have a place, but the foundation is signature-driven.

Security Posture Management

New in 9.1, Security Posture Management (SPM) brings continuous-compliance enforcement into VCF Operations. From the Protect pillar:

• Automated assessment against VCF security guidelines and PCI DSS benchmarks

• Compliance scoring across the fleet

• Drift detection — alerts when configurations drift away from compliant baselines

• One-click remediation for many common findings

• Audit-ready reporting reducing manual audit preparation overhead

• Integration with Advanced Cyber Compliance (ACC, Part 1) for continuous compliance enforcement

For compliance-heavy customers — finance, government, healthcare — SPM is structural. The audit posture moves from “prepare-for-the-audit” to “report-on-the-current-state.”

Configuration Drift Management

Host Profiles existed in vSphere but were never properly compatible with VCF. Configuration Drift Management in VCF 9.x fixes this:

• vCenter Configuration capture as a baseline

• ESX configuration capture including advanced settings

• Drift detection when actual configuration deviates from baseline

• Reconciliation workflows to bring drifted hosts back to baseline

• Fleet-scale management of ESX advanced settings

The HLD implication: capture baselines as part of the platform commissioning, not as a Day-2 afterthought. The baselines then become the source of truth for what “compliant” means in your environment.

Management Pack Builder and Marketplace

VCF Operations’ extensibility surface in 9.1:

• Marketplace — find, download, install integrations from the VMware Marketplace directly in VCF Operations

• Management Pack Builder — build custom management packs in the admin console, no code, with JSON and XML REST API support

• Extend existing objects with new metrics and relationships

• Design, test, and install custom packs in the same console

• Telegraf agent integration for VKS / VM-based application observability

Where vendor management packs don’t exist or aren’t yet 9.x-compatible, Management Pack Builder fills the gap. For customer environments with third-party storage, networking, or hardware that needs integration into VCF Operations, this is the path.

Day-2 design patterns for VCF Operations

Four operational patterns I work with.

Pattern 1: Standard enterprise operating model. Single VCF Operations instance per VCF Fleet. All four pillars active. RBAC roles aligned to operational functions (build, manage, operate, protect). Real-Time Metrics scoped to specific clusters by policy. Active Findings drives alerting. SPM continuously running against VCF baselines and any applicable industry benchmarks.

Pattern 2: Service provider / multi-tenant operations. VCF Operations exposes per-tenant cost showback (including VKS), per-tenant capacity views, and per-tenant log/audit boundaries. Self-service consumption by tenants via VCF Automation, observability by tenants via tenant-scoped VCF Operations views. The provider owns the platform; tenants see only their own slice.

Pattern 3: Regulated operations. SPM continuously enforcing PCI DSS, HIPAA, FedRAMP, ISO 27001 baselines. Configuration Drift Management with strict remediation policies. Security audit logs flowing to long-term archive and SIEM. Confidential computing visibility enabled. Real-Time Metrics scoped only during specific authorised investigation windows.

Pattern 4: AI / mixed-workload operations. Standard pillars plus Private AI Model and GPU Metrics (Part 7) in the Operate pillar. AI Metrics Observability Dashboard (Grafana) for detailed AI telemetry. AI-ready APIs exposing platform data into RAG / MCP pipelines. Cost showback for both VKS and traditional VM workloads.

Common HLD/LLD anti-patterns for Day-2 operations

Treating VCF Operations as just Aria Operations renamed. Mental shift required. The four-pillar console is not Aria Operations with a different skin. Operational habits need to evolve to use the pillar segmentation as the navigation primitive.

Skipping Real-Time Metrics deployment. It’s an additional component with footprint, but the diagnostic acceleration during incidents is substantial. Plan it in.

Ignoring Active Findings in favour of custom alerts. Custom alerts still have value, but Active Findings is where the platform engineering investment is. Adopt it as the primary alerting layer.

Running Logs and Operations as separate workflows. They’re integrated. Train operators to use the integrated experience, not the legacy standalone Log Insight UI, for new workflows.

Not configuring SPM from Day-0. Compliance posture should be baseline, not retrofit. SPM should be running before workloads land on the platform.

Skipping Configuration Drift Management baselines. Without baselines, drift detection has nothing to compare against. Capture baselines during commissioning.

Manual license cycles. 9.1 eliminates the 180-day manual acknowledgment. Move to programmatic license management via the Business Services console and VCF Operations APIs.

Single VCF Operations for distributed fleets without scaling. Multi-instance, multi-region fleets need VCF Operations sized appropriately. Validate against the documented VCF Operations Models for your fleet shape.

Forgetting the Management Pack ecosystem. Third-party storage, network, hardware telemetry needs management packs. Inventory what’s available, what needs Management Pack Builder, and what stays outside VCF Operations.

Decision framework: where does this Day-2 task live?

When an operational task arrives, navigate to the right pillar:

• Building, extending, lifecycle-ing the fleet → Build pillar

• Capacity planning, cost analysis, licensing, fleet inventory → Manage pillar

• Day-to-day monitoring, troubleshooting, alerting, performance → Operate pillar

• Security posture, compliance, audit, recovery, confidential workloads → Protect pillar

For specific task types:

• New cluster commissioning → Build > Lifecycle

• Memory Tiering capacity recommendation → Manage > Optimize > Resource Efficiency

• Performance investigation → Operate > Real-Time Metrics + Active Findings

• Security audit → Protect > Security Audit Logs + SPM

• Configuration baseline check → Configuration Drift Management

• Cost showback for a tenant → Manage > Cost

• Custom metric or third-party integration → Marketplace or Management Pack Builder

• AI workload observability → Operate (Private AI Model + GPU Metrics) + AI Metrics Dashboard

Closing

VCF Operations in 9.1 is the operating model the platform always implied but never quite delivered. The four-pillar console reorganises the operational surface around intent rather than components. Real-time metrics close the diagnostic-granularity gap that drove operators back to SSH. PromQL and the AI-ready API surface make the platform observable from the cloud-native ecosystem. Integrated logs eliminate the swivel chair. Active Findings shifts the alerting model from thresholds to signatures. SPM, Configuration Drift Management, and programmatic licensing turn Day-2 hygiene into a Day-0 design input.

For my own design reviews, the Day-2 questions I work through every time:

• Is the four-pillar mental model aligned to the customer’s operational team structure?

• Is Real-Time Metrics deployed, and what’s the scoping policy?

• Are Active Findings used as the primary alerting surface, or are custom alerts still dominant?

• Is SPM enabled with the right benchmark profile (VCF, PCI, HIPAA, FedRAMP, etc.)?

• Is Configuration Drift Management capturing baselines during commissioning?

• Is the Logs experience integrated, or are operators still using the standalone UI?

• Is licensing managed programmatically?

• Are third-party integrations Marketplace-sourced or Builder-developed?

• For AI workloads, is Private AI Model + GPU Metrics in the Operate pillar configured?

• Is the VCF Operations sizing appropriate for the fleet shape (instances, regions, scale)?

Get those answered and the operating model is set up to deliver the time, cost, and capacity benefits that the survey numbers suggest are achievable.

That closes Part 9. Together with Parts 1–8, this is the nine-part read of VCF 9.1 — the platform architecture, the workload class for AI, the customer migration journey, and now the operating model that ties it all together.

Sources

• Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1 (Broadcom)

• VCF 9.1 is Available: Explore the New Features in Hands-on Labs (Broadcom)

• VCF 9.1 Licensing: Programmatic, Centralized, and Built to Scale (Broadcom)

• VCF Operations Models (Broadcom TechDocs)

• Operations in VMware Cloud Foundation 9.0: The Modern Way to Build and Manage Your Private Cloud (Broadcom)

• VCF 9.1 — What’s New? VCF Operations Real-Time Metrics (Gibson Virtualization)

• VCF 9.1 — What’s New? VCF Operations (Gibson Virtualization)

• VCF 9.1.x Ultimate Deployment Guide (Leaha’s Blog)

• VCF 9.1 GA is Available: Explore the New Features in Hands-on Labs (Angry Admin)