Academy/vSphere Foundation 9.0 Support (2V0-18.25)/Lab: Create and Execute Orchestrator Workflow for Automated Log Collection
This lab targets VCF 9.0

Lab: Create and Execute Orchestrator Workflow for Automated Log Collection

VCF 9.0Advancedvcp-foundation⏱ 75 min

Covers Obj 5.9 (VCF Operations Orchestrator — configuration, workflows, scheduling). Build automated workflow for support operations.

Objectives

  • Configure VCF Operations Orchestrator and connect to vCenter
  • Browse and run pre-built workflows from the workflow library
  • Create a custom workflow for automated log collection across hosts
  • Schedule workflow execution for recurring support tasks
  • Understand event-based triggers for automated remediation

Prerequisites

VVF lab with VCF Operations Orchestrator deployed (or bundled with VCF Operations). vCenter operational.

Prior labs: vvf-support-12

Required skills:

  • VCF Operations UI basics
  • Basic scripting concepts
  • vCenter administration

Lab Environment

Holodeck VVF pod with VCF Operations Orchestrator running. vCenter connected as endpoint.

Credentials

SystemUsernamePassword
OrchestratoradminSet during deployment
vCenteradministrator@vsphere.localHolodeck default

Tasks

Task 1 Configure Orchestrator and Explore Pre-Built Workflows

manageability

Orchestrator automates repetitive support tasks. Understanding configuration and the pre-built workflow library is foundational for Obj 5.9.

Step 1
VCF Operations → Orchestrate (or navigate to Orchestrator UI). Verify Orchestrator status: Should show 'Running' with vCenter endpoint connected.
Orchestrator running. vCenter endpoint shows 'Connected' status.
Step 2
If vCenter endpoint not configured: Orchestrate → Endpoints → Add → vCenter. Enter FQDN, credentials, accept certificate.
vCenter endpoint added and validated. Inventory discovery begins.
Step 3
Browse workflow library: Orchestrate → Library → browse categories: vSphere, vSAN, Lifecycle Management, Custom. Note the pre-built workflows available.
Library shows categorized workflows. vSphere category includes: Create VM, Clone VM, Snapshot management, Host maintenance.
Step 4
Run a pre-built workflow: Select 'Create a snapshot for all VMs in a resource pool' → Run. Select target resource pool. Set snapshot name and description.
Workflow executes. Tasks tab shows progress. Snapshots created on all VMs in selected resource pool.
Step 5
Review workflow execution history: Orchestrate → Runs → select completed workflow. Review: start time, duration, status (succeeded/failed), input/output parameters.
Execution details show step-by-step progress with timestamps and results.

Validation Gate

Check: Orchestrator configured, pre-built workflow executed successfully

Expected: vCenter endpoint connected. Snapshot workflow completed. Execution history recorded.

Common Errors

vCenter endpoint shows 'Disconnected'
Cause: Credentials expired or vCenter certificate changed
Fix: Edit endpoint → update credentials → re-accept certificate → Save.
Workflow fails with 'Permission denied'
Cause: Orchestrator service account lacks required vCenter permissions
Fix: Verify Orchestrator service account has Administrator role on vCenter. Check vCenter → Administration → Global Permissions.

Task 2 Create Custom Workflow for Automated Log Collection

manageability

Custom workflows automate repetitive support tasks. Building a log collection workflow demonstrates Orchestrator's scripting and action chaining capabilities.

Step 1
Orchestrate → Workflows → New Workflow. Name: 'Automated ESXi Log Collection'. Description: 'Collects support bundles from all ESXi hosts in a cluster and stores in central location.'
Step 2

Define input parameters: Add parameter 'targetCluster' (type: VC:ClusterComputeResource) — this lets the operator select which cluster to collect logs from.

Input parameter defined with vCenter cluster object type.
Step 3

Add workflow elements in sequence: (1) 'Get hosts in cluster' action — retrieves all ESXi hosts from targetCluster. (2) For-each loop over hosts. (3) Inside loop: 'Run SSH command' action — executes 'esxcli system supportrequest interactive' on each host.

The workflow designer uses drag-and-drop for actions. Each action has input/output bindings that connect them in sequence.
Step 4

