13.4 Creating Support Cases, Required Documentation, and Insights

13.4 Creating Support Cases, Required Documentation, and Insights

Objective 4.3 — "leverage support functions" — is the most practical objective on the blueprint. It is also the one a Tier 1 administrator, the blueprint's named candidate profile, will use most.

Before You Open a Case

A short triage pass resolves a meaningful share of issues and materially improves the cases that do get opened:

1. Read the alert properly — severity, entity, and timestamp (section 8.1).
2. Run the relevant NCC health check. NCC output frequently names the condition and points at a knowledge base article (section 8.2).
3. Search the Knowledge Base. NCC results often cite a specific KB number.
4. Check whether it self-resolved. Many Nutanix alerts auto-resolve when the condition passes.

If the issue persists, open a case — and everything gathered above goes into it.

Creating the Case

Cases are opened through the Nutanix Support Portal, using an account associated with your organization's entitled assets. That association is what links a case to a supported cluster, which is why a new administrator's first support interaction is often about portal access rather than the technical issue. The blueprint references "Common Nutanix Support Portal Access Issues" for that reason.

Required documentation for a case

This is a named knowledge statement — "identify the required documentation for support cases" — so know what belongs in one:

[!TIP] Scope the log bundle to the incident window. Logbay lets you specify a time range and filter by service tags. A bundle covering the twenty minutes around the event is far more useful — and far faster to upload and analyse — than one covering a week.

Priority and Response Times

Nutanix publishes support priority definitions and associated response times. The principle to carry into the exam:

• The highest priorities are reserved for genuine production-down or severely degraded situations with real business impact.
• Lower priorities cover degraded but functioning systems, and questions or requests for guidance.
• Priority should reflect actual impact. Inflating priority on a low-impact case is self-defeating: it degrades the queue for everyone, and it is exactly what makes an organization's genuine emergency harder to prioritize.

Note the distinction from section 13.2: alert severity is Critical, Warning, Info and is a property of a cluster alert. Case priority is a property of a support case. They are different scales and a question may test that you do not conflate them.

Nutanix Documentation Types

"Identify the various Documentation types" is its own knowledge statement, and each type answers a different kind of question:

Some of these require Support Portal access, which the blueprint notes explicitly in its introduction to the objectives.

[!IMPORTANT] Match the question to the document. A symptom → KB article. A design decision → best practice guide. What changed in this build → release notes. Is this supported → the matrix. Proactive hardware or software risk → field advisory. Exam items in this objective are usually exactly this matching exercise.

Insights: Predictive Health and Support Automation

The final knowledge statement is "leverage Insights for predictive health and support automation."

Insights is the cloud-side analytics service that consumes Pulse telemetry (sections 3.3 and 8.4). Because Nutanix receives configuration and health data from a large installed base, it can reason about your cluster against patterns seen across all of them.

What that enables:

• Proactive identification of exposure. When a defect is discovered, Nutanix can identify which clusters are running the affected combination and notify those customers rather than waiting for each to hit the problem.
• Predictive hardware failure detection, from drive and component telemetry.
• Automatic case creation for certain conditions — a failed drive can raise a case and dispatch a replacement without anyone reporting it.
• Configuration and health recommendations benchmarked against the wider installed base.

Pulse is the prerequisite

All of this depends on Pulse being enabled. Disable Pulse and the cluster becomes invisible to Nutanix: no proactive notification, no automatic case creation, no predictive failure detection, and a slower reactive support experience because every case starts from scratch.

That is why Objective 4.2 asks you to "verify Pulse status" and to "describe the benefits of Pulse." The benefit is not telemetry for its own sake — it is that support becomes proactive instead of reactive.

[!TIP] Alert-triggered log collection ties the whole chapter together: certain alerts can automatically collect the relevant logs at the moment of the event. That matters because the most valuable diagnostic data is captured while the problem is happening, not hours later when somebody gets round to opening a case.