Lab: Configure VCF Operations with NSX Adapter and Custom Dashboards

VCF 9.0Intermediateadmincloud-opsnetwork⏱ 75 min

Objectives

Add NSX adapter to VCF Operations for network topology monitoring
Create custom dashboard with NSX-aware widgets (DFW analytics, segment health)
Configure cross-component correlation between vCenter, NSX, and vSAN metrics
Differentiate metrics, properties, and logs with hands-on examples

Prerequisites

VCF management domain with VCF Operations deployed and NSX Manager operational

Prior labs: vcp-admin-01

Required skills:

VCF Operations UI
NSX Manager basics

Lab Environment

Holodeck VCF pod with management domain, NSX Manager cluster, VCF Operations.

Credentials

System	Username	Password
VCF Operations	`admin`

Tasks

Task 1 Add NSX Adapter and Verify Network Metrics Collection

manageability

NSX adapter enables network topology visualization and DFW analytics — key VCF-only capability not in VVF.

Step 1

VCF Operations → Administration → Solutions → NSX-T → Configure → Add adapter. Enter NSX Manager FQDN, admin credentials, test connection.

NSX-T adapter appears in Solutions list with 'Connected' status. Collection begins immediately.

Use a service account for the NSX adapter, not admin credentials. Service accounts survive password rotation.

Step 2

Wait 10 minutes for initial collection. Navigate to Environment → NSX → verify Tier-0/Tier-1 gateways, segments, and Edge nodes appear.

NSX inventory tree shows: Tier-0 gateways, Tier-1 gateways, Segments, Edge nodes, Transport nodes. Each object has metrics beginning to populate.

Initial collection takes 10-15 minutes for a small environment. Large NSX deployments (1000+ segments) may take 30+ minutes.

Step 3

Install NSX Content Pack: Administration → Solutions → Repository → find 'NSX-T' → Install. This adds pre-built NSX dashboards.

NSX Content Pack installs pre-built dashboards: NSX Overview, DFW Analytics, Edge Health, Segment Traffic Analysis.

Content Packs are versioned. Check for updates quarterly to get new dashboards and improved metric definitions.

Step 4

Navigate to Dashboards → NSX Overview. Review widgets: DFW rule hit count, segment traffic, Edge node health.

NSX Overview dashboard shows: total segments, active DFW rules, Edge node CPU/memory, and top talker VMs by network throughput.

DFW rule hit count widget is particularly valuable — identifies unused rules that can be pruned for performance.

Validation Gate

Check: Environment → NSX shows Tier-0 gateway, segments, and Edge nodes

Expected: NSX inventory populated with all managed objects

Common Errors

Using admin credentials instead of service account for NSX adapter — password rotation breaks collection

Not installing NSX Content Pack — default dashboards lack NSX-specific widgets

Expecting immediate data after adapter addition — initial collection takes 10-15 minutes

Task 2 Create Cross-Component Dashboard

manageability

Cross-component dashboards demonstrate the VCF Operations value proposition — correlating compute, network, and storage metrics in a single view.

Step 1

Create new dashboard: 'VCF Infrastructure Health'. Add widgets: (1) Heatmap — hosts by CPU, (2) NSX segment traffic chart, (3) vSAN latency trend, (4) Top-N VMs by network throughput.

Dashboard layout with 4 widgets: CPU heatmap (green-to-red color scale), NSX segment traffic line chart, vSAN latency trend line, and Top-N VM table.

Design dashboards for specific personas: executive (high-level health), operator (detailed metrics), security (DFW analytics).

Step 2

Configure widget interactions: Host heatmap → filters NSX segment widget to show segments on selected host. Top-N → links to VM detail.

Widget interactions configured: clicking a host in heatmap filters the NSX segment widget to show only segments with VMs on that host.

Widget interactions make dashboards actionable. Without interactions, each widget is an isolated view that requires mental correlation.

Step 3

Add alert list widget filtered to Critical/Immediate alerts across all adapters (vCenter + NSX + vSAN).

