Academy/VCF 9.0 Support (2V0-15.25)/Technical Support Fundamentals — Broadcom Wolken Case Management
This lab targets VCF 9.0

Technical Support Fundamentals — Broadcom Wolken Case Management

VCF 9.0Beginnersupport⏱ 45 min

VCFFTS9 course content — VCF 9.0 focused

Objectives

  • Navigate Broadcom Support Portal and Wolken case management site
  • Create a support case with correct severity level and required fields
  • Understand SLO timelines for Raise Management Concern (P1=12hr, P2/P3=24hr, P4=48hr)
  • Search and use KB articles for troubleshooting (key articles: 144456, 200997, 252162, 275360)
  • Generate and transfer diagnostic log bundles via Log Assist
  • Use VCF Operations Log Analysis for real-time troubleshooting

Prerequisites

Active Holodeck VCF 9.0 lab or access to VCF documentation

Required skills:

  • Basic VMware terminology

Tasks

Task 1 Wolken Case Management

Understanding Broadcom's support model (Wolken portal, case severity levels, and escalation paths) is essential for production VCF operations. Support engagement is a Day-2 competency that many teams neglect until a P1 incident.

Navigate and use Broadcom's Wolken case management system

Step 1
Accessing the Support Portal
Broadcom Support Portal: register with corporate email, access requires valid Support Site ID (processing up to 48 hours). Navigate: My Dashboard → My Cases or My Entitlements → select product → case icon. Case views: My Cases (user-opened), All Cases (includes cases from additional Site IDs).
Step 2
Creating a Case

Required fields: Issue Type (Technical/Non-Technical), Product (entitled products only), Company/Site ID (auto-populated), Product Release/version, Severity (P1-P4), Component, Subject (auto-searches KB), Description (detailed issue description + actions taken). For P1 (Critical): must confirm production down + describe business impact. Operating System and Service Pack are optional.

Step 3
Severity Levels & SLO

P1 Critical: production down, 24/7 engagement, Raise Mgmt Concern after 12 hours. P2 High: significant impact, Raise Mgmt Concern after 24 hours. P3 Medium: limited impact, Raise Mgmt Concern after 24 hours. P4 Low: minimal impact, Raise Mgmt Concern after 48 hours. Raise Mgmt Concern = child ticket to support manager (NOT a severity change). Multiple concerns can be raised on one case.

Step 4
Case Management Actions

Quick actions: add comment, file attachment info (FTP/SFTP upload details), refresh, export (PDF/Word), Raise Management Concern (escalation), request close. Case tabs: Unified History (all activities), Comments (add info), Knowledge (linked KB articles), Related Content (technical references). Filter views: AND/OR conditions, sort by field, custom columns, save views.

Validation Gate

Check: What log bundles should you collect before filing a VCF support case?

Expected: ESXi: vm-support bundle. vCenter: vc-support bundle. NSX: support bundle from NSX Manager UI. SDDC Manager: sddc-support bundle from SDDC Manager CLI. Collect ALL relevant bundles — the issue may span components.

Common Errors

Filing a P1 severity case for non-production-impacting issues
Fix: Severity levels: P1 = production down/data loss risk, P2 = production degraded, P3 = partial impact, P4 = general question. Filing P1 for a lab issue or documentation question wastes support resources and delays response for actual P1 cases. Accurately assess severity when filing.
Not collecting log bundles before filing a support case
Fix: Support's first request is always a log bundle. For ESXi: vm-support (esxcli), for vCenter: vc-support, for NSX: support bundle from NSX Manager, for SDDC Manager: sddc-support bundle. Collect logs BEFORE restarting services — a restart may clear the evidence of the root cause.
Not including environment details in support cases
Fix: Include: VCF version, component versions (vCenter, NSX, vSAN, ESXi), hardware model, deployment type (fresh install vs upgrade), and steps to reproduce. Missing details cause back-and-forth that delays resolution. Use SDDC Manager inventory export to capture all versions at once.