Add error handling: Wrap the SSH command in a try-catch block. On failure, log the error and continue to next host (don't stop the entire workflow for one host failure).

Error handling configured. Workflow continues processing remaining hosts if one fails.
Step 5

Add final action: 'Send email notification' — sends summary email listing which hosts succeeded and which failed. Configure SMTP settings if not already done.

In Holodeck without SMTP, this step can be replaced with a 'Log message' action that writes results to Orchestrator logs.
Step 6

Validate and save workflow. Click 'Validate' to check for binding errors or missing connections. Fix any validation warnings.

Workflow validates successfully. No binding errors.
Step 7
Test run: Execute workflow → select target cluster → monitor execution in Runs tab.
Workflow executes across all hosts. Support bundles generated on each host.

Validation Gate

Check: Custom workflow created, validated, and executed successfully

Expected: Workflow runs against cluster. Log collection completes on all hosts (or gracefully handles failures).

Common Errors

Workflow validation fails — 'Unbound input parameter'
Cause: Action input not connected to previous action output or workflow input
Fix: Check each action's input bindings in the workflow designer. Ensure targetCluster flows to 'Get hosts' action input.
SSH command fails — 'Connection refused'
Cause: ESXi SSH service not running or firewall blocking port 22
Fix: Enable SSH on target hosts: vCenter → Host → Configure → System → Services → SSH → Start.

Task 3 Schedule Workflow and Configure Event Triggers

manageability

Scheduling and event-based triggers turn manual workflows into automated operations — key for proactive support and exam Obj 5.9.

Step 1
Schedule the log collection workflow: Orchestrate → Workflows → select 'Automated ESXi Log Collection' → Schedule. Set: Daily at 02:00 UTC, target cluster pre-selected.
Scheduled task created. Shows in Orchestrate → Scheduled Tasks list.
Step 2
Configure event-based trigger: Orchestrate → Policies → Add Policy. Create trigger: 'When VCF Operations raises Critical alert on ESXi host → run log collection workflow on affected host.'
Event-based triggers enable automated remediation. Example: critical alert → auto-collect logs → notify support team. Reduces response time.
Step 3

Review policy configuration: Trigger condition (alert severity = Critical, object type = Host System), Action (run workflow with affected host as input), Notification (email/log).

Policy configured with trigger → action → notification chain.
Step 4

Test the trigger: Simulate a critical alert in VCF Operations (or wait for one). Verify the workflow auto-triggers and collects logs from the affected host.

In Holodeck, generate a test alert by temporarily disconnecting a host's vSAN VMkernel — this triggers a vSAN health critical alert.
Step 5

Document automation patterns: List 3 common support scenarios that benefit from Orchestrator automation: (1) Proactive log collection on alert, (2) Scheduled compliance checks, (3) Automated VM snapshot cleanup (delete snapshots >7 days old).

Validation Gate

Check: Workflow scheduled, event trigger configured, automation patterns documented

Expected: Scheduled task visible. Policy trigger configured. Three automation use cases documented.

Common Errors

Scheduled task not executing at configured time
Cause: Orchestrator timezone mismatch or service restart cleared schedule
Fix: Verify Orchestrator timezone matches intended schedule. Check Orchestrator service status. Re-create schedule if needed.
Event trigger fires but workflow fails
Cause: Policy action not properly bound to workflow input parameters
Fix: Edit policy → verify action bindings. Ensure affected object is passed as workflow input parameter.

Final Validation

Orchestrator configured, custom workflow created and tested, scheduling and event triggers operational

✓ Orchestrator connected to vCenter → Endpoint shows 'Connected'

✓ Pre-built workflow executed → Snapshot workflow completed successfully

✓ Custom log collection workflow works → Support bundles generated on target hosts

✓ Schedule configured → Daily schedule visible in Scheduled Tasks

✓ Event trigger configured → Policy with critical alert trigger and workflow action

Cleanup / Restore

• Disable scheduled tasks if not needed for ongoing lab use

• Delete test snapshots created by pre-built workflow

• Remove event trigger policies to prevent unintended workflow execution

Design Reflection (VCDX)

Orchestrator transforms reactive support into proactive operations. Architects should design automation runbooks that cover the top-10 support scenarios, reducing human intervention and MTTR.

Requirements

  • Automate log collection across all cluster hosts
  • Event-driven response to critical alerts

Constraints

  • SSH must be enabled on target hosts (security consideration)
  • Orchestrator needs sufficient resources for concurrent workflow execution

Assumptions

  • vCenter endpoint credentials remain valid
  • SMTP configured for email notifications (optional in lab)

Risks

  • Overly aggressive event triggers can cause workflow storms — implement cooldown periods
  • SSH access to ESXi hosts creates security surface — restrict to Orchestrator service account only

Self-Assessment Discussion Prompts

  1. What safeguards prevent an event trigger from creating an infinite loop of workflow executions?
  2. How would you design an Orchestrator workflow for automated host remediation (vLCM patch + reboot)?
  3. What are the security implications of Orchestrator having SSH access to all ESXi hosts?

Extensions

Create a workflow that generates a weekly vSAN health report and emails it to the ops team

Build an automated snapshot cleanup workflow that deletes snapshots older than 7 days

Integrate Orchestrator with a ticketing system (ServiceNow) to auto-create incidents on critical alerts

Create a multi-step remediation workflow: detect disk failure → evacuate data → create support ticket

⚠ Known Pitfalls (from Community KB)

Orchestrator workflows run with the service account permissions — ensure account has required roles on all target objects
Event triggers without cooldown/throttling can cause workflow storms during major incidents (e.g., network partition triggers alerts on every host simultaneously)
Custom workflows should always include error handling — a single host failure should not abort the entire workflow

References

Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.