Alert list widget shows Critical and Immediate alerts from all configured adapters. Alerts include source (vCenter/NSX/vSAN), object name, and triggered time.

Filter alert widgets carefully — showing all alerts creates noise. Focus on Critical and Immediate for operator dashboards; include Warning for capacity planning dashboards.

Step 4

Save and share dashboard with operator role (read-only access).

Dashboard shared with operator role. Operators can view but not modify the dashboard layout or widget configurations.

Dashboard sharing supports role-based access. Create different dashboards for different roles rather than one dashboard for everyone.

Validation Gate

Check: Dashboard 'VCF Infrastructure Health' loads with all widgets showing data from vCenter, NSX, and vSAN

Expected: Cross-component widgets populated, interactions working

Common Errors

Creating dashboards with too many widgets — cognitive overload reduces effectiveness; limit to 6-8 widgets per dashboard

Not configuring widget interactions — isolated widgets require manual correlation across separate views

Sharing dashboards with edit access to operators — accidental modification loses carefully designed layouts

Task 3 Demonstrate Metrics vs Properties vs Logs

manageability

Understanding the three data types is an explicit exam objective. Hands-on differentiation builds exam confidence.

Step 1

Select any ESXi host → Metrics tab. Identify: CPU Usage % (metric — numeric, changes every 5 min). Note collection interval and retention.

Metric example: CPU Usage % = 45.2 (numeric, sampled every 5 minutes, stored for 6 months default retention).

Metrics drive alerts and capacity planning. Know the collection interval (default 5 min) and retention period for sizing VCF Operations storage.

Step 2

Same host → Properties tab. Identify: ESXi Version (property — static, changes only on upgrade). Note: properties enable filtering and grouping.

Property example: ESXi Version = 9.0.0 (string, updated only when host is upgraded, used for filtering and grouping in dashboards).

Properties enable powerful grouping: filter all hosts by ESXi version to identify upgrade candidates, or group by hardware model for lifecycle planning.

Step 3

Navigate to Operations for Logs → Explore Logs → filter by source = same ESXi host. Identify: Log entry (log — text event, timestamped, used for troubleshooting).

Log example: 2025-01-15T10:23:45Z esxi-01 vpxa: [info] Task completed successfully (text event with timestamp, source, and message body).

Logs are the troubleshooting backbone. VCF Operations for Logs provides structured search and log-based alerting — essential for proactive incident detection.

Step 4

Document the three data types with one example each. This is a common exam question format.

Documentation showing three data types with examples from the lab. This format matches common exam question patterns.

Exam tip: metrics are numeric and time-series, properties are descriptive and semi-static, logs are text events used for troubleshooting. Remember: metrics for alerting, properties for inventory, logs for root cause.

Validation Gate

Check: Can articulate metric vs property vs log with concrete examples from the lab environment

Expected: Clear understanding demonstrated through hands-on exploration

Common Errors

Confusing metrics with properties — metrics change frequently (CPU usage), properties change rarely (ESXi version)

Not understanding log retention vs metric retention — different retention policies for different data types

Ignoring the relationship between data types — a metric alert triggers investigation in logs, properties filter the scope

Task 4 Configure Alert Definitions and Notification Channels

availability

Alert configuration transforms VCF Operations from a passive monitoring tool to an active operational assistant. Proper alerting reduces MTTR and prevents incidents.

Step 1

Navigate to Alerts > Alert Definitions. Review existing alerts for NSX objects. Key alerts: NSX Manager cluster health degraded, Edge node CPU >80%, DFW rule push failure, Transport node disconnected. Enable notification for each critical alert.

Alert definitions list shows NSX-specific alerts from the Content Pack. Each alert has: name, criticality (Critical/Immediate/Warning/Info), trigger condition, and recommendation.

Focus on high-impact alerts first: NSX Manager cluster health and Edge node availability directly affect network data plane.

Step 2

Create a custom alert: 'vSAN Capacity Warning'. Configure: Metric=vSAN Used Capacity %, Condition=> 70%, Criticality=Warning, Wait Cycles=3 (confirms trend over 15 min). Add recommendation text: 'Review capacity trending and plan expansion. Check for orphaned snapshots consuming space.'