Task 2 Knowledge Base & Log Collection

Effective support engagement includes proactive measures: health checks, knowledge base awareness, and understanding of the support lifecycle from case creation to resolution.

Use KB articles for troubleshooting and collect diagnostic logs

Step 1
Knowledge Base Articles
KB article types: how-to, best practices, FAQs, advisories (critical updates/vulnerabilities). Article sections: Products, Issue/Introduction, Environment, Cause, Resolution. Access: Broadcom Support Portal → Knowledge widget → search by keywords + filter by article type/product/date. Subscribe to articles for update notifications. Key KB articles: 144456 (case management), 200997 (advanced search), 252162 (KB from case), 275360 (subscribe to KB).
Step 2
Log Assist — Generating & Transferring Bundles
Log Assist in VCF Operations console generates diagnostic log bundles. Prerequisites: deploy advanced cloud proxies and map to components. Supported components: vCenter, ESX, NSX, SDDC Manager, VCF Operations, Log Insight, Lifecycle Manager. Workflow: select inventory objects → generate bundle (each object = separate task) → authenticate to Broadcom Support Portal → provide Party Site ID + Support Case ID → transfer. Status tracked on Log Assist page. Also can upload directly via Wolken (KB 140731).

[HOLODECK NOTE] Log Assist bundle generation works in Holodeck — it collects logs from nested ESXi hosts and management appliances. However, the 'Transfer to Support Portal' step requires internet connectivity from the VCF Operations appliance. In air-gapped Holodeck environments, download the bundle locally and upload manually via the Broadcom support portal web interface. Bundle sizes from Holodeck are typically smaller than production (fewer hosts, less traffic) but the process is identical.

Step 3
Log Analysis for Troubleshooting
VCF Operations Log Analysis: log-based dashboards, saved queries, custom filters (criteria + grouping), visualization modes and chart types. Live monitoring for real-time analysis. Log-based alerts: configure proactive notifications for specific log patterns. Customizable charts for detailed visualization. Effective troubleshooting: identify issue → check relevant logs → cross-reference with KB articles → collect bundles → submit to support.

Validation Gate

Check: What are the four severity levels for Broadcom support cases?

Expected: P1: Production down, data loss risk (24×7 response). P2: Production degraded (business hours, urgent). P3: Partial impact, workaround exists (business hours). P4: General question, enhancement request (business hours).

Common Errors

Not checking Broadcom KB articles before filing a case
Fix: Many common issues have published KB articles with workarounds. Search kb.broadcom.com before filing a case. If a KB exists, reference it in your case — it accelerates triage. If the KB workaround doesn't resolve the issue, state what you tried.
Closing support cases before root cause is confirmed
Fix: Closing a case after a workaround without confirming root cause means the issue may recur. Keep cases open until: root cause is identified, permanent fix is available (patch/upgrade), or the issue is confirmed as a known limitation with documented workaround.

Design Reflection (VCDX)

Support readiness is part of operational design. VCDX panelists may ask about your support engagement model: who files cases, what information is included, and how escalations are handled. This demonstrates operational maturity beyond initial deployment.

Requirements

  • Understand Broadcom Wolken support portal and case management
  • Know severity levels and appropriate classification
  • Collect diagnostic bundles before support engagement

Constraints

  • P1 cases require production impact justification
  • Log bundles must be collected before service restarts
  • Support portal access requires active support contract

Assumptions

  • Active Broadcom support contract is in place
  • Operations team has access to support portal and knows log collection procedures

Risks

  • Delayed resolution from inadequate initial case information
  • Evidence loss from restarting services before collecting logs
  • Support contract lapse leaving production environment without vendor support

⚠ Known Pitfalls (from Community KB)

Restarting services before collecting log bundles — the most common mistake that makes root cause analysis impossible for support.
Not maintaining an active support contract and discovering it during a P1 incident — verify contract status quarterly.

References

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