VCF Operations & Operations for Logs — Complete Handbook

VMware Cloud Foundation 9.0 | Broadcom

Author: Virtual Control LLC Copyright: © 2026 Virtual Control LLC. All rights reserved. Version: 1.0 — March 2026 Classification: Internal / Professional Reference

PART I: VCF Operations

Chapter 1 — Product Overview

VCF Operations is the unified monitoring, capacity planning, and optimization platform for VMware Cloud Foundation environments. It provides real-time analytics across compute, storage, networking, and application layers, delivering intelligent workload placement, proactive alerting, and capacity forecasting to ensure the health and efficiency of your private cloud infrastructure.

1.1 Naming History

The product now known as VCF Operations has undergone several name changes as VMware's portfolio evolved and Broadcom completed its acquisition of VMware. Understanding this lineage is critical when referencing older documentation, KB articles, and community resources.

Important: When searching VMware Knowledge Base articles, use all three historical names — vRealize Operations, Aria Operations, and VCF Operations — to ensure complete coverage of relevant results. Many KB articles have not yet been updated to reflect the latest naming.

The underlying technology, architecture, and API surface remain consistent across these name changes. A deployment upgraded from vRealize Operations 8.6 through Aria Operations 8.14 to VCF Operations 8.18.2 retains its full configuration, dashboards, super metrics, and alert definitions without requiring re-creation.

1.2 Product Family

VCF Operations is not a single appliance — it is the anchor product within a broader operations suite. The following table lists all products in the VCF Operations family as of VCF 9.0:

All products in the suite share a common authentication framework, can be cross-launched from one another, and are managed through a unified lifecycle workflow in SDDC Manager.

1.3 Architecture

VCF Operations employs a distributed analytics architecture designed for horizontal scalability and high availability. The architecture consists of the following tiers:

Analytics Cluster

The analytics cluster is the core of VCF Operations. It processes incoming metrics, computes dynamic thresholds, evaluates alert conditions, and serves the user interface. A production analytics cluster consists of:

• Primary Node — The first node deployed. It hosts the master controller services, the global xDB distributed datastore partition, the API endpoint, and the administrative UI. In a single-node deployment, the primary node performs all roles.
• Replica Node — An identical node that maintains a full copy of the primary node's configuration and data. If the primary node fails, the replica automatically assumes the primary role. There is exactly one replica in an HA-enabled cluster.
• Data Nodes — Additional nodes that expand the cluster's data processing and storage capacity. Data nodes handle metric ingestion, analytics computation, and xDB partitions. You can add data nodes in pairs to scale from 16,000 to 100,000+ objects.

Collectors

Collectors are responsible for gathering metrics from monitored endpoints and delivering them to the analytics cluster:

• Embedded Collector — Runs within each analytics cluster node. Suitable for endpoints that are network-local to the cluster.
• Remote Collector — A separate lightweight OVA deployed near the monitored endpoints. Used when endpoints reside in different network segments, datacenters, or workload domains. Remote Collectors do not store data locally — they forward all collected data to the analytics cluster over HTTPS (port 443).

Adapters

Adapters are modular plugins that define how VCF Operations connects to and collects data from specific endpoint types. Each adapter type understands the API, object model, and metrics of its target system. Key built-in adapters include:

• vCenter Adapter (collects ESXi hosts, VMs, clusters, datastores, resource pools)
• NSX-T Adapter (collects transport nodes, logical switches, edge nodes, load balancers)
• vSAN Adapter (collects vSAN clusters, disk groups, capacity, health)
• SDDC Manager Adapter (collects workload domains, lifecycle events)

Management Packs

Management packs extend VCF Operations with adapters, dashboards, alert definitions, and reports for third-party and additional VMware products. They are installed through the product UI or via the VCF Suite Lifecycle Manager.

Data Flow Summary

1. Collection — Adapters (running on embedded or remote collectors) poll endpoints at configured intervals (default: 5 minutes) and retrieve raw metrics, properties, and relationships.
2. Ingestion — Raw data is transmitted to the analytics cluster over HTTPS and written to the xDB distributed datastore.
3. Analytics — The analytics engine computes dynamic thresholds (based on machine-learning models), evaluates symptom and alert definitions, runs capacity models, and calculates health/risk/efficiency scores.
4. Presentation — Processed data is served through the HTML5 UI, REST API, dashboards, views, and reports.

1.4 VCF 9.0 Integration Model

In VCF 9.0, VCF Operations is a mandatory first-class component of the Cloud Foundation stack, not an optional add-on. Its integration with the broader VCF platform is deep and bidirectional:

Fleet Manager Deployment

VCF 9.0 introduces Fleet Manager as the next-generation deployment and lifecycle orchestrator. Fleet Manager automates the full VCF Operations deployment workflow:

1. Fleet Manager references the Bill of Materials (BoM) to determine the correct VCF Operations OVA version.
2. The OVA is downloaded from the Broadcom repository or a local depot.
3. Fleet Manager deploys the OVA to the management cluster, applying network and sizing parameters from the deployment specification.
4. Post-deployment configuration (NTP, DNS, admin credentials) is applied automatically.
5. The VCF Operations instance is registered with SDDC Manager for ongoing lifecycle management.

SDDC Manager Orchestration

SDDC Manager provides ongoing lifecycle management for VCF Operations:

• Upgrade orchestration — SDDC Manager downloads upgrade bundles, validates compatibility, creates pre-upgrade snapshots, applies the upgrade, and validates post-upgrade health.
• Configuration drift detection — SDDC Manager monitors VCF Operations configuration against the desired-state specification and flags deviations.
• Certificate rotation — SDDC Manager coordinates certificate renewal across all VCF components, including VCF Operations.

Mandatory Monitoring

In VCF 9.0, VCF Operations monitoring is enabled by default for every workload domain. When a new workload domain is created, SDDC Manager automatically:

• Configures a vCenter adapter instance for the workload domain's vCenter Server.
• Configures an NSX adapter instance for the workload domain's NSX Manager cluster.
• Enables vSAN monitoring if the workload domain uses vSAN storage.
• Applies the default monitoring policy for the workload domain.

This ensures complete observability from the moment a workload domain becomes operational, with no manual adapter configuration required.

Chapter 2 — Sizing and Prerequisites

Proper sizing of VCF Operations is critical to achieving reliable performance, accurate analytics, and timely alerting. Under-sizing leads to collection lag, delayed alerts, and UI timeouts. Over-sizing wastes management cluster resources. This chapter provides the authoritative sizing tables and prerequisite requirements.

2.1 Node Types

VCF Operations uses five distinct node types. Each serves a specific role in the analytics architecture:

Node Selection Guidance

• Single-node deployment (primary only): Suitable for lab, proof-of-concept, or small environments with fewer than 1,200 objects. No high availability.
• HA deployment (primary + replica): Suitable for production environments. Provides automatic failover. Recommended for all VCF production deployments.
• Scale-out deployment (primary + replica + data nodes): Required when the object count exceeds 16,000 or when collection intervals need to be shortened below the default 5 minutes.

2.2 OVA Sizing

The VCF Operations OVA is deployed with one of five predefined size profiles. The size is selected during OVA deployment and cannot be changed after deployment without redeploying the node.

Note: The "Maximum Objects" column refers to the total count of monitored objects across all adapters — VMs, hosts, datastores, clusters, port groups, NSX objects, vSAN objects, and any objects from management packs. Use the formula: Total Objects ≈ (VMs × 1.0) + (Hosts × 3.5) + (Clusters × 2.0) + (Datastores × 1.0) as a rough estimation starting point.

Sizing Recommendations

• Always size based on projected 12-month growth, not current object count.
• If the object count falls between two size tiers, select the larger tier.
• All nodes in a cluster (primary, replica, and data nodes) must use the same size profile.
• Remote Collectors and Cloud Proxies have their own separate sizing (see Section 2.4).

2.3 Cluster Models

VCF Operations supports three cluster deployment models:

Simple (Single Node)

• Consists of a single primary node.
• No high availability or automatic failover.
• Suitable for non-production environments only.
• If the node fails, monitoring is completely unavailable until the node is restored.

High Availability (HA)

• Consists of a primary node and a replica node.
• The replica node maintains a continuously synchronized copy of the primary's data and configuration.
• If the primary node becomes unavailable, the replica is automatically promoted to primary within approximately 5 minutes.
• This is the minimum recommended production configuration.
• Both nodes must reside on the same vCenter Server and ideally in the same cluster, but on different ESXi hosts (use anti-affinity rules).

Continuous Availability (CA)

• Consists of three or more nodes configured as a cluster with a witness node.
• Provides the highest level of availability — the cluster continues to operate with no data loss even if one node fails entirely.
• Requires a minimum of three nodes: primary, replica, and at least one data node, plus a witness appliance.
• The witness appliance is a minimal OVA that participates in quorum votes but does not store analytics data.
• CA mode is recommended for mission-critical environments where even a brief monitoring gap is unacceptable.

Critical Limitation: You cannot convert a Simple (single-node) deployment to an HA or CA deployment in place. The replica and data nodes must be deployed as fresh OVAs and joined to the primary. However, you cannot retroactively add HA to a node that was initialized as a standalone instance without redeploying the primary. Plan your cluster model before initial deployment.

2.4 Remote Collector Sizing

Remote Collectors are deployed as separate OVAs with their own sizing profiles, independent of the analytics cluster node sizing:

Remote Collector Placement Guidelines

• Deploy one Remote Collector per remote network segment or datacenter that hosts monitored endpoints.
• The Remote Collector must have low-latency, reliable network connectivity to the endpoints it monitors (same LAN or campus network).
• The Remote Collector communicates with the analytics cluster over a single HTTPS connection (port 443). This connection can traverse WAN links and firewalls.
• If a Remote Collector becomes unavailable, collection for its assigned endpoints pauses. Data is not buffered — the gap in metrics will appear as a break in charts. Collection resumes automatically when the Remote Collector reconnects.

2.5 Disk Partitions

The VCF Operations appliance uses multiple disk partitions to separate data by function. Understanding these partitions is essential for troubleshooting disk-space alerts and planning NFS extension:

Best Practice: Monitor disk usage on /storage/db closely. When this partition reaches 90% utilization, VCF Operations triggers a critical alert and may begin dropping the oldest data to prevent total disk exhaustion. Extend this partition by adding an NFS datastore or by deploying additional data nodes to distribute the storage load.

2.6 Browser and Hypervisor Requirements

Supported Browsers

The VCF Operations HTML5 UI is supported on the following browsers:

• JavaScript must be enabled.
• Browser zoom should be set to 100% for optimal dashboard layout rendering.
• Pop-up blockers may interfere with report downloads and cross-launch URLs.

Supported Hypervisor Versions

Additional Prerequisites

• DNS — Forward and reverse DNS records must exist for every VCF Operations node before deployment. The FQDN is set during OVA deployment and cannot be changed post-deployment.
• NTP — All VCF Operations nodes must synchronize time with the same NTP source used by vCenter and ESXi hosts. Time skew greater than 5 minutes causes collection failures and certificate validation errors.
• Certificates — VCF Operations deploys with a self-signed certificate by default. For production, replace with a CA-signed certificate that includes the FQDN and IP address in the SAN field.

Chapter 3 — Network Port Requirements

VCF Operations requires specific network ports to be open between its nodes, monitored endpoints, and consuming services. Failure to open the correct ports results in collection failures, cluster communication breakdowns, or inaccessible UI. This chapter provides the complete port reference.

3.1 Inbound Ports

These ports must be open to the VCF Operations analytics cluster nodes from clients and external systems:

3.2 Outbound Ports

These ports must be open from the VCF Operations analytics cluster nodes (and Remote Collectors) to external endpoints:

3.3 Cluster-Internal Ports

These ports are used for communication between VCF Operations cluster nodes (primary, replica, and data nodes). They must be open bidirectionally between all cluster members:

Important: All cluster-internal ports must have low latency (< 1 ms round-trip) and high bandwidth (1 Gbps minimum). Cluster nodes should not be separated by WAN links, firewalls with deep packet inspection, or load balancers. Place all cluster nodes on the same VLAN or Layer 2 segment.

3.4 Localhost-Only Ports

These ports are bound to 127.0.0.1 (localhost) on each VCF Operations node. They do not require firewall rules because they are not accessible from the network. They are documented here for troubleshooting and security audit purposes:

3.5 Remote Collector Ports

Remote Collectors have a simplified port profile because they do not run analytics or store data:

Remote Collectors do not expose any inbound ports. All communication is initiated outbound by the collector. This makes Remote Collectors ideal for deployment in DMZ or restricted network zones where inbound connections are prohibited.

3.6 Firewall Rule Guidance

When creating firewall rules for VCF Operations, follow these best practices:

1. Use FQDNs, not IP addresses, in firewall rules where possible. VCF Operations nodes may change IP addresses during disaster recovery or migration. FQDN-based rules are more resilient.

2. Restrict source addresses. Do not use any as the source for inbound port 443. Limit access to known admin workstation subnets, SDDC Manager, and Remote Collector IP ranges.

3. Enable stateful inspection. All VCF Operations connections are TCP-based and work correctly with stateful firewalls. Stateful inspection ensures return traffic is automatically permitted.

4. Do not use SSL decryption/inspection on traffic between VCF Operations cluster nodes. SSL interception between cluster members causes certificate validation failures and breaks cluster communication.

5. Test connectivity before deployment. Use curl -v https://<target>:443 from the VCF Operations node to verify that each required port is reachable before configuring adapters. Connection failures after adapter configuration are difficult to distinguish from credential or API errors.

6. Document all rules. Maintain a port matrix document that maps each firewall rule to its VCF Operations purpose. This accelerates troubleshooting when connectivity issues arise during maintenance windows or network changes.

Chapter 4 — Deployment

This chapter covers all deployment methods for VCF Operations — from the fully automated VCF 9.0 workflow to manual OVA deployment via the vSphere Client and command-line tools. Regardless of the deployment method, the end result is the same: a running VCF Operations appliance ready for initial configuration.

4.1 VCF Automated Deployment Flow

In a VCF 9.0 environment, VCF Operations deployment is orchestrated by SDDC Manager and Fleet Manager. This is the recommended deployment method for production VCF environments because it ensures consistency with the VCF Bill of Materials and integrates VCF Operations into the overall lifecycle management framework.

Automated Deployment Sequence

1. Prerequisite Validation — SDDC Manager validates that the management cluster has sufficient capacity (CPU, memory, storage) to host the VCF Operations appliance at the specified size.

2. OVA Acquisition — Fleet Manager retrieves the VCF Operations OVA from the configured software depot. In connected environments, this is the Broadcom online repository. In air-gapped environments, the OVA must be pre-staged in the local SDDC Manager depot.

3. OVA Deployment — Fleet Manager deploys the OVA to the management cluster's designated resource pool and datastore. Network configuration (IP, subnet, gateway, DNS, NTP) is injected via OVF properties derived from the deployment specification.

4. Appliance Boot and Self-Configuration — The appliance boots, applies the network configuration, generates initial self-signed certificates, and starts all core services. This takes approximately 10–15 minutes.

5. Registration — Fleet Manager registers the VCF Operations instance with SDDC Manager. This enables ongoing lifecycle management (upgrades, certificate rotation, health monitoring).

6. Initial Adapter Configuration — SDDC Manager automatically configures vCenter and NSX adapter instances for the management domain. If additional workload domains exist, adapters are configured for those as well.

7. Validation — Fleet Manager runs a post-deployment health check to confirm that all services are running, the UI is accessible, and initial data collection has started.

Note: The automated deployment flow always deploys a Medium-sized OVA by default. To override the size, edit the deployment specification JSON before initiating the workflow. Consult the SDDC Manager API documentation for the exact parameter path.

4.2 OVA Deployment via vSphere Client

For environments not using VCF 9.0 automation, or when deploying additional nodes (replica, data), the OVA can be deployed manually through the vSphere Client.

Step-by-Step Procedure

Step 1 — Download the OVA

Download the VCF Operations OVA file from the Broadcom Support Portal (support.broadcom.com). Navigate to VMware Cloud Foundation → VCF Operations → Downloads. Select the version matching your VCF Bill of Materials.

Step 2 — Launch the Deploy OVF Template Wizard