Custom alert created and visible in Alert Definitions. After 3 collection cycles above threshold, alert triggers and appears in the Alerts dashboard.

Wait Cycles prevent false alarms from transient spikes. 3 cycles = 15 minutes at 5-min collection interval. Increase for less critical alerts.

Step 3

Configure notification channel: Alerts > Notifications > Add. Options: Email (SMTP), Webhook (REST API for ticketing integration), Syslog (forward to SIEM). Configure email: SMTP server, recipient list (ops-team@company.com), alert filter (Critical and Immediate only).

Notification channel configured and tested. Test notification email received by operations team. Webhook integration documented for future ServiceNow/Jira integration.

Filter notifications aggressively — sending all alerts causes alert fatigue. Ops team email gets Critical/Immediate only. Warning alerts go to a dashboard for weekly review.

Step 4

Design an alert escalation matrix: Tier 1 (Info/Warning) — dashboard review during daily standup. Tier 2 (Immediate) — email to on-call engineer, 30-minute response. Tier 3 (Critical) — email + webhook to PagerDuty/ServiceNow, 15-minute response. Document the matrix and map VCF Operations alert levels to organizational response tiers.

Alert escalation matrix with 3 tiers mapping VCF Operations criticality to organizational response procedures. Each tier has: notification method, response time, escalation path.

VCDX design: alert escalation must map to SLA commitments. If the SLA requires 15-minute response, the alert must reach the engineer within 5 minutes to allow 10 minutes for diagnosis.

Validation Gate

Check: Custom alert created, notification channel configured, escalation matrix documented

Expected: Alert fires on threshold breach, notification reaches operations team, escalation matrix ready for production use

Common Errors

Not setting Wait Cycles on alerts — single-sample alerts trigger on transient spikes causing alert fatigue

Sending all alert levels to email — operators ignore alerts when volume is too high

Not testing notification channels — alerts fire but nobody receives them due to SMTP misconfiguration

Task 5 Create Super Metrics for Cross-Component Analysis

manageability

Super Metrics combine data from multiple objects into custom calculated metrics — enabling business-relevant KPIs that no single adapter provides.

Step 1

Navigate to Administration > Configuration > Super Metrics. Create a new Super Metric: 'Cluster CPU Overcommit Ratio'. Formula: Sum of VM vCPU across all VMs in cluster / Total physical cores in cluster. Assign to cluster object type.

Super Metric calculates in real-time: for a 4-host cluster with 128 physical cores and 200 total vCPU assigned, ratio = 1.56:1. This overcommit ratio is a key capacity planning metric.

CPU overcommit ratios vary by workload: 3:1 acceptable for VDI, 1.5:1 for production servers, 1:1 for latency-sensitive applications. Document the target ratio in your VCDX design.

Step 2

Create a second Super Metric: 'vSAN Usable Days Remaining'. Formula: (Total vSAN capacity - Current used) / Average daily growth rate (calculated from 30-day trend). Assign to vSAN cluster object type.

Super Metric shows estimated days until vSAN reaches 70% capacity threshold. Example: 2TB free, 10GB/day growth = 200 days remaining.

This metric drives procurement planning. Alert when days remaining < 90 to allow time for hardware ordering and installation.

Step 3

Add both Super Metrics to the VCF Infrastructure Health dashboard created in Task 2. Create widgets: Scoreboard showing overcommit ratio (green <2:1, yellow 2-3:1, red >3:1) and Trend chart showing vSAN days remaining over last 30 days.

Dashboard now shows business-relevant metrics alongside infrastructure metrics. Executive stakeholders can understand capacity posture without interpreting raw metrics.

Super Metrics bridge the gap between technical infrastructure metrics and business-relevant KPIs. Design them for your audience: executives want trends and forecasts, operators want thresholds and alerts.

Step 4

Document the Super Metric design pattern for VCDX: (a) identify the business question (When will we run out of capacity?), (b) identify the source metrics (vSAN used, vSAN total, daily growth), (c) define the formula, (d) assign to object type, (e) create dashboard widget, (f) configure alert threshold. This pattern can be applied to any cross-component KPI.

Super Metric design pattern documented with 6 steps. This becomes a reusable framework for creating new business-relevant metrics.

VCDX defense: demonstrate that your monitoring design goes beyond default metrics. Custom Super Metrics show operational maturity and business alignment.

Validation Gate

Check: Super Metrics created, dashboard widgets configured, design pattern documented

Expected: Overcommit ratio and vSAN days remaining visible on dashboard with color-coded thresholds

Common Errors

Creating Super Metrics without defining the business question first — results in metrics nobody uses

Not assigning Super Metrics to the correct object type — metric calculates but does not appear on expected objects

Setting alert thresholds on Super Metrics without Wait Cycles — transient calculation spikes cause false alarms

Final Validation

VCF Operations fully configured with NSX adapter, cross-component dashboards, alerting, and custom Super Metrics.

✓ NSX adapter collecting data → NSX objects visible in inventory with metrics populating

✓ Cross-component dashboard operational → Widgets from vCenter, NSX, and vSAN with interactions

✓ Metrics/Properties/Logs differentiated → Can articulate differences with concrete examples

✓ Alert configuration complete → Custom alerts, notifications, and escalation matrix documented

✓ Super Metrics providing business KPIs → Overcommit ratio and capacity forecast on executive dashboard

Cleanup / Restore

• Take snapshot 'post-vcf-ops-nsx-dashboard'

• Export dashboard definitions for backup

• Save alert escalation matrix document

• Document Super Metric formulas for knowledge transfer

Design Reflection (VCDX)

Panelist: How does VCF Operations with NSX adapter change your monitoring strategy compared to VVF? What network metrics would you alert on for a multi-tier application?

Requirements

Unified monitoring across compute, network, and storage
Proactive alerting with <15 minute response for critical issues
Business-relevant capacity forecasting for procurement planning

Constraints

NSX adapter adds additional object count to VCF Operations sizing
Super Metric calculation increases VCF Operations CPU overhead
Notification channels require outbound network access (SMTP, webhook)

Assumptions

NSX Manager accessible from VCF Operations network
SMTP server available for email notifications
Operations team trained on alert response procedures

Risks

Oversized VCF Operations may be needed for large NSX deployments (10,000+ segments)
Alert fatigue from poorly tuned thresholds reduces response effectiveness
Super Metric formulas may produce misleading results with incorrect source metrics

Self-Assessment Discussion Prompts

How would you size VCF Operations for 10,000 NSX segments?
What DFW metrics indicate a security policy misconfiguration?
How do you design dashboards for different stakeholder audiences?
What Super Metrics would you create for a VCDX design review?

Extensions

Aria Operations Integration Comparison

If Aria Operations is available, compare its capabilities with VCF Operations. Document additional features: what-if capacity modeling, predictive DRS recommendations, cost optimization recommendations, and third-party management pack ecosystem.

Custom Content Pack Development

Create a custom Content Pack with dashboards tailored to your organization. Include: executive health summary, operations detail view, security compliance dashboard, and capacity planning view. Export and version-control the Content Pack.

VCF Operations API Automation

Use the VCF Operations REST API to automate: dashboard creation, alert configuration, Super Metric definition, and report generation. Build a Python script that deploys a standardized monitoring configuration to new VCF environments.

⚠ Known Pitfalls (from Community KB)

Using admin credentials for NSX adapter instead of a dedicated service account — password rotation breaks metric collection silently

Creating dashboards with 15+ widgets — cognitive overload reduces operational effectiveness; limit to 6-8 focused widgets per dashboard

Not configuring Wait Cycles on alerts — single-sample triggers cause alert fatigue and erode trust in the monitoring system

Ignoring Super Metric opportunities — default metrics answer infrastructure questions but miss business-relevant KPIs like capacity forecast and overcommit ratios

References

VCF Operations NSX Adapter GuideTier 1 — Official

Mark complete