1. Log in to the vSphere Client (https://<vcenter-fqdn>/ui).
2. Right-click the target cluster or resource pool in the inventory tree.
3. Select Deploy OVF Template.

Step 3 — Select the OVA Source

• Choose Local file and browse to the downloaded .ova file.
• Alternatively, choose URL and enter the direct download URL if the vCenter has internet access.
• Click Next.

Step 4 — Name and Location

• Virtual machine name: Enter a descriptive name, e.g., vcf-operations-primary-01.
• Location: Select the datacenter and folder where the VM will be placed.
• Click Next.

Step 5 — Select a Compute Resource

• Select the target cluster, resource pool, or ESXi host.
• Ensure the selected compute resource has sufficient capacity for the chosen OVA size.
• Click Next.

Step 6 — Review Details

• Review the OVA metadata: publisher, version, download size, and disk requirements.
• Click Next.

Step 7 — Configuration (Size Selection)

• Select the deployment size from the dropdown:
  • Extra Small, Small, Medium, Large, or Extra Large
• This selection determines vCPU, memory, and disk allocation. It cannot be changed after deployment.
• Click Next.

Step 8 — Select Storage

• VM Storage Policy: Select an appropriate storage policy (e.g., vSAN Default Storage Policy or a custom policy).
• Datastore: Select the target datastore. Ensure it has sufficient free space for the selected OVA size (refer to the sizing table in Section 2.2).
• Virtual disk format: Select Thin Provision to conserve initial storage. The disks will grow as data is collected.
• Click Next.

Step 9 — Select Networks

• Map the OVA network labeled Network 1 to the target port group on the management VLAN.
• Click Next.

Step 10 — Customize Template (OVF Properties)

This is the most critical page. Enter the following values:

• Click Next.

Step 11 — Ready to Complete

• Review all settings. Click Finish to begin deployment.
• The deployment task appears in the vSphere Client Recent Tasks panel. Typical deployment time: 5–10 minutes depending on storage performance.

Step 12 — Power On

• After deployment completes, right-click the VM and select Power → Power On.
• Open the VM console to watch the boot process. First boot takes approximately 10–15 minutes as the appliance initializes services, generates certificates, and prepares the datastore.

4.3 OVA Deployment via ovftool CLI

For automated or scripted deployments, use the VMware ovftool command-line utility. This is useful for deploying multiple nodes in a cluster or for integrating VCF Operations deployment into infrastructure-as-code pipelines.

Full ovftool Command

ovftool \
  --name="vcf-operations-primary-01" \
  --deploymentOption="medium" \
  --diskMode="thin" \
  --datastore="vsanDatastore" \
  --network="Management-PG" \
  --acceptAllEulas \
  --allowExtraConfig \
  --powerOn \
  --prop:vami.DNS.VMware_Aria_Operations="10.0.10.10" \
  --prop:vami.gateway.VMware_Aria_Operations="10.0.10.1" \
  --prop:vami.ip0.VMware_Aria_Operations="10.0.10.50" \
  --prop:vami.netmask0.VMware_Aria_Operations="255.255.255.0" \
  --prop:vami.hostname="vcf-ops-01.lab.local" \
  --prop:vami.NTP.VMware_Aria_Operations="10.0.10.10" \
  --prop:vami.domain.VMware_Aria_Operations="lab.local" \
  --prop:guestinfo.cis.appliance.root.password="VMware123!" \
  --prop:guestinfo.cis.appliance.ssh.enabled="True" \
  /path/to/vcf-operations-8.18.2.ova \
  "vi://administrator@vsphere.local:password@vcenter.lab.local/Datacenter/host/Management-Cluster"

Key Parameters Explained

Note: The OVF property names reference VMware_Aria_Operations because the OVA internal metadata still uses the Aria Operations naming convention. This does not affect functionality — it is simply the OVF property namespace.

4.4 VAMI Configuration

After the appliance boots and completes its initial self-configuration, the Virtual Appliance Management Interface (VAMI) is available for administrative tasks.

Accessing VAMI

Open a browser and navigate to:

https://<node-fqdn>/admin

Log in with the admin user account and the password specified during OVA deployment.

Historical Note: In older versions (vRealize Operations 6.x–8.x), the VAMI was accessed on port 5480 (https://<node-fqdn>:5480). In current versions, the VAMI is integrated into the main web interface at the /admin path on port 443.

VAMI Administrative Functions

The VAMI provides the following administrative functions:

• Network Configuration — View and modify IP address, DNS, gateway, and NTP settings. Changes require a service restart.
• Certificate Management — View the current TLS certificate, generate a new CSR (Certificate Signing Request), or install a CA-signed certificate.
• Service Control — Start, stop, and restart individual VCF Operations services.
• Time Zone Configuration — Set the appliance time zone.
• SSH Access — Enable or disable SSH access to the appliance for CLI troubleshooting.
• Support Bundle — Generate a diagnostic log bundle for Broadcom support cases.

4.5 Initial Setup Wizard

On the first login to the VCF Operations UI (https://<node-fqdn>/ui), the Initial Setup Wizard guides you through the essential configuration steps. The wizard consists of seven steps:

Step 1 — Getting Started

• The wizard displays a welcome page with an overview of the setup process.
• Click Next to begin.

Step 2 — Accept the EULA

• Read and accept the End User License Agreement.
• Check the I accept the terms checkbox.
• Click Next.

Step 3 — Choose the Deployment Type

• Select the deployment type:
  • New Installation — First node in a new analytics cluster.
  • Expand an Existing Cluster — Add this node to an existing cluster as a replica or data node.
• For a primary node deployment, select New Installation.
• Click Next.

Step 4 — Set the Admin Password

• Set (or confirm) the password for the admin user account.
• This account is the super-administrator with full access to all VCF Operations functions.
• Password requirements: minimum 8 characters, must include uppercase, lowercase, digit, and special character.
• Click Next.

Step 5 — Choose the Certificate Option

• Select the certificate mode:
  • Use the default self-signed certificate — Suitable for initial setup. Replace with a CA-signed certificate later.
  • Install a custom certificate — Provide a CA-signed PEM certificate and private key now.
• For most deployments, use the self-signed certificate initially and replace it post-setup.
• Click Next.

Step 6 — Configure NTP

• Verify or update the NTP server address(es).
• Click Test to validate NTP connectivity and synchronization.
• Click Next.

Step 7 — Ready to Complete

• Review the configuration summary.
• Click Finish to apply the configuration and start all VCF Operations services.
• The appliance will take 5–10 minutes to fully initialize. A progress bar is displayed.

After the wizard completes, the VCF Operations login page is displayed. Log in with admin and the password set in Step 4. The system is now ready for adapter configuration and monitoring setup (covered in subsequent chapters).

Chapter 5 — High Availability Cluster Setup

A single-node VCF Operations deployment provides no fault tolerance — if the appliance fails, all monitoring, alerting, and capacity analytics are lost until the node is restored. For production environments, deploying a high availability (HA) cluster is strongly recommended. This chapter provides a detailed walkthrough of HA cluster configuration.

5.1 Deploy Primary Node

The primary node is deployed using the procedures described in Chapter 4 (Section 4.2 for vSphere Client or Section 4.3 for ovftool). Complete the Initial Setup Wizard (Section 4.5) with the New Installation option.

Before proceeding to replica deployment, verify the primary node is fully operational:

1. Log in to https://<primary-fqdn>/ui with the admin account.
2. Navigate to Administration → Cluster Management.
3. Confirm the node status shows Online with a green indicator.
4. Verify that all services are running: navigate to Administration → Cluster Management → Services and confirm that every listed service shows a status of Running.

Pre-Requisites for Cluster Expansion

Before deploying the replica node, ensure:

• DNS A and PTR records exist for the replica node's FQDN and IP address.
• The replica node's IP address is on the same network segment (VLAN) as the primary node.
• Firewall rules are in place to allow all cluster-internal ports (see Section 3.3) between the primary and replica IP addresses.
• Sufficient compute capacity exists on the management cluster to host a second identically-sized OVA.
• Anti-affinity DRS rules are prepared (or will be created) to prevent the primary and replica VMs from running on the same ESXi host.

5.2 Deploy and Join Replica Nodes

Deploy the Replica OVA

Deploy a second VCF Operations OVA using the same size profile as the primary node. Use the same deployment method (vSphere Client or ovftool) described in Chapter 4.

Key settings for the replica OVA:

Power on the replica OVA and wait for it to complete first-boot initialization (10–15 minutes).

Join the Replica to the Primary

1. Open a browser and navigate to https://<replica-fqdn>/ui.

2. The Initial Setup Wizard appears. On the Deployment Type page, select Expand an Existing Cluster.

3. Enter the primary node's FQDN or IP address:

   • Primary Node Address: vcf-ops-01.lab.local

4. Click Validate. The wizard connects to the primary node and retrieves its certificate.

5. Accept the Certificate — Review the certificate thumbprint displayed. Verify it matches the primary node's certificate thumbprint (you can find this on the primary node under Administration → Cluster Management → Certificate). Click Accept.

6. Authenticate — Enter the admin credentials for the primary node.

7. Node Role Selection — Select Replica as the role for this node.

   • Selecting Data would add it as a data node instead (covered in scale-out documentation).

8. Click Next and then Finish to initiate the join process.

The join process takes approximately 15–25 minutes. During this time:

• The replica node downloads the full configuration from the primary.
• The xDB datastore is initialized and begins synchronizing data from the primary.
• Cluster membership is updated, and the primary node begins heartbeat monitoring of the replica.

Monitoring the Join Progress

On the primary node, navigate to Administration → Cluster Management. The cluster status panel shows:

• Replica Node: Status transitions from Joining → Synchronizing → Online.
• Cluster Status: Transitions from Single Node → Preparing HA → Online (HA Enabled).

Do not modify any configuration or restart any services during the join process.

5.3 Cluster Initialization

After the replica node joins successfully, the cluster requires activation to enable HA functionality:

1. On the primary node, navigate to Administration → Cluster Management.

2. The cluster status panel shows both nodes: the primary and the replica. Both should show status Online.

3. Click the Enable HA button (if it has not been automatically enabled during the join process).

4. A confirmation dialog appears: "Enabling High Availability will synchronize all data between the primary and replica nodes. This may temporarily impact performance during the initial synchronization. Do you want to continue?"

5. Click Yes to confirm.

6. The cluster enters the Synchronizing state. During synchronization:

   • All historical metrics, alert definitions, dashboards, super metrics, views, reports, and policies are replicated from the primary to the replica.
   • Synchronization time depends on the volume of data — expect 30 minutes to several hours for large deployments.
   • The UI remains accessible during synchronization, but some queries may be slower.

7. When synchronization completes, the cluster status changes to Online (HA Enabled). This indicates:

   • Both nodes are operational and in sync.
   • Automatic failover is active.
   • If the primary node becomes unreachable, the replica will be promoted to primary within approximately 5 minutes.

Verifying HA Functionality

To verify that HA is working correctly:

1. Navigate to Administration → Cluster Management → Status.

2. Confirm:

   • Cluster Mode: High Availability
   • Primary Node: Online
   • Replica Node: Online
   • Synchronization Status: Synchronized (no pending sync operations)

3. Check the Cluster Health dashboard (Dashboards → VCF Operations Self-Monitoring → Cluster Health). All health indicators should be green.

Creating Anti-Affinity Rules

To prevent both cluster nodes from running on the same ESXi host (which would defeat the purpose of HA), create a DRS anti-affinity rule:

1. In the vSphere Client, navigate to the management cluster.
2. Go to Configure → VM/Host Rules.
3. Click Add.
4. Name: VCF-Operations-Anti-Affinity
5. Type: Separate Virtual Machines
6. Members: Add vcf-operations-primary-01 and vcf-operations-replica-01.
7. Click OK.

DRS will automatically vMotion the VMs to separate hosts if they are currently co-located.

5.4 Limitations and Considerations

Critical: No In-Place Conversion from Simple to HA

VCF Operations does not support converting a single-node (Simple) deployment to HA by adding a replica after the fact if the original deployment was initialized as a standalone instance with certain configuration flags. The supported path is:

1. Deploy the primary node using the New Installation wizard.
2. Deploy the replica OVA.
3. Join the replica to the primary before or shortly after production data collection begins.

If you attempt to add a replica to a long-running standalone deployment, the join may succeed, but synchronization of historical data can take an extremely long time and may fail for very large datasets. Best practice: decide on your cluster model before initial deployment and deploy the replica immediately after the primary.

IP Address and FQDN Immutability

Once deployed, the IP address and FQDN of each node are embedded in the cluster configuration, certificates, and inter-node trust relationships. Changing the IP or FQDN of a cluster member requires:

1. Removing the node from the cluster.
2. Redeploying the OVA with the new IP/FQDN.
3. Re-joining the node to the cluster.

This is disruptive and should be avoided. Plan IP addressing and DNS naming carefully before deployment.

Cluster Node Sizing Consistency

All nodes in a cluster must use the same OVA size profile. You cannot mix a Medium primary with a Small replica or add Large data nodes to a Medium cluster. If you need to change the cluster size, you must redeploy all nodes.

Network Latency Requirements

Cluster-internal communication (xDB replication, heartbeat, GemFire cache synchronization) is latency-sensitive. All cluster nodes must be on the same Layer 2 network segment with:

• Maximum round-trip latency: < 1 ms
• Minimum bandwidth: 1 Gbps
• No stateful firewalls or WAN accelerators between cluster nodes

Violating these requirements leads to split-brain scenarios, data inconsistency, and false failover events.

Failover Behavior

When the primary node fails:

1. The replica detects the failure via missed heartbeats (default timeout: 5 minutes).
2. The replica promotes itself to primary and begins serving the UI and API.
3. All adapter collection continues without interruption (collectors reconnect to the new primary automatically).
4. When the original primary node is restored, it re-joins the cluster as the replica.

During the failover window (approximately 5 minutes), the UI is unavailable and no new alerts are generated. Metric collection continues in the collector buffer and is flushed to the cluster once the new primary is operational.

Witness Node for Continuous Availability

For environments requiring even higher availability, deploy a witness node in addition to the primary and replica. The witness participates in quorum voting to prevent split-brain scenarios but does not store analytics data or serve the UI. The witness OVA is a separate, much smaller appliance. Continuous Availability (CA) mode requires:

• 1 primary node
• 1 replica node
• 1 witness node
• Minimum 2 data nodes (added in pairs)

CA mode ensures that the cluster continues to operate with zero data loss even if one node fails completely, by maintaining a quorum and synchronous data replication across all nodes.

Chapter 6: Key Filesystem Paths and Services

This chapter provides a comprehensive reference for the filesystem layout, service architecture, and operational commands used to manage VCF Operations (Aria Operations) appliances. Understanding these paths and services is essential for troubleshooting, backup planning, and day-to-day administration.

6.1 Filesystem Paths

The VCF Operations appliance is built on Photon OS and follows a structured directory layout. The two primary mount points are the root filesystem (/) and the data partition (/storage/), which is sized according to the deployment profile selected during installation.

Note: The /storage/ partition is critical. If it reaches capacity, analytics processing halts and data collection stops. Monitor the partition with df -h /storage/ and configure alerts for filesystem utilization exceeding 85%.

6.2 Services

VCF Operations runs as a collection of interdependent services managed by systemd. The following table lists every core service, its function, and its expected default state on a healthy primary node.

6.3 Service Management Commands

All service operations must be performed as the root user via SSH or console access. The appliance supports both systemctl and legacy service command syntax.

Checking service status:

# Preferred — systemctl
systemctl status vmware-vcops-analytics

# Legacy — service wrapper
service vmware-vcops-analytics status

Starting, stopping, and restarting individual services:

# Start a service
systemctl start vmware-vcops-collector

# Stop a service
systemctl stop vmware-vcops-collector

# Restart a service (stop then start)
systemctl restart vmware-vcops-api

Querying overall cluster slice status:

/usr/lib/vmware-vcops/support/sliceConfiguration.sh --status

This command returns the role of the current node (primary, replica, data), cluster membership, and the online/offline state of each slice.

Using the Operations CLI:

$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py --help
$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py adapter list
$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py node list

Checking all VCF Operations services at once:

for svc in analytics collector api casa gemfire vpostgres cassandra watchdog web; do
  echo "=== vmware-vcops-${svc} ==="
  systemctl is-active vmware-vcops-${svc}
done

6.4 Shutdown and Startup Sequences

Correct shutdown and startup ordering is critical to avoid data corruption, split-brain scenarios, and prolonged recovery times. The required sequence varies depending on your deployment topology.

Non-HA (Single Node)

Shutdown:

# Stop all VCF Operations services
service vmware-stsd stop
service vmware-vcops stop

Startup:

# Start all VCF Operations services
service vmware-vcops start
service vmware-stsd start

Warning: Always stop vmware-stsd after vmware-vcops during shutdown, and start it before vmware-vcops during startup. Reversing this order can leave authentication tokens in an inconsistent state.

HA (High Availability — Primary + Replica)

Shutdown sequence (order matters):

1. If data nodes exist, shut down all data nodes first (in any order among themselves).
2. Shut down the replica node.
3. Shut down the primary node last.

# On each data node (if applicable):
service vmware-vcops stop && shutdown -h now

# On the replica node:
service vmware-vcops stop && shutdown -h now

# On the primary node (last):
service vmware-vcops stop && shutdown -h now

Startup sequence (reverse order):

1. Power on and start services on the primary node first.
2. Wait until the primary node UI is accessible and all services report healthy.
3. Power on and start services on the replica node.
4. Power on and start services on all data nodes.

# On the primary node (first):
service vmware-vcops start

# Verify primary is healthy before proceeding:
/usr/lib/vmware-vcops/support/sliceConfiguration.sh --status

# On the replica node (second):
service vmware-vcops start

# On each data node (last):
service vmware-vcops start

Warning: Starting the replica or data nodes before the primary is fully online will cause CASA cluster formation failures. The primary node must be the first to come online and the last to go offline.

Continuous Availability (CA)

Continuous Availability deployments include a witness node in addition to primary and replica nodes. The witness participates in quorum decisions but does not store data.

Shutdown sequence:

1. Shut down all data nodes.
2. Shut down the witness node.
3. Shut down the replica node.
4. Shut down the primary node last.

Startup sequence:

1. Start the primary node first.
2. Start the replica node.
3. Start the witness node.
4. Start all data nodes.

Warning: In a CA deployment, losing both the witness and one of the primary/replica nodes simultaneously causes a loss of quorum. Never perform maintenance on the witness and a data-bearing node at the same time. Always verify quorum status via the admin UI or sliceConfiguration.sh --status before proceeding to the next node.

Chapter 7: vCenter Adapter Configuration

The VMware vSphere adapter is the foundational integration for VCF Operations. It collects performance metrics, configuration properties, change events, and relationship data from vCenter Server and all managed objects including ESXi hosts, virtual machines, datastores, clusters, distributed switches, and resource pools. This chapter provides a complete walkthrough of credential creation, adapter instance configuration, collection tuning, and health monitoring.

7.1 Create vCenter Credentials

Before creating an adapter instance, you must configure a credential that VCF Operations will use to authenticate against the target vCenter Server.

Step-by-step procedure:

1. Log in to the VCF Operations UI as an administrator.
2. Navigate to Administration → Integrations → Accounts.
3. Click Add Account.
4. Select vCenter as the account type.
5. Complete the following fields:
   • Display Name — A human-readable label (e.g., vcsa-mgmt-01.corp.local).
   • Description — Optional description of the vCenter instance and its purpose.
6. In the Credential section, click Add Credential (or select an existing one):
   • Credential Name — e.g., svc-vrops-mgmt-01.
   • vCenter Server — Enter the FQDN of the vCenter Server (e.g., vcsa-mgmt-01.corp.local). Do not use an IP address; certificate validation requires FQDN.
   • Username — A dedicated service account (e.g., svc-vrops@vsphere.local). Never use administrator@vsphere.local in production.
   • Password — The service account password.
7. Click Validate to test the credential before saving.
8. Click Save.

Required vCenter Permissions:

The service account must be assigned a custom role at the vCenter root level with the following minimum privileges:

Best Practice: Create a dedicated vSphere role named VCF-Operations-ReadOnly with these privileges. Assign it to the service account at the vCenter root object and select Propagate to children. This ensures the adapter can discover and monitor all objects in the inventory hierarchy.

7.2 Adapter Instance Configuration

With the credential in place, create the adapter instance that will perform data collection.

1. Navigate to Administration → Integrations → Accounts.
2. Click Add Account and select vCenter.
3. Complete the following fields:

4. Expand Advanced Settings to configure optional parameters:

5. Click Validate Connection to verify connectivity.
6. Click Save to create the adapter instance.

7.3 Collection Intervals

VCF Operations collects different categories of data at different frequencies. These intervals can be modified per adapter instance, but the defaults are optimized for most environments.

Tip: In very large environments (>10,000 VMs), increasing the configuration collection interval to 60 minutes and inventory discovery to 12 hours significantly reduces API load on vCenter with minimal impact on monitoring fidelity.

7.4 Wait/Cancel Cycles and Data Maturation

After initial deployment, the adapter follows a well-defined lifecycle before full analytics capability is reached:

1. Initial Discovery (0–30 minutes): The adapter performs a complete inventory traversal, creating resource objects for every discovered entity (hosts, VMs, clusters, datastores, etc.). The Object Count in the adapter status begins to populate.

2. First Collection Cycle (5–10 minutes after discovery): Performance metrics and configuration properties are collected for the first time. Metrics begin appearing in dashboards, but values are raw with no baseline context.

3. Statistics Build-Up (24–72 hours): The analytics engine begins calculating rolling averages, standard deviations, and trend lines. Capacity projections begin to appear, but with low confidence.

4. Dynamic Thresholds (1–2 weeks): After accumulating approximately one to two weeks of continuous data, the analytics engine generates dynamic thresholds (DT). These adaptive baselines learn normal behavior patterns for each metric on each object, including daily and weekly seasonality. Alerts based on dynamic thresholds become meaningful only after this maturation period.

5. Steady State (2+ weeks): Dynamic thresholds are fully established. Anomaly detection, predictive alerts, and capacity forecasts operate at full accuracy. The system continues to refine thresholds as it accumulates more historical data.

Important: Do not create custom alert definitions based on dynamic thresholds during the first two weeks. The immature thresholds will generate excessive false positives. Use static thresholds for immediate alerting needs during the burn-in period.

7.5 Test Connection and Initial Discovery

After saving the adapter instance, perform the following validation steps:

1. Test Connection: On the adapter configuration page, click Test Connection. A successful test confirms:

   • Network connectivity from the collector to the vCenter Server on port 443.
   • Credential validity (username and password accepted).
   • SSL certificate trust (the vCenter certificate is trusted by the collector's trust store).

2. Monitor Discovery Progress:

   • Navigate to Administration → Integrations → Accounts.
   • Locate the adapter instance card. The status indicator transitions through:
     • Grey (Unknown) — Adapter has not yet started.
     • Yellow (Collecting) — Discovery or collection is in progress.
     • Green (Receiving Data) — Successful collection cycles are completing.
     • Red (Not Receiving Data) — Collection failures detected.
   • Click the adapter card to view the Collection State and Collection Status details.

3. Verify Object Counts:

   • Navigate to Environment → Inventory → Object Browser.
   • Filter by adapter instance name.
   • Confirm that the discovered object count is consistent with the vCenter inventory (e.g., if vCenter manages 200 VMs, approximately 200 Virtual Machine objects should appear).

4. Check Adapter Logs:

   tail -100 /storage/log/collector/collector.log | grep -i "VMware_adapter3"
   

   Look for Collection completed successfully messages and verify there are no authentication errors or timeout exceptions.

7.6 Monitoring Adapter Health

Ongoing adapter health monitoring ensures continuous data collection and early detection of integration failures.

Via REST API:

# Get adapter instance status
curl -sk -X GET \
  "https://<vrops-fqdn>/suite-api/api/adapters/{adapterId}" \
  -H "Authorization: vRealizeOpsToken <token>" \
  -H "Accept: application/json"

The response includes resourceStatusAndReason, where:

• resourceStatus: DATA_RECEIVING — Healthy.
• resourceStatus: NO_DATA_RECEIVING — Collection failures occurring.
• resourceStatus: NO_PARENT_MONITORING — Collector node offline.
• resourceStatus: UNKNOWN — Adapter has not completed its first cycle.

Via CLI:

$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py adapter list

This outputs all configured adapter instances, their types, collection states, and associated collector nodes.

Via UI:

1. Navigate to Administration → Integrations → Repository.
2. Each adapter is displayed as a card with a color-coded status indicator.
3. Click an adapter card to view:
   • Last Collection Time — Timestamp of the most recent successful collection.
   • Object Count — Number of discovered and monitored resources.
   • Collection Duration — Time taken for the last collection cycle.
   • Error Messages — Any warnings or errors from recent cycles.

Common adapter health issues and resolutions:

Chapter 8: SDDC Manager Integration

SDDC Manager is the lifecycle management control plane for VMware Cloud Foundation. Integrating VCF Operations with SDDC Manager provides domain-level topology awareness, lifecycle status visibility, and operational context that enriches the analytics engine's understanding of the VCF stack.

8.1 Configuration

Step-by-step procedure:

1. Log in to the VCF Operations UI as an administrator.
2. Navigate to Administration → Integrations → Accounts.
3. Click Add Account.
4. Select SDDC Manager from the account type list.
5. Complete the following fields:
   • Display Name — A descriptive label (e.g., sddc-mgr-01.corp.local).
   • Description — Optional. Describe the VCF instance this SDDC Manager controls.
   • SDDC Manager FQDN — The fully qualified domain name of the SDDC Manager appliance (e.g., sddc-mgr-01.corp.local). Use the FQDN, not the IP address.
   • Credential — Click Add Credential and enter:
     • Username — An SDDC Manager user with at least the ADMIN or OPERATOR role (e.g., svc-vrops@corp.local).
     • Password — The corresponding password.
6. Click Test Connection to validate connectivity and credentials.
7. Click Save.

Note: The SDDC Manager API uses port 443. Ensure that firewall rules allow HTTPS traffic from the VCF Operations collector node to the SDDC Manager appliance.

8.2 What the Adapter Collects

Once configured, the SDDC Manager adapter automatically discovers and monitors the following data:

• VCF Domain Topology — Management domain and all workload domains, including their constituent clusters, hosts, and networking configuration.
• Workload Domain Health — Aggregate health status of each workload domain based on component availability and configuration drift.
• Component Versions and Lifecycle Status — Current installed versions and available updates for vCenter, ESXi, NSX, and vSAN across all domains.
• Host Commission/Decommission Events — Tracks when physical hosts are added to or removed from the SDDC Manager inventory, including the associated workflow status.
• Certificate Status — Expiration dates and validity status for certificates managed by SDDC Manager, enabling proactive renewal alerting.
• Upgrade and Patch Compliance — Identifies domains and clusters that are behind on recommended update bundles.
• Network Pool Utilization — Tracks consumption of IP pools and VLAN assignments managed by SDDC Manager.

8.3 SDDC Manager REST API Endpoints Used

The adapter communicates with the SDDC Manager via its published REST API. The following table lists the key endpoints queried during each collection cycle:

Tip: If the SDDC Manager adapter reports errors for specific endpoints, verify that the service account has sufficient privileges. The ADMIN role provides access to all endpoints; the OPERATOR role may restrict access to certain lifecycle operations.

Chapter 9: NSX Integration

NSX provides the network virtualization and security layer in VMware Cloud Foundation. Integrating VCF Operations with NSX delivers visibility into logical networking constructs, transport infrastructure, distributed firewall activity, and load balancer performance — all correlated with the compute and storage metrics collected by the vSphere adapter.

9.1 Configuration

Step-by-step procedure:

1. Log in to the VCF Operations UI as an administrator.
2. Navigate to Administration → Integrations → Accounts.
3. Click Add Account and select NSX-T from the account type list.
4. Complete the following fields:
   • Display Name — A descriptive label (e.g., nsx-mgmt-01.corp.local).
   • Description — Optional. Describe the NSX deployment and its associated VCF domain.
   • NSX Manager FQDN — Enter the Virtual IP (VIP) of the NSX Manager cluster (e.g., nsx-vip-mgmt.corp.local). This is critical — see the note below.
   • Credential — Click Add Credential and enter:
     • Username — A service account with the audit role (e.g., svc-vrops-nsx@corp.local) or the enterprise_admin role for full visibility. The audit role is recommended for least-privilege compliance.
     • Password — The corresponding password.
   • Collector / Collector Group — Select the appropriate collector. For cross-site deployments, choose a collector local to the NSX Manager.
5. Click Test Connection to verify connectivity and authentication.
6. Click Save.

Warning: Always use the NSX Manager VIP (Virtual IP), not the FQDN of an individual NSX Manager node. The NSX Manager cluster operates as a three-node Raft consensus group. During maintenance, node upgrades, or node failures, individual manager nodes become temporarily unavailable. The VIP automatically directs traffic to a healthy node, ensuring uninterrupted data collection. Configuring the adapter with an individual node address will result in collection outages during any node maintenance event.

9.2 What the Adapter Collects

The NSX-T adapter collects a comprehensive set of networking and security data:

• Logical Switches and Segments — Segment name, VLAN/overlay type, admin state, connected VMs, and traffic statistics (packets in/out, bytes in/out, drops).
• Transport Zones — Overlay and VLAN transport zone membership, host participation, and configuration status.
• Transport Nodes — ESXi host and Edge node transport connectivity status, TEP (Tunnel Endpoint) IP addressing, and N-VDS configuration.
• Edge Clusters and Edge Nodes — Edge cluster membership, deployment status (active/standby), CPU/memory/NIC utilization, and service deployment (T0/T1 routers, load balancers).
• Distributed Firewall (DFW) — Rule count per section, rule hit counts, session counts, connection rates, and dropped packet counts. Enables identification of unused rules and overly permissive policies.
• Gateway Firewall — North-south firewall statistics on Tier-0 and Tier-1 gateways.
• Load Balancer Statistics — Virtual server status, pool member health, active sessions, throughput, and connection rate for NSX load balancer instances.
• BGP and Routing — BGP neighbor status (established/active/idle), route table size, and routing protocol convergence events on Tier-0 gateways.
• NSX Manager Cluster Health — Cluster status (STABLE, DEGRADED, UNSTABLE), individual node health, API responsiveness, and Corfu database replication state.
• Alarms and System Events — NSX-generated alarms covering certificate expiry, control plane connectivity, and transport node preparation failures.

9.3 VCF Operations for Networks (Overview)

In addition to the built-in NSX adapter, VMware offers VCF Operations for Networks (formerly known as Aria Operations for Networks, or vRealize Network Insight) as a complementary product for deep network visibility. While the NSX adapter focuses on management-plane metrics, VCF Operations for Networks provides data-plane flow analysis.

Deployment model:

• Requires two OVA appliances:
  • Platform OVA — The analytics engine and web UI (minimum: 8 vCPU, 32 GB RAM, 2 TB disk).
  • Collector OVA — Deployed near each data source to collect NetFlow/IPFIX, syslog, SNMP, and API data (minimum: 4 vCPU, 16 GB RAM, 200 GB disk).
• Multiple collectors can feed a single platform for multi-site coverage.

Key capabilities:

• Flow-Level Visibility — Analyzes NetFlow/IPFIX data from physical switches and ESXi hosts to map all east-west and north-south traffic flows.
• Micro-Segmentation Planning — Recommends NSX DFW rules based on observed traffic patterns, accelerating zero-trust network implementation.
• Network Topology Maps — Auto-generated visual maps showing physical-to-virtual network paths, including underlay switch topology (via LLDP/CDP), overlay segments, and VM-to-VM connectivity.
• Application Discovery — Groups VMs into application tiers based on observed communication patterns.
• Path Tracing — Traces the complete network path between any two endpoints, identifying every hop, firewall rule, and load balancer in the path.
• Integration with VCF Operations Dashboards — Network topology and flow data can be surfaced in VCF Operations dashboards via cross-launch links and shared context.

Note: VCF Operations for Networks is licensed separately from VCF Operations. In VCF 5.x environments, it is included with the VCF Operations Advanced and Enterprise editions.

Chapter 10: vSAN Integration

VMware vSAN is the hyper-converged storage platform embedded in VCF. VCF Operations provides native vSAN monitoring through the vSphere adapter, delivering capacity analytics, performance trending, health correlation, and policy compliance tracking without requiring a separate adapter installation.

10.1 Automatic via vSphere Adapter

vSAN monitoring is automatically activated when the vCenter adapter discovers one or more vSAN-enabled clusters. No additional adapter installation, configuration, or licensing is required for core vSAN metrics.

Prerequisites for automatic vSAN data collection:

• The vCenter adapter must be configured and actively collecting data (see Chapter 7).
• vSAN Health Service must be enabled in vCenter. Verify by navigating to the vSAN cluster in vSphere Client → Monitor → vSAN → Health and confirming that health checks are running.
• vSAN Performance Service must be enabled on the vSAN cluster. Navigate to vSphere Client → select the vSAN cluster → Configure → vSAN → Performance Service → ensure it is turned on and a network-accessible database is configured.
• The VCF Operations service account must have the vSAN → Cluster → ReadOnly privilege (included in the role defined in Section 7.1).

Once these prerequisites are met, VCF Operations automatically creates resource objects for:

• vSAN Cluster
• vSAN Disk Groups
• vSAN Disks (cache and capacity tiers)
• vSAN Hosts (storage perspective)
• vSAN Virtual Machine Storage Objects

10.2 Advanced vSAN Configuration

For environments requiring deeper vSAN observability, additional collection parameters can be enabled in the vCenter adapter instance's advanced settings.

Navigate to Administration → Integrations → Accounts → select the vCenter adapter → Edit → expand Advanced Settings:

Warning: Enabling COLLECT_VSAN_ADVANCED_METRICS on clusters with more than 32 hosts or heavy I/O workloads can significantly increase vCenter API response times and VCF Operations collection duration. Enable this setting selectively and monitor the adapter collection duration (see Section 7.6) after activation.

Additional vSAN Performance Service requirements:

• The Performance Service stores statistics in the vSAN datastore itself. Ensure that the vSAN datastore has sufficient free capacity (at minimum 256 GB free) to accommodate the performance database.
• The Performance Service network must be reachable from all hosts in the cluster. In stretched cluster configurations, verify that both sites can access the Performance Service host.

10.3 Key vSAN Metrics Collected

VCF Operations collects hundreds of vSAN metrics. The following table summarizes the most operationally significant metric groups:

10.4 vSAN Dashboards

VCF Operations ships with a comprehensive set of predefined vSAN dashboards that provide immediate operational visibility without custom configuration. These dashboards cover:

• vSAN Cluster Overview — High-level health, capacity, and performance summary for all vSAN clusters.
• vSAN Capacity Planning — Trending and forecasting of vSAN capacity consumption with time-to-exhaustion projections.
• vSAN Performance — Real-time and historical IOPS, throughput, and latency visualization at cluster, host, and disk group levels.
• vSAN Resync Monitoring — Active resync operations, progress tracking, and estimated completion times.
• vSAN Health Deep Dive — Detailed health check results correlated with related events and configuration changes.
• vSAN VM Storage Policy Compliance — Identifies VMs with non-compliant storage objects and correlates compliance violations with capacity or host availability changes.

For a complete listing of all predefined vSAN dashboards, their widget configurations, and customization guidance, refer to Chapter 14: Predefined Dashboards and Views.

Tip: Pin the vSAN Cluster Overview and vSAN Capacity Planning dashboards to your home page for daily operational monitoring. Configure email-based scheduled reports from the vSAN Capacity Planning dashboard to automatically distribute weekly capacity status to infrastructure leads.

Chapter 11: Policies

Policies in VCF Operations govern how the platform analyzes, alerts on, and reports capacity for your monitored objects. Every object in the inventory is subject to exactly one policy at any given time, and understanding how policies layer and override one another is essential for accurate monitoring at scale.

11.1 Default Policy vs Custom Policies

VCF Operations ships with a single Default Policy that is automatically applied to every monitored object in the inventory. This policy contains Broadcom's recommended thresholds, alert definitions, symptom definitions, and capacity settings for all supported object types. It cannot be deleted, and it serves as the fallback for any object not explicitly covered by a custom policy.

Custom policies allow administrators to override specific settings from the Default Policy for targeted groups of objects. A custom policy does not need to redefine every setting — it inherits any setting left unconfigured from the Default Policy and only overrides the values explicitly changed.

To manage policies, navigate to:

Configure → Policies

The Policies page displays all active policies in a table with columns for Name, Description, Priority, and the number of object groups assigned. From this page you can:

• Add a new custom policy
• Clone an existing policy (including the Default Policy) to use as a starting template
• Edit a custom policy's settings
• Delete a custom policy (objects revert to the Default Policy)
• View which object groups are assigned to each policy

Note: The Default Policy itself can be edited, but exercise caution — changes to the Default Policy affect every object that is not covered by a higher-priority custom policy.

11.2 Policy Priority and Inheritance

When multiple custom policies exist, VCF Operations uses a numeric priority system to determine which policy governs a given object. Each policy is assigned a priority number, and lower numbers indicate higher priority.

Policy resolution follows this logic:

1. VCF Operations evaluates all custom policies in ascending priority order (lowest number first).
2. For each policy, it checks whether the object belongs to any of the policy's assigned object groups.
3. The first matching policy (lowest priority number) wins and governs the object.
4. If no custom policy matches, the Default Policy applies.

If an object belongs to groups assigned to multiple policies, only the highest-priority policy (lowest number) applies. There is no merging of settings across policies — the winning policy's settings apply in full, with any unconfigured settings inherited from the Default Policy.

To change priority, navigate to Configure → Policies, select a policy, and click Edit Priority. Enter the desired numeric value and save.

11.3 Configurable Elements

Each policy exposes five major configuration areas. The following sections detail every configurable element, its UI navigation path, and key settings.

11.3.1 Workload Automation

Navigation: Configure → Policies → [Policy Name] → Edit → Workload Automation

Workload Automation enables DRS-like optimization recommendations (or automated actions, if configured) driven by VCF Operations analytics rather than vCenter DRS alone.

11.3.2 Capacity Settings

Navigation: Configure → Policies → [Policy Name] → Edit → Capacity

Capacity settings control how VCF Operations calculates remaining capacity and time-to-exhaustion.

11.3.3 Attributes and Metrics

Navigation: Configure → Policies → [Policy Name] → Edit → Attributes/Metrics

This section allows enabling or disabling the collection of specific metric groups per object type. Disabling unused metric groups reduces storage consumption and processing overhead.

Categories include CPU, Memory, Disk, Network, Datastore, Virtual Disk, GPU, vSAN, and System metrics. Each category can be individually toggled.

11.3.4 Alerts and Symptoms

Navigation: Configure → Policies → [Policy Name] → Edit → Alerts/Symptoms

Administrators can enable or disable individual alert definitions and symptom definitions within the scope of the policy. This is useful for suppressing alerts that are not relevant to a particular workload tier — for example, disabling memory overcommit alerts for development clusters where overcommit is expected.

11.3.5 Compliance

Navigation: Configure → Policies → [Policy Name] → Edit → Compliance

Activate or deactivate compliance benchmarks on a per-policy basis. Available benchmarks include VMware Security Hardening Guide, CIS Benchmarks, DISA STIGs, and any custom benchmarks that have been imported.

11.4 Allocation vs Demand Model

The capacity model determines how VCF Operations calculates how much capacity a cluster or datastore has remaining.

11.5 Best Practices

• Create separate policies for Production and Dev/Test. Production policies should use the Allocation Model with conservative overcommit ratios (CPU 4:1, Memory 1:1). Dev/Test policies can use the Demand Model with higher overcommit ratios (CPU 8:1, Memory 2:1).
• Use object groups to target policies precisely. Define groups using vCenter folder structure, tags, or custom properties rather than manually adding individual objects.
• Keep the number of custom policies manageable. Aim for 3–5 policies that align with your operational tiers, not dozens of niche policies.
• Review priority order quarterly. As new policies are added, verify that priority ordering still reflects the intended precedence.
• Test policy changes on a small group first. Clone a policy, apply it to a test group, monitor for 24–48 hours, then promote to production scope.
• Document your policies. Use the Description field in each policy to record the rationale, the approver, and the date of last review.

Chapter 12: Alerts and Symptoms

Alerts and symptoms form the proactive monitoring backbone of VCF Operations. Symptoms detect individual conditions; alerts correlate one or more symptoms into actionable notifications that drive operational response.

12.1 Understanding Alerts

Every alert in VCF Operations is classified along three dimensions: type, criticality, and control state.

Alert Types:

Badge Colors and Criticality Levels:

Control States:

When all triggering symptoms clear, the alert automatically transitions to a cancelled state. Manually cancelled alerts will not re-fire until the symptoms clear and then trigger again.

12.2 Alert Lifecycle

The alert lifecycle follows a deterministic sequence:

1. Symptom Detection — A metric crosses a threshold, a log message matches a pattern, or a fault event arrives. The symptom condition evaluates to TRUE.
2. Wait Cycles — If configured, the symptom must remain TRUE for the specified number of collection cycles (each cycle is typically 5 minutes) before it activates.
3. Symptom Activation — The symptom transitions to an active state.
4. Alert Evaluation — The alert definition checks whether its symptom combination logic (ALL or ANY) is satisfied.
5. Alert Fires — The alert appears on the object's alert list with the configured criticality and type.
6. Notification — If a notification rule matches the alert's attributes (type, criticality, object type), the configured notification method is triggered (email, webhook, SNMP trap, etc.).
7. Admin Review — An administrator views the alert in Alerts → Triggered Alerts or receives the notification.
8. Assignment — The administrator changes the control state to Assigned, taking ownership.
9. Resolution — The administrator resolves the underlying issue.
10. Auto-Cancellation — When all triggering symptoms clear, VCF Operations automatically cancels the alert. Alternatively, the administrator can manually cancel the alert.

Alerts can also be suspended for a configurable duration (e.g., during a maintenance window), after which they automatically resume evaluation.

12.3 Creating Alert Definitions

To create a custom alert definition, follow these steps:

Step 1. Navigate to Configure → Alerts → Alert Definitions.

Step 2. Click the Add button in the toolbar.

Step 3. On the Name and Description tab:

• Enter a descriptive Name (e.g., "Production VM CPU Saturation").
• Provide a Description explaining the alert's purpose and recommended remediation.
• Select the Base Object Type from the dropdown (e.g., Virtual Machine, Host System, Cluster Compute Resource). This determines which objects can trigger the alert.

Step 4. On the Alert Impact tab:

• Select the Alert Type: Health, Risk, or Efficiency.
• Set the Criticality: Critical, Immediate, Warning, or Information.
• Choose the Impact Area: Availability, Performance, Capacity, or Compliance.

Step 5. On the Add Symptom Definitions tab:

• Browse or search the symptom catalog in the left panel.
• Drag one or more symptom definitions into the alert canvas.
• Alternatively, click Create Symptom Definition to build a new symptom inline (see Section 12.4).

Step 6. On the Configure Symptom Conditions section:

• Set the combination logic:
  • ALL — All listed symptoms must be active simultaneously for the alert to fire.
  • ANY — Any single symptom being active will fire the alert.
• Configure Wait Cycles for each symptom (recommended: 3–5 cycles to reduce false positives).
• Optionally set Cancel Cycles — the number of cycles a symptom must remain clear before the alert cancels.

Step 7. Click Save. The alert definition is now created but will only evaluate against objects governed by a policy where the alert is enabled.

12.4 Symptom Definitions

Symptoms are the atomic conditions that feed into alert definitions. VCF Operations supports five distinct symptom types.

12.4.1 Metric/Property Symptom

Triggers when a monitored metric or property meets a defined condition.

Static Threshold Configuration:

• Select Object Type and Metric (e.g., Virtual Machine → CPU → Usage Average %).
• Choose Operator: >, <, >=, <=, =, !=.
• Enter a fixed threshold value (e.g., 90).
• Set Wait Cycles and Cancel Cycles.

Dynamic Threshold Configuration:

• Select Object Type and Metric.
• Choose Trend Direction: Above or Below.
• Choose Threshold Sensitivity:
  • Normal Range — triggers when outside the learned normal operating band.
  • 1 Standard Deviation (1 sigma) — moderate sensitivity.
  • 2 Standard Deviations (2 sigma) — low sensitivity (fewer false positives).
  • 3 Standard Deviations (3 sigma) — very low sensitivity (only extreme deviations).
• VCF Operations requires 1–2 weeks of data collection to establish baselines.

12.4.2 Message Event Symptom

Triggers when a log message matches a defined pattern. This symptom type requires Operations for Logs integration.

• Define the Log Message Pattern using regex or keyword matching.
• Select the Log Source (e.g., syslog, application log).
• Set the Severity Level filter (Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug).
• Optionally filter by Facility or Application Name.

12.4.3 Fault Event Symptom

Triggers on fault events published by vCenter Server or other adapter sources.

• Select the Event Type from the catalog of known vCenter events (e.g., VmPoweredOffEvent, HostConnectionLostEvent).
• Optionally filter by Event Message content.
• Fault event symptoms fire immediately upon event receipt — wait cycles are typically not applicable.

12.4.4 Metric Event Symptom

Triggers on metric events published by external systems through the VCF Operations REST API.

• Define the Event Type identifier.
• Set matching criteria on event attributes.
• Used primarily for integration with third-party monitoring tools that push events into VCF Operations.

12.4.5 Smart Early Warning

Predictive symptom that uses machine-learning trend analysis to forecast when a metric will cross a threshold.

• Select the Metric to monitor.
• Define the Threshold Value that the prediction targets.
• Set the Forecast Window (e.g., 7 days, 14 days, 30 days).
• VCF Operations projects the metric's trajectory and fires the symptom if the forecast indicates the threshold will be breached within the window.

12.5 Static vs Dynamic Thresholds

Dynamic Threshold Sensitivity Levels:

12.6 Relationship Types for Symptom Evaluation

Alert definitions can include symptoms that evaluate conditions not only on the alerting object itself but also on related objects in the inventory hierarchy.

Relationship-based symptoms enable compound alerts that correlate conditions across infrastructure layers — for example, an alert that fires only when a VM has high CPU ready AND its parent host has high CPU utilization, confirming the contention is host-driven rather than guest-driven.

12.7 Alert Definition Best Practices

• Avoid duplicating built-in alerts. VCF Operations includes hundreds of predefined alert definitions. Before creating a custom alert, search the existing catalog to confirm no equivalent exists.
• Use wait cycles to reduce false positives. A wait cycle count of 3–5 (representing 15–25 minutes at the default 5-minute collection interval) filters out transient spikes. Reserve zero wait cycles for truly critical conditions like host disconnection.
• Combine multiple symptoms for meaningful alerts. A single symptom (e.g., CPU > 80%) in isolation may generate noise. Pairing it with a second symptom (e.g., CPU Ready > 5%) creates a more meaningful alert that confirms actual contention.
• Prefer ALL logic for compound conditions. Use ANY logic only when multiple independent indicators should each independently warrant attention.
• Test in a limited scope first. Create a test policy, assign it to a small object group, enable the new alert definition only in that policy, and observe behavior for several days before rolling it out broadly.
• Document remediation steps in the Description field. Include specific actions the operations team should take when the alert fires. This turns the alert into a self-service runbook entry.
• Set appropriate criticality levels. Reserve Critical for service-impacting conditions. Overuse of Critical erodes trust in the alerting system.

12.8 Notification Rules

Notification rules bridge alerts to human attention by defining what gets communicated, to whom, and through which channel.

Step 1. Navigate to Configure → Alerts → Notification Settings.

Step 2. Click Add to create a new notification rule.

Step 3. Enter a Name for the rule (e.g., "Critical Production Alerts to On-Call Team").

Step 4. Set Filter Criteria to control which alerts trigger this notification:

• Alert Type: Health, Risk, Efficiency, or All.
• Criticality: Critical, Immediate, Warning, Information, or All.
• Object Type: Filter to specific object types (e.g., only Host System alerts).
• Alert Definitions: Optionally select specific alert definitions by name.
• Object Groups: Limit to objects in specific groups.

Step 5. Select the Notification Method — choose from the configured outbound plug-ins (see Section 12.9).

Step 6. Set Notification Frequency:

• Immediate — sends notification as soon as the alert fires.
• Hourly Digest — batches all matching alerts into a single hourly summary.
• Daily Digest — batches all matching alerts into a single daily summary.

Step 7. Click Save. The notification rule takes effect immediately.

Tip: Create separate notification rules for different criticality levels. Route Critical alerts to PagerDuty or SMS-capable channels for immediate response, while routing Warning alerts to email or Slack for informational awareness.

12.9 Outbound Notification Plug-ins

Outbound plug-ins define the communication channels available for notification rules. Configure them at Administration → Outbound Settings → Add.

Configuration procedure for each plug-in type:

1. Navigate to Administration → Outbound Settings.
2. Click Add.
3. Select the Plug-in Type from the dropdown.
4. Enter an Instance Name (e.g., "Production SMTP Server").
5. Fill in the required configuration fields (per the table above).
6. Click Test to send a test notification and verify connectivity.
7. Click Save.

Each plug-in type can have multiple instances configured (e.g., separate SMTP servers for different environments, multiple Slack channels). Notification rules reference specific plug-in instances when defining the delivery channel.

Chapter 13: Super Metrics

Super metrics extend the analytic capabilities of VCF Operations by enabling administrators to define custom calculated metrics that combine, aggregate, or transform multiple standard metrics into a single derived value. They fill gaps where the built-in metric catalog does not provide the exact calculation your organization needs.

13.1 What Are Super Metrics

A super metric is a user-defined formula that VCF Operations evaluates on every collection cycle, producing a new metric value that can be used in dashboards, views, reports, alert symptom definitions, and capacity calculations — just like any native metric.

Common use cases:

• Weighted averages across clusters — Calculate a cluster-wide average that weights each host's contribution by its capacity rather than treating all hosts equally.
• Ratio calculations — Compute overcommit ratios, efficiency ratios, or utilization-to-capacity percentages not available natively.
• Cross-object aggregations — Sum or average a metric across all children of a parent object (e.g., total memory consumed by all VMs in a resource pool).
• Conditional calculations — Apply different formulas based on object properties (e.g., calculate differently for powered-on vs powered-off VMs).
• Business-level KPIs — Create metrics that map infrastructure telemetry to business-relevant indicators.

To access super metrics, navigate to: Configure → Super Metrics.

13.2 Creating a Super Metric

Follow this ten-step procedure to create a super metric:

Step 1. Navigate to Configure → Super Metrics.

Step 2. Click the Add button in the toolbar.

Step 3. Enter a Name for the super metric (e.g., "Cluster - Avg VM CPU Usage (Powered-On Only)"). Enter an optional Description explaining the formula's purpose and intended consumers.

Step 4. Select the Object Type that this super metric will be associated with. The super metric will appear as a metric on objects of this type. For example, selecting "Cluster Compute Resource" means the super metric will be calculated and displayed for each cluster.

Step 5. Build the formula in the Formula Editor. The editor provides a text area where you type or construct the formula using metric references, operators, and functions.

Step 6. Use the Metric Picker (right panel) to browse or search the available metric catalog. Double-click a metric to insert its reference into the formula. The metric reference is inserted in the syntax ${this, metric=<metric_key>}.

Step 7. Apply looping functions to iterate over child objects. For example, wrap a metric reference in avg() to compute the average value of that metric across all child objects at a specified depth. See Section 13.3 for the complete list of looping functions.

Step 8. Click the Preview button to validate the formula syntax and see sample results. The preview evaluates the formula against a few sample objects and displays the computed values. Fix any syntax errors before proceeding.

Step 9. Assign the super metric to a policy. A super metric only collects data when it is activated in at least one policy. Navigate to the Policies tab within the super metric editor, or go to Configure → Policies → [Policy Name] → Edit → Attributes/Metrics and enable the super metric under the appropriate object type.

Step 10. Click Save. The super metric begins collecting data on the next collection cycle for all objects governed by the policy where it is activated.

Important: Super metrics do not retroactively calculate historical data. Data collection begins from the moment the super metric is activated in a policy.

13.3 Looping Functions

Looping functions iterate over child objects (or related objects at a specified depth) and aggregate a metric across them.

The depth parameter controls how many levels down the hierarchy to traverse:

• depth=1 — direct children only (e.g., VMs directly under a host).
• depth=2 — children and grandchildren (e.g., VMs under hosts under a cluster).
• Omitting depth defaults to depth=1.

13.4 Single Functions

Single functions operate on individual numeric values within the formula.

13.5 Operators

Super metric formulas support the following operators:

Numeric Operators:

Comparison Operators:

Logical Operators:

String Operators:

13.6 Formula Syntax Deep Dive

The depth Parameter

The depth parameter specifies how many levels of the object hierarchy to traverse when using looping functions:

• depth=0 — the current object itself (no looping).
• depth=1 — direct children (e.g., for a cluster: hosts; for a host: VMs).
• depth=2 — grandchildren (e.g., for a cluster: VMs through hosts).
• Higher values traverse deeper, but performance impact increases with depth.

The where Clause

The where clause filters child objects by a property value before aggregation:

avg(${this, metric=cpu|usage_average, depth=1, where=Summary|Guest Operating System=.*Linux.*})

This calculates the average CPU usage only for child VMs whose guest OS name matches the regex .*Linux.*.

The where clause supports:

• Exact match: where=Summary|Runtime|PowerState=Powered On
• Regex match: where=config|name=.*prod.*
• Numeric comparison within the where context: where=cpu|usage_average > 50

The isFresh() Function

isFresh() checks whether a metric has received data within the most recent collection cycle. It returns 1 if fresh data exists, 0 otherwise. This is useful for conditionally including only actively-reporting objects:

sum(${this, metric=mem|consumed_average, depth=1, where=isFresh(mem|consumed_average)})

Aliases (Variable Assignment)

Intermediate calculations can be assigned to aliases for readability:

alias cpuTotal = sum(${this, metric=cpu|usagemhz_average, depth=1})
alias cpuCapacity = ${this, metric=cpu|capacity_usagemhz}
cpuTotal / cpuCapacity * 100

Ternary Expressions

Use ternary syntax for conditional logic:

${this, metric=cpu|usage_average} > 80 ? 1 : 0

This returns 1 if CPU usage exceeds 80%, otherwise returns 0 — useful for creating "count of objects exceeding threshold" super metrics when combined with sum().

13.7 Use Cases and Examples

The following real-world examples demonstrate practical super metric formulas.

Example 1: Average VM CPU Usage Across a Cluster (Windows VMs Only)

Object Type: Cluster Compute Resource

avg(${this, metric=cpu|usage_average, depth=2, where=Summary|Guest Operating System=.*Windows.*})

This formula traverses two levels deep from the cluster (cluster → host → VM), filters to only Windows VMs, and calculates the average CPU usage across all matching VMs in the cluster.

Example 2: Total Memory Consumed by Powered-On VMs

Object Type: Cluster Compute Resource

sum(${this, metric=mem|consumed_average, depth=2, where=Summary|Runtime|PowerState=Powered On})

This formula sums the consumed memory metric across all VMs in the cluster that are currently powered on, giving an accurate picture of active memory demand.

Example 3: Count of VMs with CPU Ready Exceeding Threshold

Object Type: Host System

count(${this, metric=cpu|readyPct, depth=1, where=cpu|readyPct > 2.5})

This formula returns the number of VMs on a host where the CPU Ready percentage exceeds 2.5%, providing a single metric that indicates how many VMs on the host are experiencing CPU scheduling contention.

Example 4: Cluster CPU Overcommit Ratio

Object Type: Cluster Compute Resource

sum(${this, metric=cpu|num_vcpus_latest, depth=2}) / sum(${this, metric=cpu|corecount_provisioned, depth=0})

This formula divides the total number of vCPUs allocated across all VMs in the cluster (depth=2 to traverse through hosts to VMs) by the total physical core count of the cluster itself (depth=0 for the cluster's own metric), producing the vCPU-to-pCPU overcommit ratio.

Chapter 14: Dashboards — Built-in (Predefined)

VCF Operations ships with an extensive library of predefined dashboards that provide immediate visibility into the health, performance, capacity, and efficiency of your virtual infrastructure. These dashboards represent Broadcom's best-practice views and serve as both operational tools and templates for custom dashboard development.

14.1 Accessing Predefined Dashboards

To access predefined dashboards:

1. Navigate to Visualize → Dashboards.
2. The left navigation panel displays dashboard categories as expandable folders.
3. Click a category to expand it and reveal the dashboards within.
4. Click a dashboard name to load it in the main content area.

Predefined dashboards are read-only — they cannot be modified directly. To customize a predefined dashboard:

1. Open the dashboard you wish to modify.
2. Click the Actions menu (three dots or gear icon) in the top-right corner.
3. Select Clone.
4. Enter a name for the cloned copy.
5. The cloned dashboard opens in edit mode, where all widgets and configurations can be freely modified.

Dashboards can be marked as Favorites (star icon) for quick access from the Favorites section of the left panel. The Home Dashboard can be set by navigating to Visualize → Dashboards → Actions → Set as Home Dashboard.

14.2 Complete List of Predefined Dashboards

Performance Category

Capacity Category

Cost Category

Availability Category

Sustainability Category

NSX Category

Other Categories

14.3 KPI Thresholds

The following table provides industry-standard threshold guidance for key performance indicators. These values are used by many of the predefined dashboards and alert definitions.

14.4 Dashboard Time Settings

All dashboards support configurable time ranges and refresh intervals that control the data window displayed by widgets.

Time Range Options:

The time range selector is located in the top-right toolbar of every dashboard. Changing the time range affects all time-aware widgets on the dashboard simultaneously.

Auto-Refresh Intervals:

The auto-refresh toggle is located next to the time range selector. For dashboards displayed on NOC wall screens, set auto-refresh to 5 minutes to maintain near-real-time visibility.

Note: Setting aggressive auto-refresh intervals on dashboards with many widgets or large object scopes may increase load on the VCF Operations analytics cluster. For environments with more than 10,000 objects, consider using 10- or 15-minute refresh intervals for complex dashboards.

Chapter 15: Dashboards — Custom Creation

While the predefined dashboards cover a broad range of operational scenarios, custom dashboards enable you to build views tailored to your organization's specific monitoring requirements, operational workflows, and reporting needs.

15.1 Creating a Dashboard

Follow these steps to create a new custom dashboard:

Step 1. Navigate to Visualize → Dashboards.

Step 2. Click the Create button in the top toolbar (or use the + icon).

Step 3. Enter a Dashboard Name (e.g., "Production Cluster Health — Tier 1").

Step 4. Optionally select a Dashboard Template from the dropdown. Templates provide pre-arranged widget layouts that you can populate with your own data sources. Available templates include Blank Canvas, Two-Column, Three-Column, Executive Summary, and Troubleshooting.

Step 5. Set the Default Time Range for the dashboard (e.g., Last 6 Hours). Individual widgets can override this if needed.

Step 6. Click Save. The empty dashboard canvas appears in edit mode, ready for widgets to be added.

To add widgets:

1. Click the Add Widget button (or drag from the widget panel on the left).
2. Select the desired widget type from the catalog (see Section 15.2).
3. Configure the widget (see Section 15.3).
4. Position and resize the widget on the canvas by dragging.
5. Repeat for additional widgets.
6. Click Save when the layout is complete.

15.2 Complete Widget Catalog

VCF Operations provides a comprehensive widget catalog organized by functional category.

Data Visualization Widgets

Object List Widgets

Utility Widgets

15.3 Widget Configuration Deep Dive

Scoreboard Widget

The Scoreboard widget is the most commonly used widget for executive dashboards and NOC displays.

Configuration steps:

1. Click Add Widget → Scoreboard.
2. In the Data tab, click Add Metric.
3. Select the Object Type and browse or search for the desired metric.
4. Select specific object(s) or use an object group to scope the data.
5. In the Thresholds tab, configure color bands:
   • Green: Metric value range considered healthy (e.g., 0–70%).
   • Yellow: Warning range (e.g., 70–85%).
   • Orange: Elevated concern range (e.g., 85–95%).
   • Red: Critical range (e.g., 95–100%).
6. In the Display tab, choose the display mode:
   • Single Value: Shows just the current value with color background.
   • Sparkline + Value: Shows a compact trend line alongside the current value.
   • Multi-Metric: Displays multiple metrics in a grid within the single widget.
7. Configure Label (custom display name), Unit (override the default unit), and Decimal Places (0–4).
8. Click Save.

Heatmap Widget

The Heatmap widget provides instant visual identification of outliers across hundreds or thousands of objects.

Configuration steps:

1. Click Add Widget → Heatmap.
2. In the Data tab, select the Object Type (e.g., Virtual Machine).
3. Set Group By to organize cells by a parent attribute (e.g., Cluster, Host, Datacenter). Objects are visually grouped under their parent's label.
4. Set Color By to the metric that determines cell color (e.g., CPU Usage %). Configure the color gradient with minimum (green) and maximum (red) values.
5. Set Size By to the metric that determines cell size (e.g., Configured Memory MB). Larger cells represent objects with more of the sized metric.
6. In the Thresholds tab, define the color bands:
   • Specify the numeric ranges for green, yellow, orange, and red.
7. Optionally filter the object scope using an Object Group or tag-based filter.
8. Click Save.

Metric Chart Widget

The Metric Chart widget is the primary tool for time-series analysis and trend investigation.

Configuration steps:

1. Click Add Widget → Metric Chart.
2. In the Data tab, add one or more object-metric combinations:
   • Click Add Metric, select the object(s) and metric(s).
   • Each combination appears as a separate series on the chart.
3. In the Chart Options tab:
   • Select Chart Type: Line (default), Area, or Stacked Area.
   • Set Y-Axis Scale: Auto (dynamic based on data), Fixed (specify min/max), or Percentage (0–100).
   • Toggle Show Legend to display/hide the series legend.
   • Toggle Show Data Table to display a tabular view of the data below the chart.
   • Toggle Show Trend Line to overlay a linear regression trend on each series.
   • Toggle Show Dynamic Threshold to display the learned normal range as a shaded band (requires dynamic threshold data).
4. Configure the Time Range override if the widget should use a different range than the dashboard default.
5. Click Save.

Top-N Widget

The Top-N widget ranks objects by a selected metric to quickly surface the highest or lowest performers.

Configuration steps:

1. Click Add Widget → Top-N.
2. In the Data tab, select the Metric to rank by (e.g., Memory Usage %).
3. Set the N Value — the number of objects to display: 5, 10, 20, or 50.
4. Set Sort Order: Highest (top consumers) or Lowest (least utilized).
5. Set Scope: All objects of the selected type, or filter to a specific Object Group or parent object.
6. In the Display tab:
   • Choose bar orientation (horizontal or vertical).
   • Enable or disable value labels on bars.
   • Configure color coding based on thresholds.
7. Click Save.

Topology Graph Widget

The Topology Graph widget visualizes the relationships between infrastructure objects as an interactive network diagram.

Configuration steps:

1. Click Add Widget → Topology Graph.
2. In the Data tab, select the Root Object — the starting point for the topology visualization (e.g., a specific cluster or datacenter).
3. Set Relationship Depth (1–5) — how many levels of parent/child/peer relationships to display from the root object.
4. In the Display tab:
   • Toggle Show Badges to overlay health/risk/efficiency badge icons on each node.
   • Toggle Metrics Overlay to display a selected metric value on each node.
   • Toggle Alert Status to color-code nodes based on their most severe active alert.
5. Configure which Relationship Types to include: Parent, Child, Peer, or All.
6. Click Save.

15.4 Widget Interactions

Widget interactions enable a powerful provider/receiver paradigm where selecting an object in one widget automatically updates the data displayed in other widgets on the same dashboard. This creates interactive, drill-down capable dashboards.

Key concepts:

• A Provider Widget publishes its currently selected object(s) to one or more receiver widgets. Typical providers include Object List, Heatmap, Top-N, and Topology Graph.
• A Receiver Widget consumes the selected object from a provider and updates its display accordingly. Typical receivers include Metric Chart, Alert List, Property List, and Scoreboard.
• A single widget can be both a provider and a receiver simultaneously.

Configuring widget interactions:

1. Open the dashboard in Edit Mode (click the pencil icon or Edit button).
2. Click the gear icon on the provider widget to open its configuration.
3. Navigate to the Widget Interactions tab (also labeled Output in some widget types).
4. In the Receiving Widgets section, check the boxes next to the widgets that should receive selections from this provider.
5. Click Save on the widget configuration.
6. Repeat for additional provider widgets as needed.
7. Save the dashboard.

Performance considerations:

• Widget Limit: A maximum of 25 widgets per dashboard is recommended for optimal performance. Dashboards exceeding this count may experience slow load times, especially with large object scopes.
• Interaction Chains: Avoid circular interaction chains (Widget A provides to Widget B, which provides back to Widget A). This can cause infinite refresh loops.
• Object Scope: When a provider widget has thousands of objects, ensure receiver widgets can handle the potential selection. Use filtering in receiver widgets to limit the data they request.

Example interaction configuration:

A common pattern is the "list-and-detail" layout:

When the operator clicks a VM in the Object List, all four receiver widgets update simultaneously to show data for that specific VM, creating a cohesive investigation experience.

15.5 Dashboard Navigation

Dashboard navigation enables you to link multiple dashboards together, creating hierarchical drill-down paths that guide operators from high-level overviews to detailed investigation views.

Method 1: Navigation Widget

The Navigation Widget provides explicit, clickable links to other dashboards or external URLs.

1. Add a Navigation Widget to the dashboard.
2. In the configuration panel, add one or more Links:
   • Dashboard Link: Select a target dashboard from the dropdown. Optionally pass the currently selected object as context.
   • External URL Link: Enter a full URL (e.g., link to a runbook wiki page or external monitoring tool).
3. Configure the Display Style: Button, Text Link, or Icon.
4. Position the Navigation Widget at the top or side of the dashboard for visibility.

Method 2: Object Click Actions

Configure what happens when a user clicks an object in a widget:

1. Open the dashboard in Edit Mode.
2. Click the gear icon on the widget where click navigation should be enabled.
3. In the Output section (or Interactions tab), find the On Click action setting.
4. Select Navigate to Dashboard and choose the target dashboard.
5. Optionally enable Pass Object Context — the clicked object is automatically set as the focus in the target dashboard.
6. Save the widget and dashboard.

Method 3: Dashboard Linking via URL Parameters

Dashboards can be directly linked using URL parameters that pre-select objects and time ranges:

• Object context: Append ?objectId=<resource_id> to the dashboard URL.
• Time range: Append &timeRange=<start>-<end> in epoch milliseconds.
• This method is useful for embedding VCF Operations dashboards in external portals, wikis, or ServiceNow pages.

Best practices for dashboard navigation:

• Design a dashboard hierarchy: Create a top-level "Landing Page" dashboard with navigation links to domain-specific dashboards (Compute, Storage, Network, Applications). Each domain dashboard links further to object-specific detail dashboards.
• Use consistent naming conventions: Name dashboards with a prefix indicating their level (e.g., "L1 — Environment Overview", "L2 — Cluster Performance", "L3 — VM Detail").
• Include a "Back" link: On detail dashboards, add a Navigation Widget linking back to the parent dashboard so operators can easily return to the overview.
• Leverage context passing: Always enable object context passing when linking from a list or heatmap dashboard to a detail dashboard. This eliminates the need for the operator to re-select the object on the target dashboard.
• Share dashboards with teams: Use Visualize → Dashboards → Actions → Share to grant view or edit access to specific user groups. Shared dashboards appear in recipients' dashboard lists without requiring them to create their own copies.

Chapter 16: Best Practice Dashboard Designs

Dashboards are the primary interface through which operators, engineers, and executives consume data from VCF Operations. A poorly designed dashboard buries critical information; a well-designed dashboard surfaces the right data to the right audience at the right time. This chapter provides six ready-to-implement dashboard blueprints and a set of universal design principles.

16.1 Daily Operations Check Dashboard

This dashboard is the first screen an operations engineer should open each morning. It answers one question: "Is anything broken or about to break?"

Row 1 — Scoreboards (4 widgets, equal width)

Configuration Tip: Set the Scoreboard refresh interval to 5 minutes. Use the "Sparkline" option to show a 24-hour mini-trend directly inside the scoreboard tile.

Row 2 — Top-N Performance Offenders (3 widgets, equal width)

Row 3 — Trends and Heatmaps (2 widgets, 60/40 split)

Blockquote — Why 7-day alert trend? A 7-day window reveals patterns tied to weekly batch jobs, backup windows, or recurring misconfigurations. A single day's snapshot hides these cycles.

16.2 Capacity Planning Dashboard

This dashboard is reviewed weekly by capacity and infrastructure teams. It answers: "When will we run out of resources, and what can we reclaim?"

Row 1 — Scoreboards

Row 2 — Bar Charts (2 widgets, equal width)

Row 3 — Lists and Actions (2 widgets, equal width)

Capacity Threshold Recommendations:

16.3 Performance Monitoring Dashboard

This dashboard is used during active troubleshooting or continuous performance reviews. It answers: "How are my workloads performing right now and over time?"

Row 1 — Scoreboards (3 widgets)

Row 2 — Metric Charts (2 widgets, equal width)

Row 3 — Heatmap and Top-N (2 widgets, 60/40 split)

16.4 Cost Analysis Dashboard

This dashboard serves finance teams and infrastructure managers tracking cloud and on-premises spending. It answers: "Where is the money going, and where can we save?"

Row 1 — Scoreboards (3 widgets)

Row 2 — Distribution and Savings (2 widgets)

Row 3 — Actionable Lists (2 widgets)

16.5 Compliance Dashboard

This dashboard is essential for security and audit teams. It answers: "Are we compliant, and where have we drifted?"

Row 1 — Scoreboards (2 widgets)

Row 2 — Compliance by Benchmark (3 widgets)

Row 3 — Drift and Changes (2 widgets)

16.6 Executive Summary Dashboard

This dashboard is designed for C-level and director-level audiences. It prioritizes clarity over detail and should be presentable on a projector or shared screen without explanation.

Design Principles for Executive Dashboards:

• Maximum 8–10 widgets
• Large font sizes (scoreboard "Big Number" mode)
• No raw metric names — use plain-English labels ("Infrastructure Health" not "badge|health")
• Traffic-light color coding (Green / Yellow / Red)

Row 1 — Environment Scorecard (3 large scoreboards)

Row 2 — 30-Day Trends (2 widgets)

Row 3 — Cost and Sustainability (2 widgets)

16.7 Dashboard Design Best Practices

1. Limit widget count. Keep dashboards to 15–20 widgets maximum. Each additional widget increases render time and cognitive load. If you need more, create a second dashboard and link them.

2. Use widget interactions for drill-down. Configure widget interactions so that clicking an object in a Top-N chart drives the selection in a Metric Chart or Object List widget on the same dashboard. This eliminates the need to duplicate data.

3. Group related metrics logically. Place CPU metrics adjacent to CPU-related alerts. Place capacity widgets together. The user's eye should flow naturally from overview to detail, left to right, top to bottom.

4. Use consistent time ranges. If one chart shows 30 days, all charts on that dashboard should show 30 days unless there is a specific analytical reason to differ. Inconsistent ranges confuse viewers.

5. Place critical KPIs in the top-left quadrant. Eye-tracking studies confirm that users scan dashboards starting from the top-left. Place the most urgent or important information there.

6. Use Text Widgets for section headers. A simple text widget with a bold label like "Performance Indicators" or "Capacity Metrics" helps organize the dashboard visually and aids comprehension.

7. Clone predefined dashboards as starting points. VCF Operations ships with dozens of out-of-the-box dashboards. Clone one that is close to your goal, then modify it. This saves time and ensures you start with proven widget configurations.

8. Test with real data at scale. A dashboard that loads quickly in a lab with 50 VMs may be unusably slow in production with 10,000 VMs. Test with production scope before publishing.

9. Set appropriate default scopes. Avoid dashboards scoped to "All Objects" when a narrower scope (specific cluster, resource pool, or custom group) would be more relevant.

10. Document your dashboards. Add a Text Widget at the top of each dashboard with a one-sentence purpose statement and the intended audience. This prevents dashboard sprawl and confusion.

Chapter 17: Views and Reports

Views and Reports are the primary mechanism for extracting structured, repeatable, and shareable data from VCF Operations. While dashboards are interactive and real-time, reports are static snapshots designed for distribution, archival, and audit compliance.

17.1 View Types

Views are the building blocks of reports. Each view type presents data in a specific visual format optimized for a particular analytical need.

Note: Image Views require you to upload a base image first, then map data points to specific pixel coordinates on the image. This is most commonly used for physical data center visualizations.

17.2 Creating Views

Follow these steps to create a custom view.

Step 1. Navigate to Visualize → Views in the left navigation menu.

Step 2. Click the Create button (plus icon) in the toolbar.

Step 3. In the Presentation section, enter:

• View Name — a descriptive name (e.g., "Top 20 VMs by CPU Usage - Weekly")
• Description — purpose and intended audience

Step 4. Select the View Type from the dropdown: List, Trend, Distribution, Image, or Summary.

Step 5. In the Subjects section, select the Object Type that this view will report on. Common selections include:

• Virtual Machine
• Host System
• Cluster Compute Resource
• Datastore
• vSAN Cluster

Step 6. Switch to the Data tab. Here you select the metrics and properties to display:

• For List Views: each selected metric or property becomes a column
• For Trend Views: each selected metric becomes a line on the chart
• For Distribution Views: select a single metric to distribute
• For Summary Views: select metrics and choose aggregation functions (avg, min, max, sum, count)

Step 7. Switch to the Filter tab (optional). Apply conditions to limit which objects appear in the view. Filters use property or metric-based conditions such as:

• powerState = poweredOn
• cpu|usage_average > 80
• summary|config|numCpu >= 8

Multiple filter conditions can be combined with AND/OR logic.

Step 8. Click Preview to verify the output displays the expected data with the correct format and filtering.

Step 9. Click Save. The view is now available for use in dashboards or report templates.

Tip: When creating List Views, limit the number of columns to 10–12 for readability. If you need more data points, create a second view rather than cramming everything into one table.

17.3 Creating Report Templates

Report templates combine one or more views into a formatted document suitable for distribution. Follow this procedure.

Step 1. Navigate to Visualize → Reports in the left navigation menu.

Step 2. Click Create Template in the toolbar.

Step 3. Enter the Report Name (e.g., "Weekly Infrastructure Health Report") and an optional Description.

Step 4. In the report canvas, add views by dragging them from the left panel into the report body. You can include multiple views of different types. Arrange them in the desired order — each view will render as a separate section in the final report.

Step 5. Optionally configure presentation elements:

• Cover Page — toggle on/off; customize title, subtitle, logo
• Header — appears on every page; can include report name and date
• Footer — appears on every page; can include page numbers and confidentiality notice
• Table of Contents — auto-generated from view names

Step 6. Click Save. The template is now available for on-demand generation or scheduled execution.

Important: Report templates are separate from the data they display. A template defines the structure; the data is populated at generation time based on the scope you select.

17.4 Generating and Scheduling Reports

On-Demand Generation:

1. Navigate to Visualize → Reports.
2. Select the desired report template.
3. Click Run (play icon).
4. In the dialog, select the Scope — choose one or more objects or groups that the report will cover (e.g., a specific cluster, a custom group of VMs, or "All Objects").
5. Click Generate.
6. The report enters a processing queue. Depending on complexity and scope, generation may take seconds to several minutes.
7. Once complete, the report appears in the Generated Reports tab, available for download.

Scheduled Generation:

1. Select the report template and click Schedule (calendar icon).
2. Configure the schedule parameters:

3. Configure Email Delivery:
   • Recipients — comma-separated email addresses
   • Subject Line — supports variables: ${ReportName}, ${Date}
   • Attachment Format — PDF, CSV, or both
4. Click Save Schedule.

Warning: Scheduled reports consume analytics engine resources during generation. Avoid scheduling more than 10 reports at the same time window. Stagger schedules by 15–30 minutes.

17.5 Export Formats

Both formats are available from the Generated Reports tab. Click the download icon next to a completed report and select the desired format.

Tip: For automated downstream processing, use the Suite API endpoint POST /suite-api/api/reports/{reportId}/download with the format query parameter set to pdf or csv. This enables integration with ticketing systems, SharePoint libraries, or custom portals.

Chapter 18: Capacity Planning and Optimization

Capacity planning in VCF Operations moves beyond simple threshold monitoring into predictive analytics. The platform's capacity engine continuously analyzes historical consumption patterns, applies multiple forecasting algorithms, and produces actionable recommendations for rightsizing, reclamation, and future procurement.

18.1 Capacity Engine Overview

The capacity engine evaluates every cluster, datastore, and resource pool across three dimensions.

The capacity engine runs on a continuous cycle, recalculating projections every collection interval (default: 5 minutes for real-time, daily for long-term forecasts).

Important: Capacity calculations honor the policy settings applied to each object. If your policy sets a CPU utilization cap of 70% (meaning 70% is considered "full"), Time Remaining reflects when demand will reach 70%, not 100%.

18.2 Forecasting Algorithms

VCF Operations does not rely on a single forecasting model. Instead, it runs multiple algorithms in parallel and selects the best fit for each metric on each object.

The analytics engine scores each algorithm's fit against actual historical data using a mean-absolute-percentage-error (MAPE) calculation. The algorithm with the lowest MAPE for a given metric is selected for that metric's forecast.

Tip: To see which algorithm was selected for a specific metric, navigate to the cluster's Capacity tab and hover over the forecast line. The tooltip displays the algorithm name and confidence interval.

18.3 Peak Classification

Not all spikes in resource consumption are equal. The capacity engine classifies peaks to prevent false alarms and ensure accurate forecasting.

Peak classification thresholds can be adjusted in the active policy under Configure → Policies → Edit Policy → Capacity and Allocation → Peak Classification.

18.4 Rightsizing

Navigate to: Optimize → Rightsizing

Rightsizing identifies VMs whose allocated resources are significantly mismatched to their actual consumption patterns.

Oversized VM Detection Criteria:

Undersized VM Detection Criteria:

Rightsizing Report Columns:

Taking Action on Rightsizing Recommendations:

1. Generate Change Request — exports a formatted change request document for ITSM integration
2. Export CSV — downloads all recommendations for offline review
3. Apply via Automation — if VCF Automation (Aria Automation) is integrated, trigger a rightsizing workflow directly

Warning: Always validate rightsizing recommendations against application-level requirements. A VM may appear oversized from an infrastructure perspective but require the allocated resources for licensing compliance (e.g., Oracle per-core licensing) or application-mandated minimums.

18.5 Reclaimable Resources

Navigate to: Optimize → Reclaim

The reclamation engine identifies waste — resources that are allocated but delivering no value.

Best Practice: Schedule a weekly reclamation review meeting. Export the reclamation report and distribute it to application owners with a 14-day response window. VMs and VMDKs not claimed within the window are candidates for decommissioning.

18.6 Workload Optimization

Navigate to: Optimize → Workload Optimization

Workload Optimization provides DRS-like placement recommendations, but operates at the VCF Operations level rather than within a single vCenter. This enables cross-cluster and even cross-vCenter balancing recommendations.

Considerations evaluated by the engine:

• CPU demand and contention on source and destination hosts
• Memory demand, active memory, and contention
• Network utilization and port group availability
• Storage latency and capacity
• DRS affinity and anti-affinity rules
• VM-to-host compatibility (EVC mode, hardware version)

Output: The engine generates a prioritized list of migration recommendations. Each recommendation includes:

Note: Workload Optimization recommendations are advisory. VCF Operations does not execute migrations autonomously unless integrated with an automation platform and explicitly configured to do so.

18.7 What-If Analysis

Navigate to: Optimize → What-If Analysis

What-If Analysis lets you model hypothetical changes to your environment and see projected capacity impacts before committing resources or budget.

Scenario Types:

Step-by-Step Procedure (applicable to all scenario types):

Step 1. Click Create Scenario and provide a scenario name (e.g., "Q3 ERP Migration Impact").

Step 2. Select the scenario type from the four options above.

Step 3. Enter parameters specific to the scenario type. For "Add Workload," define the VM profile:

• vCPU count per VM (e.g., 4)
• Memory per VM in GB (e.g., 16)
• Storage per VM in GB (e.g., 100)
• Number of VMs (e.g., 50)

Step 4. Select the target cluster(s) where the workload will be placed or infrastructure will be added.

Step 5. Click Run Analysis. The engine calculates the impact using the same forecasting algorithms described in Section 18.2.

Step 6. Review the results:

Step 7. Save the scenario for future reference or discard it. Saved scenarios can be revisited, modified, and re-run as conditions change.

Tip: Combine scenario types for complex planning. First run "Add Workload" to see the impact of a new project, then run "Add Infrastructure" to determine how many hosts are needed to absorb it. Compare the two scenarios side by side.

Chapter 19: Management Packs

Management Packs extend VCF Operations beyond vSphere, enabling unified monitoring across heterogeneous infrastructure, cloud platforms, applications, and hardware.

19.1 What Are Management Packs

A Management Pack is a pluggable adapter module that teaches VCF Operations how to collect, interpret, and act on data from a specific technology. Each management pack is a self-contained package that includes:

Management packs are distributed as PAK files (Platform Archive Kit) — a signed archive format used by the VCF Operations platform for all extensions and updates.

19.2 Installation Steps

Step 1. Obtain the management pack PAK file. Sources include:

• Broadcom Marketplace (marketplace.broadcom.com)
• Vendor-specific download portals
• VMware Flings (for experimental packs)

Step 2. In VCF Operations, navigate to Administration → Integrations → Repository.

Step 3. Click Add (or Upload PAK File, depending on UI version).

Step 4. Browse to the downloaded PAK file and click Upload. The system validates the file signature and compatibility.

Step 5. Review and accept the End User License Agreement (EULA).

Step 6. Monitor the installation progress bar. Installation typically takes 2–5 minutes. The cluster will distribute the adapter code to all nodes automatically.

Step 7. After installation completes, configure the adapter instance:

1. Navigate to Administration → Integrations → Accounts
2. Click Add Account
3. Select the newly installed adapter type from the dropdown
4. Provide connection details:
   • Display Name — a friendly name for this adapter instance
   • Endpoint URL / IP — the target system's management address
   • Credential — create or select a credential (username/password, token, certificate)
   • Collector — select which collector node will run this adapter (default or Remote Collector)
5. Click Validate Connection to test connectivity
6. Click Save

Warning: After installing a management pack, allow 2–3 collection cycles (typically 10–15 minutes) before expecting data to appear in dashboards. The initial collection cycle populates the object inventory; subsequent cycles populate metrics.

19.3 Official Management Packs (Broadcom)

The following table lists the management packs available from Broadcom, including those built into VCF Operations and those available as separate downloads.

19.4 Management Pack Builder

For technologies not covered by existing management packs, VCF Operations includes a no-code development environment for building custom adapters.

Navigate to: Administration → Integrations → Management Pack Builder

Supported Input Methods:

Development Workflow:

1. Create a new project in Management Pack Builder
2. Define the object model — what object types exist (e.g., "Custom App Server," "Custom Database")
3. Define relationships between object types (e.g., "App Server runs on Host")
4. Map metrics — connect API responses, SNMP OIDs, or script outputs to named metrics
5. Define collection intervals for each metric group
6. Create alert definitions (optional) — symptoms and recommendations for the custom technology
7. Build dashboards (optional) — pre-built dashboards included in the pack
8. Export the project as a PAK file
9. Install the PAK file using the standard process (Section 19.2)

Tip: Start with the REST API input type for most modern applications. Define a health-check endpoint first to validate connectivity, then expand to detailed metrics. Use the built-in Test button at each stage to validate collection before exporting.

19.5 Third-Party Packs

In addition to Broadcom-published management packs, several vendors produce and support their own packs for VCF Operations.

Note: Third-party management packs follow their own release cadence independent of VCF Operations versions. Always verify compatibility with your VCF Operations version before installing. Check the vendor's compatibility matrix or release notes.

Chapter 20: Day-2 Operations and Maintenance

Once VCF Operations is deployed and configured, ongoing maintenance ensures the platform remains healthy, performant, and current. This chapter covers the operational tasks that every VCF Operations administrator must master.

20.1 Log File Locations

All VCF Operations appliance logs reside on the appliance filesystem. The following table identifies the critical log files, their paths, and their purposes.

Tip: When troubleshooting, start with the most specific log. If a particular adapter is failing, check its log in /storage/log/vcops/adapters/ first. Escalate to collector.log only if the adapter log does not reveal the issue.

20.2 Safely Cleaning Logs

Log files can grow substantially in active environments, particularly when debug logging is enabled. Use the following procedures to reclaim disk space safely.

Check current disk usage:

df -h /storage/log
du -sh /storage/log/vcops/*

Truncate an active log file (preserves file handle):

truncate -s 0 /storage/log/vcops/analytics.log

Remove old rotated log archives:

find /storage/log -name "*.gz" -mtime +30 -delete
find /storage/log -name "*.log.*" -mtime +30 -delete

Check for core dumps consuming space:

du -sh /storage/core/
# If core dumps are present and no longer needed:
rm -f /storage/core/core.*

Warning: Never use rm on active log files (e.g., rm analytics.log). The process holding the file descriptor will continue writing to the deleted inode, consuming disk space invisibly. Always use truncate to safely zero out an active log file while preserving the file handle.

Warning: If log growth is persistent, investigate the root cause (e.g., a failing adapter retrying every 5 seconds, debug logging left enabled). Truncating logs without addressing the cause is a temporary fix.

20.3 Backup and Restore

Backup Configuration:

Step 1. Navigate to Administration → Backup/Restore.

Step 2. Configure the backup destination:

• NFS Share — recommended for production; provide NFS path (e.g., nfs://fileserver.corp.local/backups/vcfops)
• Local Path — on-appliance storage; suitable for lab environments only

Step 3. Set the backup schedule:

Step 4. Select backup content:

Step 5. Click Save to activate the schedule. For an immediate backup, click Backup Now.

Restore Procedure:

1. Deploy a fresh VCF Operations OVA with the same version as the backup
2. During the Initial Setup Wizard, select Restore from Backup instead of "New Installation"
3. Provide the backup location path (NFS or local)
4. Select the specific backup file to restore from (listed by date/time)
5. The restore process rebuilds the cluster configuration, policies, dashboards, and (if included) historical data
6. After restore completes, the cluster comes online and resumes data collection

Important: You cannot restore a backup from a newer version to an older version. The target appliance must be the same version or newer than the backup source.

20.4 Certificate Management

VCF Operations generates self-signed internal certificates during deployment. For production environments, replace these with certificates signed by your enterprise Certificate Authority (CA).

Current Certificate Status: Navigate to Administration → Certificates to view the current certificate details, including issuer, subject, expiration date, and thumbprint.

Supported Formats:

Steps to Replace the Certificate:

Step 1. Generate a Certificate Signing Request (CSR) from VCF Operations, or prepare a PEM certificate chain externally.

• If generating a CSR: Administration → Certificates → Generate CSR — provide Subject, SANs (Subject Alternative Names must include FQDN and IP of all nodes), key size (2048 or 4096)
• If providing an external certificate: ensure it includes the full chain (server cert + intermediate CA + root CA)

Step 2. Upload the signed certificate and private key:

• For PEM: upload the certificate file and the private key file separately
• For PFX: upload the PFX file and provide the passphrase

Step 3. Click Apply. VCF Operations validates the certificate chain, verifies the private key matches, and restarts services automatically. Expect 5–10 minutes of downtime during the service restart.

Warning: Ensure the certificate's Subject Alternative Names (SANs) include the FQDN of every node in the cluster and the cluster VIP (if using HA/CA). Missing SANs will cause inter-node communication failures.

20.5 Password Rotation

Regular password rotation is a security best practice and may be required by organizational policy.

Via CLI (SSH to the VCF Operations appliance):

$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py \
  password change --user admin

You will be prompted for the current password and the new password.

Via VCF Fleet Manager (SDDC Manager integration):

1. Log in to SDDC Manager
2. Navigate to Lifecycle → Password Management
3. Select the VCF Operations instance
4. Click Rotate
5. Choose to auto-generate or manually specify the new password
6. Confirm rotation

Rotation Schedule Recommendations:

Important: After rotating adapter credentials (e.g., the vCenter service account password), update the corresponding credential in Administration → Integrations → Accounts → Edit Credential. Failure to do so will cause data collection to stop.

20.6 Upgrading

VCF Operations upgrades are delivered as PAK files and follow a rolling upgrade process that minimizes downtime in HA and CA deployments.

Phase 1 — Pre-Upgrade Checklist:

Phase 2 — Upgrade Execution:

1. Navigate to Administration → Software Update
2. Click Upload PAK File and browse to the upgrade PAK
3. Once uploaded, the system validates the PAK and displays the target version
4. Click Install
5. The upgrade proceeds in rolling fashion:
   • Data nodes upgrade first (one at a time)
   • Remote Collector nodes upgrade next
   • Primary Replica upgrades last
6. During the upgrade, the cluster remains partially available (data collection continues on non-upgrading nodes)
7. Total upgrade time: 30–90 minutes depending on cluster size

Phase 3 — Post-Upgrade Validation:

Warning: Do not delete VM snapshots until you have fully validated the upgrade. Snapshots provide the fastest rollback path if issues are discovered. However, do not keep snapshots longer than 72 hours, as they degrade VM performance.

20.7 Scaling

As monitored environments grow, VCF Operations may require additional resources.

Vertical Scaling (Scale Up):

Increase the vCPU and memory allocated to existing nodes.

To change the size: power off the node, adjust CPU/RAM in vCenter, power on. The analytics engine automatically detects the new resources.

Horizontal Scaling (Scale Out):

Add Data Nodes to distribute the analytics workload across more compute.

1. Deploy a new VCF Operations OVA
2. During setup, select Expand an existing cluster
3. Provide the primary node's FQDN or IP
4. The new node joins the cluster with the Data role
5. Navigate to Administration → Cluster Management to verify the new node
6. The cluster automatically rebalances object assignments across all data nodes

Guideline: Add one Data Node for every 10,000 additional objects beyond the primary node's capacity. For environments exceeding 50,000 objects, engage Broadcom Professional Services for architecture review.

20.8 Support Bundle Generation

When engaging Broadcom Global Support Services (GSS), a support bundle is typically required.

Via the UI:

1. Navigate to Administration → Support → Generate Support Bundle
2. Select the nodes to include (all nodes recommended)
3. Optionally select specific log categories to include
4. Click Generate
5. Download the resulting ZIP file when generation completes

Via the CLI (SSH):

/usr/lib/vmware-vcops/support/vrops-support.sh

The script collects logs, configuration files, cluster state, and diagnostic information into a ZIP file located at /storage/log/vcops/support/.

Support Bundle Contents:

Tip: For targeted troubleshooting, you can generate a "lightweight" bundle by specifying only the relevant log categories. This reduces generation time and file size, which speeds up upload to the support ticket.

20.9 Troubleshooting Common Issues

The following sections document the most frequently encountered issues, their root causes, and step-by-step resolutions.

Cluster Stuck at "Going Online"

Symptom: The cluster status on the Administration → Cluster Management page shows "Going Online" for more than 30 minutes without progressing.

Root Cause: The analytics service is failing to start, typically due to a GemFire distributed cache partition conflict or corrupted analytics state.

Resolution:

# Step 1: Check current service status
/usr/lib/vmware-vcops/support/sliceConfiguration.sh --status

# Step 2: Restart the analytics service
service vmware-vcops-analytics restart

# Step 3: Monitor the analytics log for errors
tail -f /storage/log/vcops/analytics.log

If the restart does not resolve the issue, check for GemFire partition conflicts:

grep -i "partition" /storage/log/vcops/gemfire/gemfire.log | tail -20

If partition errors are present, a full cluster restart may be required:

service vmware-vcops stop
# Wait 5 minutes for all services to fully terminate
service vmware-vcops start

Cluster Stuck at "Going Offline"

Symptom: After requesting the cluster to go offline, the Admin UI becomes unresponsive and the cluster never reaches "Offline" state.

Root Cause: A hung analytics or vPostgres process is preventing graceful shutdown.

Resolution:

# Step 1: Force stop all services
service vmware-vcops stop

# Step 2: Verify all Java processes have terminated
ps aux | grep java

# Step 3: If processes remain, wait 5 minutes then check again
# Do NOT use kill -9 unless absolutely necessary

# Step 4: Start services
service vmware-vcops start

"Waiting for Analytics" Message

Symptom: Dashboard widgets display "Waiting for Analytics" instead of data. The message persists beyond the normal startup window (15 minutes).

Root Cause: The analytics engine has either crashed, is processing a large backlog, or has encountered an out-of-memory condition.

Resolution:

1. Check the analytics service status:

   service vmware-vcops-analytics status
   

2. If the service is stopped, check the log for the cause:

   tail -100 /storage/log/vcops/analytics.log
   

3. Look for OutOfMemoryError or StackOverflowError in the log. If found, the node likely needs more memory (see Section 20.7 on vertical scaling).

4. Restart the analytics service:

   service vmware-vcops-analytics restart
   

"FSDB Running Low on Disk Space"

Symptom: An alert fires indicating that the FSDB (File System Database) partition is running low on disk space. The /storage/db partition is at or above 85% utilization.

Root Cause: Historical metric data has filled the /storage/db partition. This occurs when retention is set too high for the available disk, or when a large number of new objects were added without corresponding disk expansion.

Resolution (in order of preference):

1. Reduce data retention:

   • Navigate to Configure → Global Settings → Data Retention
   • Reduce retention periods:

   Data Type	Default	Minimum Recommended
   Real-time (5-min)	1 day	1 day
   Hourly rollup	30 days	15 days
   Daily rollup	6 months	3 months
   Monthly rollup	13 months	6 months

2. Expand the /storage/db disk:

   • In vCenter, add a new virtual disk to the appliance VM
   • Access the VAMI (https://<node-fqdn>:5480)
   • Navigate to Storage and expand the /storage/db partition to include the new disk

3. Remove unused management packs:

   • Each management pack with a configured adapter instance contributes objects and metrics to the FSDB
   • Disable or remove adapters that are no longer needed

Slow Data Collection

Symptom: Metric charts show gaps, dashboards display stale data, or the "Last Collection" timestamp for adapters is more than 10 minutes old.

Root Cause: Multiple potential causes — adapter overload, network latency to the target system, expired or invalid credentials, or insufficient collector resources.

Resolution:

1. Check adapter status:

   • Navigate to Administration → Integrations → Accounts
   • Look for adapters with warning or error status icons

2. Check adapter logs:

   tail -200 /storage/log/vcops/adapters/<adapter-name>/<adapter-name>.log
   

3. Verify credentials: Edit the adapter account and click Validate Connection

4. Check collector resource usage:

   top -bn1 | head -20
   free -h
   

5. For geographically distant targets: Deploy a Remote Collector at the remote site to reduce collection latency

Root Partition Full

Symptom: Services fail to start. SSH access still works but commands may produce "No space left on device" errors.

Root Cause: Core dumps, temporary files, or unexpected log files have filled the root (/) partition.

Resolution:

# Step 1: Identify the largest consumers
du -sh /* | sort -rh | head

# Step 2: Common culprits — check and clean
du -sh /storage/core/
rm -f /storage/core/core.*

du -sh /tmp/
# Remove old temp files (careful — do not remove active temp files)
find /tmp -type f -mtime +7 -delete

# Step 3: Check for unexpected log files in /var/log
du -sh /var/log/*

Warning: If the root partition is completely full (100%), services cannot write PID files or temp files and will refuse to start. In extreme cases, you may need to boot from a rescue ISO to clear space.

20.10 CLI Tools

VCF Operations provides several command-line tools for administration and troubleshooting.

OPS-CLI Examples:

# List all adapter instances
$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py \
  adapter list

# Search for an object by name
$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py \
  object search --name "web-server-01"

# Query a metric for a specific object
$VMWARE_PYTHON_BIN /usr/lib/vmware-vcops/tools/opscli/ops-cli.py \
  metric query --objectId <uuid> --metricKey "cpu|usage_average"

Warning: Direct Cassandra access via cqlsh localhost 9042 is available for advanced troubleshooting but is unsupported by Broadcom. Modifying data in Cassandra directly can corrupt the FSDB and render the cluster inoperable. Use only under explicit guidance from Broadcom support.

20.11 Suite API Reference

The Suite API is the RESTful interface for programmatic access to all VCF Operations functionality. It enables integration with ITSM tools, custom portals, automation pipelines, and third-party systems.

Authentication:

# Acquire a token
curl -k -X POST \
  "https://<vrops-fqdn>/suite-api/api/auth/token/acquire" \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","authSource":"local","password":"<password>"}'

The response returns a JSON object containing the token field. Use this token in subsequent requests.

Token Usage:

Include the token in the Authorization header for all API calls:

Authorization: vRealizeOpsToken <token>

Tokens expire after 6 hours by default. Acquire a new token when the current one expires.

Base URL:

https://<vrops-fqdn>/suite-api/api/

Key Endpoint Categories:

Interactive API Documentation:

VCF Operations ships with embedded Swagger UI documentation:

https://<vrops-fqdn>/suite-api/doc/swagger-ui.html

The Swagger UI provides a complete, interactive reference for all API endpoints, including request/response schemas, parameter descriptions, and the ability to execute API calls directly from the browser.

Common API Workflow Example — Export All Critical Alerts:

# Step 1: Acquire token
TOKEN=$(curl -sk -X POST \
  "https://vrops.corp.local/suite-api/api/auth/token/acquire" \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","authSource":"local","password":"P@ssw0rd"}' \
  | python -c "import sys,json; print(json.load(sys.stdin)['token'])")

# Step 2: Query critical alerts
curl -sk \
  "https://vrops.corp.local/suite-api/api/alerts?status=ACTIVE&criticality=CRITICAL" \
  -H "Authorization: vRealizeOpsToken $TOKEN" \
  -H "Accept: application/json" | python -m json.tool

# Step 3: Release token when done
curl -sk -X POST \
  "https://vrops.corp.local/suite-api/api/auth/token/release" \
  -H "Authorization: vRealizeOpsToken $TOKEN"

Best Practice: Always release tokens when your automation workflow completes. Each VCF Operations instance supports a limited number of concurrent API sessions. Unreleased tokens count against this limit until they expire naturally.

PART II: VCF Operations for Logs

Chapter 21: Product Overview — Operations for Logs

21.1 Naming History

VCF Operations for Logs has undergone several name changes since its inception, reflecting broader shifts in VMware's product portfolio and, ultimately, the Broadcom acquisition. Understanding the naming timeline is essential when referencing older documentation, knowledge-base articles, and community posts.

Note: Many CLI tools, OVA filenames, internal service names, and API endpoints still reference loginsight or vrli. Do not be alarmed when you encounter these legacy identifiers — they are functionally equivalent to the current product.

Throughout this handbook, the terms Operations for Logs, OpsForLogs, and the abbreviation vRLI may be used interchangeably where historical context or brevity demands it.

21.2 How It Differs from VCF Operations

VCF Operations (metrics) and VCF Operations for Logs (logs) are complementary products. They are deployed separately, serve distinct analytical purposes, and store fundamentally different data types. The following table summarizes the key differences.

Best Practice: Deploy both products and configure the bidirectional integration between them. When Operations detects an anomaly on an object, the administrator can pivot directly into Operations for Logs to examine the logs from that object during the anomaly window — dramatically reducing mean time to resolution.

21.3 Architecture

Operations for Logs follows a scale-out clustered architecture built on the following components:

• Primary Node — The first node deployed. It hosts all core services: the web UI, the REST API, the ingestion pipeline, the indexing engine, the query engine, and the cluster coordination service. In a standalone deployment, the Primary Node handles everything.
• Worker Nodes — Additional nodes that join the cluster to provide horizontal scaling of ingestion throughput, indexing capacity, and query parallelism. Each worker runs the same services as the primary (except cluster coordination leadership).
• Integrated Load Balancer (ILB) — A built-in load-balancing service that distributes incoming log traffic and UI/API requests across all nodes in the cluster. The ILB eliminates the need for an external load balancer in most deployments.
• Virtual IP (VIP) — A single IP address managed by the ILB that serves as the unified entry point for all client connections — syslog sources, agents, browser sessions, and API calls.

Cluster Specifications:

• Minimum cluster size: 1 node (standalone)
• Maximum cluster size: 18 nodes
• Ingestion scaling is approximately linear: each node adds roughly 15 GB/day of baseline ingestion capacity (varies with log complexity and field extraction overhead)
• All nodes store a portion of the indexed data; queries are distributed across nodes and results are merged

Data Flow:

Log Sources (vCenter, ESXi, NSX, Agents, Syslog Devices)
        │
        ▼
   VIP Address (ILB)
        │
        ▼
  ┌─────┴─────┐
  │  Primary   │──── Worker 1 ──── Worker 2 ──── Worker N
  │   Node     │
  └────────────┘
        │
        ▼
  Ingestion Pipeline → Parsing → Field Extraction → Indexing
        │
        ▼
  Cassandra Index + Full-Text Index (per-node storage)
        │
        ▼
  Query Engine (distributed, merges results from all nodes)

21.4 Cluster Sizing Guidance

Select the cluster size based on expected daily ingestion volume and query concurrency requirements.

Warning: These figures assume default field extraction and content packs. Heavy use of custom regex extraction, large numbers of active alerts, or complex dashboards with many concurrent users will reduce effective ingestion capacity. Always monitor the Ingestion Rate and Query Latency dashboards after deployment and add worker nodes proactively if ingestion approaches 80% of rated capacity.

Tip: For VCF environments, a 3-node medium cluster is the recommended starting point for production. This provides both high availability (the cluster tolerates the loss of one node) and sufficient headroom for growth.

Chapter 22: Deployment

22.1 OVA Sizing

The Operations for Logs OVA offers three deployment sizes. Select the size at deployment time — it cannot be changed later without redeployment.

Important: Disk sizes listed are total, including OS, application, and log index storage. The index partition consumes the majority of disk space. When planning retention, remember that longer retention windows require proportionally more disk. If the built-in disk is insufficient, you can attach additional VMDK volumes post-deployment and configure them as additional storage partitions.

Recommendation: For production deployments, always select Medium or Large. The Small size is appropriate only for labs and proof-of-concept environments.

22.2 OVA Deployment (Step-by-Step)

Deploy the Operations for Logs OVA through the vSphere Client using the following procedure.

Prerequisites:

• Downloaded OVA file (VMware-vRealize-Log-Insight-*.ova or the renamed VCF equivalent)
• Target cluster or resource pool identified
• IP address, subnet mask, gateway, DNS, and NTP information prepared
• FQDN registered in DNS (forward and reverse records)

Procedure:

1. Log in to the vSphere Client and navigate to the target cluster or resource pool.
2. Right-click the cluster or resource pool and select Deploy OVF Template.
3. On the Select an OVF template page, choose Local file and browse to the downloaded OVA file. Click Next.
4. On the Select a name and folder page, enter a descriptive VM name (e.g., vrli-primary-01) and select the target inventory folder. Click Next.
5. On the Select a compute resource page, choose the target cluster, host, or resource pool. Click Next.
6. On the Review details page, verify the OVA details (publisher, download size, disk size). Click Next.
7. On the License agreements page, read and accept the EULA. Click Next.
8. On the Deployment configuration page, select the appropriate size from the dropdown:
   • Small (4 vCPU / 8 GB / 530 GB)
   • Medium (8 vCPU / 16 GB / 1,060 GB)
   • Large (16 vCPU / 32 GB / 2,080 GB) Click Next.
9. On the Select storage page:
   • Choose the target datastore or datastore cluster.
   • Set the virtual disk format to Thick Provision Eager Zeroed for production deployments (Thin Provision is acceptable for labs).
   • Select the appropriate VM Storage Policy if applicable. Click Next.
10. On the Select networks page, map the OVA network to the appropriate port group. Click Next.
11. On the Customize template page, fill in the following fields:
    • Root password: Set the root OS password (must meet complexity requirements).
    • Hostname: Enter the FQDN (e.g., vrli-primary-01.lab.local).
    • IP Address: Static IPv4 address.
    • Netmask: Subnet mask (e.g., 255.255.255.0).
    • Default Gateway: Gateway IP address.
    • DNS Server(s): Comma-separated DNS server IPs.
    • Domain: DNS search domain (e.g., lab.local).
    • NTP Server(s): Comma-separated NTP server hostnames or IPs. Click Next.
12. On the Ready to complete page, review all settings and click Finish.
13. Wait for the deployment task to complete in the vSphere Recent Tasks pane.
14. Power on the virtual machine.
15. Wait 3–5 minutes for all services to initialize. Monitor the VM console for boot progress.

Warning: Do not snapshot the VM during initial boot. Allow all services to fully start before taking the first snapshot.

22.3 Initial Configuration Wizard

After the first boot completes, access the web-based configuration wizard to finalize setup.

1. Open a browser and navigate to https://<node-fqdn> (or https://<ip-address>).
2. Accept the self-signed SSL certificate warning.
3. The Initial Configuration Wizard launches automatically.

Step 1 — Admin Password:

• Set the password for the admin user account.
• Requirements: minimum 12 characters, at least one uppercase letter, one lowercase letter, one digit, and one special character.

Step 2 — License Key:

• Enter your Operations for Logs license key.
• Alternatively, click Skip to start a 60-day evaluation period (limited to 16 CPU pack and 25 OSI).

Step 3 — General Configuration:

• Verify the hostname/FQDN is correct.
• Enable or disable the Customer Experience Improvement Program (CEIP).

Step 4 — CEIP:

• Confirm your CEIP participation preference (opt in or opt out).

Step 5 — NTP Configuration:

• Add one or more NTP server addresses.
• Click Test to verify time synchronization.

Critical: Accurate time synchronization is essential for log correlation. Ensure all Operations for Logs nodes, vCenter servers, and ESXi hosts share the same NTP source.

Step 6 — SMTP Configuration:

• Mail Server: SMTP server hostname or IP.
• Port: 25 (unencrypted) or 587 (STARTTLS).
• TLS: Enable if the mail server supports it.
• From Address: The sender address for alert notifications (e.g., vrli-alerts@lab.local).
• Authentication: Provide username and password if the SMTP server requires authentication.
• Click Test to send a test email.

Step 7 — SSL Certificate:

• Upload a custom SSL certificate (PEM format: certificate + private key + CA chain) for trusted browser access.
• Or accept the default self-signed certificate (can be replaced later under Administration → SSL).

Step 8 — Finish:

• Click Finish to apply all settings.
• Services restart automatically. The UI becomes available again in 2–5 minutes.
• Log in with user admin and the password set in Step 1.

22.4 Cluster Setup

A single standalone node is suitable for labs, but production environments require a cluster of at least three nodes for high availability, ingestion scaling, and query performance.

22.4.1 Adding Worker Nodes

1. Deploy additional OVAs following the same procedure described in Section 22.2. Each worker node requires its own unique FQDN and IP address.
2. Power on the worker node and wait for services to initialize (3–5 minutes).
3. Open a browser and navigate to https://<worker-fqdn>.
4. On the initial setup page, select Join Existing Deployment (do not select "Start New Deployment").
5. Enter the Primary Node FQDN or IP address.
6. Review and accept the primary node's SSL certificate fingerprint.
7. Click Join. The worker node contacts the primary, receives the cluster configuration, and begins participating in ingestion and query processing.
8. Repeat for each additional worker node.

Note: Worker nodes do not require independent license keys. The license is managed centrally on the primary node and applies cluster-wide.

22.4.2 ILB and VIP Configuration

After adding worker nodes, configure the Integrated Load Balancer and Virtual IP to provide a single entry point for all clients.

1. Log in to the primary node UI: https://<primary-fqdn>.
2. Navigate to Administration → Cluster.
3. Verify all worker nodes appear with a status of Connected.
4. Navigate to Administration → Cluster → VIP (or the Virtual IP tab).
5. Enter the desired Virtual IP address. This IP must be on the same subnet as the cluster nodes and must not be assigned to any other device.
6. Enter the FQDN for the VIP (register this in DNS beforehand with both A and PTR records).
7. Click Save.
8. The ILB activates across all cluster nodes. Within 30 seconds, the VIP becomes responsive.
9. Verify by navigating to https://<vip-fqdn> — the Operations for Logs UI should load.
10. Update all log sources (syslog configurations, agent liagent.ini files) to point to the VIP address instead of the primary node address.

Warning: If you do not configure a VIP, log sources pointing to the primary node will not benefit from load balancing, and the primary node becomes a single point of failure for ingestion.

22.5 VCF 9.0 Deployment via Fleet Manager

In VCF 9.0 and later, Operations for Logs can be deployed through SDDC Manager's Fleet Management capability, which automates the entire lifecycle.

1. Log in to SDDC Manager and navigate to Lifecycle → Fleet Management.
2. Under Available Products, select VMware Aria Operations for Logs (some builds may still display the legacy name).
3. Click Deploy and provide the required parameters:
   • IP Pool: Select or create an IP pool for the Operations for Logs nodes.
   • Sizing: Choose Small, Medium, or Large.
   • Cluster Size: Number of nodes (1, 3, 6, etc.).
   • NTP Servers: Inherited from SDDC Manager or specified manually.
   • DNS Servers: Inherited from SDDC Manager or specified manually.
   • License Key: Enter the product license key.
4. Click Submit. Fleet Manager performs the following actions automatically:
   • Downloads the OVA from the configured depot or Broadcom repository.
   • Deploys the primary node and worker nodes.
   • Runs the initial configuration wizard programmatically.
   • Forms the cluster and configures the VIP.
   • Registers the instance with SDDC Manager for lifecycle management.
5. Monitor deployment progress in the SDDC Manager → Tasks panel. A typical 3-node deployment completes in 30–45 minutes.
6. Once complete, the Operations for Logs instance appears under Fleet Management → Deployed Products with a status of Active.

Tip: Fleet Manager also handles future upgrades, certificate rotation, and backup scheduling for Operations for Logs, reducing ongoing administrative overhead.

Chapter 23: Log Source Configuration

23.1 Syslog Ingestion Ports

Operations for Logs listens on several ports for log ingestion. The following table summarizes the default ports, protocols, and their intended use.

Best Practice: Use TCP-based protocols (514/TCP, 6514/TCP, 9543/TCP) for all production log sources. UDP-based syslog (514/UDP) does not guarantee delivery and can silently drop messages under load. For compliance-sensitive environments, use TLS-encrypted ports (6514/TCP for syslog, 9543/TCP for agents).

You can verify which ports are actively listening by navigating to Administration → Configuration → Ports in the Operations for Logs UI, or by running the following on the appliance:

netstat -tlnp | grep -E '514|9000|9543'

23.2 vCenter Log Forwarding

vCenter Server generates critical logs including vpxd, vpxd-svcs, vmware-sps, vmafdd, and many others. Forwarding these to Operations for Logs provides centralized visibility into vCenter operations.

Via the VAMI (Recommended)

1. Open a browser and navigate to the vCenter VAMI: https://<vcenter-fqdn>:5480.
2. Log in with the root account.
3. Navigate to Syslog in the left navigation pane (location varies by vCenter version — check under Networking or Syslog Configuration).
4. Click Edit or Configure.
5. Add a remote syslog destination with the following settings:
   • Protocol: TCP
   • Hostname: <vrli-vip-fqdn> (the VIP address of your Operations for Logs cluster)
   • Port: 514
6. Click Save.
7. Verify log delivery: in Operations for Logs, navigate to Explore Logs and search for source = <vcenter-fqdn>. Logs should appear within 1–2 minutes.

Via the CLI (Alternative)

If VAMI access is unavailable, configure syslog forwarding from the vCenter shell:

# SSH to vCenter as root
# List current syslog configuration
/usr/lib/vmware-syslog/bin/get-rsyslog-config.sh

# Set remote syslog target
/usr/lib/vmware-vmon/vmon-cli --restart rsyslog

Note: In vCenter 8.x and later, syslog configuration is managed through the VAMI. CLI-based configuration methods vary between versions. Always consult the release-specific documentation.

23.3 ESXi Syslog Configuration

ESXi hosts produce some of the most valuable logs in a VMware environment — vmkernel, hostd, vpxa, fdm, and vobd among others. There are three methods to configure ESXi syslog forwarding.

Method 1: Automatic via vSphere Integration (Recommended)

This is the simplest method and ensures all hosts managed by a vCenter are automatically configured.

1. In Operations for Logs, navigate to Administration → Integrations → vSphere.
2. Click Add vCenter.
3. Enter the vCenter FQDN and credentials (a service account with read access is sufficient).
4. Click Test Connection to verify connectivity.
5. Click Save.
6. Operations for Logs connects to vCenter, discovers all managed ESXi hosts, and automatically configures each host to forward logs via TCP on port 1514 (SSL-secured).
7. Verify: within 2–3 minutes, ESXi host logs appear in Explore Logs with source names matching ESXi hostnames.

Tip: The vSphere integration also pulls ESXi events and tasks, enabling richer correlation between log messages and vCenter-reported events.

Method 2: Manual per-Host via esxcli

Use this method when vSphere integration is not desired or when configuring individual hosts outside of vCenter management.

# SSH to the ESXi host
esxcli system syslog config set --loghost=tcp://<vrli-vip>:514
esxcli system syslog reload
# Verify the configuration
esxcli system syslog config get

The --loghost parameter supports multiple targets separated by commas:

esxcli system syslog config set --loghost=tcp://vrli-vip.lab.local:514,tcp://backup-syslog.lab.local:514

Important: If the ESXi firewall is enabled, ensure the syslog firewall rule is open:

esxcli network firewall ruleset set -r syslog -e true
esxcli network firewall refresh

Method 3: Bulk Configuration via PowerCLI

For large environments, use PowerCLI to configure all hosts at once:

# Connect to vCenter
Connect-VIServer -Server vcenter.lab.local

# Set syslog target for all hosts
$logHost = "tcp://vrli-vip.lab.local:514"
Get-VMHost | ForEach-Object {
    Write-Host "Configuring syslog on $($_.Name)..."
    Set-VMHostSysLogServer -VMHost $_ -SysLogServer $logHost
    $esxcli = Get-EsxCli -VMHost $_ -V2
    $esxcli.system.syslog.reload.Invoke()
}

# Verify configuration
Get-VMHost | ForEach-Object {
    $esxcli = Get-EsxCli -VMHost $_ -V2
    $config = $esxcli.system.syslog.config.get.Invoke()
    Write-Host "$($_.Name): $($config.RemoteHost)"
}

Warning: When using both the vSphere integration (Method 1) and manual configuration (Method 2 or 3) simultaneously, you may receive duplicate log entries. Choose one method and apply it consistently.

23.4 NSX Log Forwarding

NSX Manager and NSX Edge nodes generate logs critical for network troubleshooting, security event analysis, and compliance auditing. Configure log forwarding from the NSX Manager UI.

Procedure:

1. Log in to the NSX Manager UI (https://<nsx-manager-fqdn>).
2. Navigate to System → Fabric → Profiles → Node Profiles.
3. Select the node profile applied to your NSX Manager appliances (typically All NSX Nodes or a custom profile).
4. Scroll to the Syslog Servers section and click Add.
5. Enter the following:
   • Server: <vrli-vip-fqdn>
   • Port: 514 (for unencrypted TCP) or 6514 (for TLS)
   • Protocol: TCP or LI-TLS (Log Insight TLS)
   • Log Level: INFO (captures Info, Warning, Error, Critical, and Emergency)
6. Click Save.
7. The syslog configuration propagates to all nodes assigned to the profile.

NSX Edge Nodes:

In some NSX deployments, Edge transport nodes may require separate syslog configuration:

1. Navigate to System → Fabric → Nodes → Edge Transport Nodes.
2. Select each Edge node.
3. Under Syslog, click Add and enter the same server details.
4. Click Save.

Note: NSX Distributed Firewall (DFW) logs are generated on the ESXi hosts where the DFW rules are enforced. These logs are forwarded via the ESXi syslog configuration (Section 23.3), not via the NSX Manager syslog configuration.

Verification:

In Operations for Logs, search for:

appname = "nsxmanager" OR appname = "nsx-edge"

NSX logs should appear within 1–2 minutes of configuration.

23.5 Agent Installation

The Operations for Logs agent (also known as the Log Insight agent or liagent) is a lightweight process that collects log files from Windows and Linux operating systems and forwards them to Operations for Logs via the CFAPI protocol.

Windows Agent — GUI Installation

1. In Operations for Logs, navigate to Administration → Agents → Downloads.
2. Download the Windows agent installer (VMware-Log-Insight-Agent-*.msi).
3. Run the MSI installer on the target Windows machine.
4. Click Next through the welcome screen.
5. Accept the EULA and click Next.
6. Enter the server hostname: <vrli-vip-fqdn>.
7. Set the port to 9543 (HTTPS) or 9000 (HTTP).
8. Set the protocol to CFAPI.
9. Check SSL and accept the server certificate if using port 9543.
10. Click Install and then Finish.
11. The agent service (VMware Log Insight Agent) starts automatically and begins forwarding Windows Event Logs.

Windows Agent — Silent Installation

For automated deployments via SCCM, GPO, or scripting:

msiexec /i VMware-Log-Insight-Agent-x64.msi /qn ^
  SERVERHOST=vrli-vip.lab.local ^
  SERVERPROTOCOL=cfapi ^
  SERVERPORT=9543 ^
  /l*v C:\temp\liagent-install.log

Tip: Add SERVICEACCOUNT=domain\svcaccount SERVICEPASSWORD=P@ssw0rd parameters if the agent service needs to run under a domain account to access specific log file paths.

Linux Agent — RPM-based Systems (RHEL, CentOS, SLES)

# Copy the RPM to the target server
sudo rpm -i VMware-Log-Insight-Agent-*.rpm

# Edit the agent configuration
sudo vi /var/lib/loginsight-agent/liagent.ini
# Set the [server] section hostname to the VIP FQDN

# Start and enable the agent service
sudo systemctl start liagent
sudo systemctl enable liagent

# Verify the agent is running
sudo systemctl status liagent

Linux Agent — DEB-based Systems (Ubuntu, Debian)

# Copy the DEB package to the target server
sudo dpkg -i VMware-Log-Insight-Agent-*.deb

# Edit the agent configuration
sudo vi /var/lib/loginsight-agent/liagent.ini
# Set the [server] section hostname to the VIP FQDN

# Start and enable the agent service
sudo systemctl start liagent
sudo systemctl enable liagent

# Verify the agent is running
sudo systemctl status liagent

Important: The agent collects /var/log/messages and /var/log/syslog by default. Additional log directories must be configured explicitly in liagent.ini (see Section 23.6).

23.6 Agent Configuration (liagent.ini)

The agent configuration file liagent.ini controls all aspects of agent behavior — server connectivity, log file collection, field tagging, and debug settings. The file is located at:

• Linux: /var/lib/loginsight-agent/liagent.ini
• Windows: C:\ProgramData\VMware\Log Insight Agent\liagent.ini

Complete Configuration Reference

; ─── Server Connection ───
[server]
hostname=vrli-vip.lab.local
port=9543
proto=cfapi
ssl=yes
ssl_accept_any=yes
; ssl_ca_path=/etc/pki/tls/certs/ca-bundle.crt   ; Use for strict CA validation

; ─── Default Syslog Collection (Linux) ───
[filelog|syslog]
directory=/var/log
include=*.log;messages;syslog

; ─── Custom Application Logs ───
[filelog|custom_app]
directory=/opt/myapp/logs
include=*.log
exclude=debug-*.log
parser=auto
tags={"appname":"myapp","env":"production","tier":"web"}

; ─── Apache Access Logs ───
[filelog|apache_access]
directory=/var/log/httpd
include=access_log*
parser=clf

; ─── Windows Event Log (Windows only) ───
[winlog|application]
channel=Application

[winlog|system]
channel=System

[winlog|security]
channel=Security

; ─── Agent Logging ───
[logging]
debug_level=0
; 0=Off, 1=Error, 2=Warning, 3=Info, 4=Debug
; Set to 4 only for troubleshooting; generates significant local log volume

Key Configuration Parameters

Central Agent Configuration (Agent Groups)

Instead of editing liagent.ini on every machine, you can push agent configurations centrally from the Operations for Logs UI:

1. Navigate to Administration → Agents → Agent Groups.
2. Click New Group.
3. Define a filter to match agents (e.g., by IP range, hostname pattern, or OS type).
4. Add [filelog|...] and [winlog|...] sections to the group configuration.
5. Click Save. Matching agents pull the new configuration on their next check-in cycle (every 5 minutes by default).

Best Practice: Use Agent Groups for all production agent configuration. This ensures consistency, simplifies changes, and provides a single pane of glass for agent management.

Chapter 24: Content Packs

24.1 Built-in Content Packs

Operations for Logs ships with two content packs installed by default:

• General — Provides baseline syslog parsing, common extracted fields (source, appname, facility, severity, text), and a default overview dashboard. This pack handles standard RFC 3164 and RFC 5424 syslog messages.
• VMware - vSphere — The most comprehensive built-in pack. It includes:
  • Parsing rules for over 50 ESXi and vCenter log formats
  • Extracted fields specific to VMware infrastructure (vmw_host, vmw_vc_vm_name, vmw_esxi_service, vmw_vc_event_type, etc.)
  • Predefined dashboards for ESXi hardware health, vCenter task analysis, vMotion tracking, storage errors, and authentication events
  • Alert definitions for critical vSphere events (PSOD, HA failover, storage path failures)

Note: The vSphere content pack is automatically activated when the vSphere integration is configured (Section 23.3, Method 1). Its extracted fields enable rich, structured queries against ESXi and vCenter logs.

24.2 Marketplace Content Packs

Additional content packs are available from the in-product Marketplace and from the Broadcom download portal. The following table lists commonly used packs.