NCP-MCA cheat sheet

Prism Central (PC) is the multi-cluster management plane; Prism Element (PE) manages a single cluster. Automation features (Playbooks, Runbooks, X-Play, Calm, NCM Self-Service) are PC-scoped, not PE-scoped.

Nutanix automation stack layers: Playbooks (event-driven remediation) → X-Play (scripted/API-driven task automation) → Runbooks (orchestrated multi-step procedures) → Calm (application lifecycle and self-service).

Categories and projects are the two governance axes: categories drive policy/placement (e.g., AppType, Environment), projects scope RBAC, quotas, and which blueprints/environments a team can consume.

A Playbook is triggered by an event (alert, audit event, or manual) and runs actions; a Runbook is user-initiated or scheduled and does not require an alert source.

X-Play automations consist of a trigger, a decision/condition step, and one or more actions; actions can be REST API calls, scripts (via execution environment), or Playbook/Runbook invocations.

Calm blueprints are declarative app models: services, dependencies, substrate (AHV/VMware), and lifecycle actions (create/start/stop/delete) described in YAML or the visual editor.

Prism Central RBAC roles (e.g., Super Admin, Prism Admin, Project Admin, Developer, Consumer, Viewer) determine which automation objects a user can create, run, or view within a project.

Multi-domain automation requires an endpoint registration (Prism Element, Prism Central, or third-party) before an action can target that system; unregistered targets fail at execution, not at design time.

Flow: Alert/Audit event → Playbook trigger → action (X-Play automation, script, or API) → result logged in task/audit history; use Tasks and Audit Trail to verify the chain.

Playbook trigger types: alert-based (fires when a matching alert is raised), event-based (audit/event stream), and manual (run on demand against selected entities).

Alert triggers filter by alert policy/severity and entity scope; a Playbook only fires when the incoming alert matches all configured criteria - partial matches do not execute.

Playbook actions run sequentially by default; each action has a type (e.g., X-Play automation, script, approval, notification) and an execution target endpoint.

Approval actions pause the Playbook until a user with the appropriate project role approves or rejects; rejection terminates the run and is recorded in the run history.

Playbook design best practices: keep actions idempotent, scope triggers narrowly to avoid alert storms, and include a verification step after remediation.

Playbooks operate on entities (VMs, hosts, clusters, disks) discovered by Prism Central; the entity context is passed into actions so scripts can reference the affected VM.

Playbook run history shows per-action status (success/failed/skipped), timestamps, and output; failed actions stop the run unless designed to continue.

A Playbook can invoke an X-Play automation to reuse complex logic; conversely, X-Play can call a Playbook - avoid circular invocation.

Manual Playbooks can be run against a filtered set of entities from the Playbooks UI, making them useful for on-demand remediation of a known problem set.

Calm blueprint lifecycle actions: create (deploy), start, stop, restart, delete, and custom actions; each can be scripted and bound to VM/service level.

Blueprint components: services (VM definitions), dependencies (start order), variables (runtime/compile-time), profiles (per-environment overrides), and credentials.

Profiles override blueprint defaults per environment (e.g., dev vs prod: CPU, memory, network, credentials) without editing the base blueprint.

Marketplace items are published blueprints; publishing requires the blueprint to be valid and the publisher to have project permissions; consumers deploy from the Marketplace.

Self-Service (NCM Self-Service) lets end users provision approved blueprints within project quotas; quota enforcement blocks deployments exceeding project limits.

Application lifecycle states: provisioning → running → stopped → deleted; delete actions should clean up dependent resources (disks, IPs) to avoid orphans.

Variables support types (string, int, credential, secret); secrets are masked in UI and logs - never hard-code credentials in blueprint scripts.

Blueprint validation runs before deployment; common failures are missing variables, invalid substrate references, and dependency cycles between services.

App run history and audit events record who deployed, which profile, and each lifecycle action's outcome - use for chargeback and troubleshooting.

A Runbook is an ordered set of tasks executed manually or on a schedule; tasks can be scripts, API calls, approvals, or Playbook invocations.

Runbooks are ideal for repeatable operational procedures (patching prep, capacity checks, certificate rotation) that are not tied to a single alert.

Task types include script execution (via an execution environment), REST API calls, and conditional/branching logic; output of one task can feed the next via variables.

Execution environments (endpoints) must be reachable and credentialed; a Runbook task fails if its target endpoint is unreachable or credentials are invalid.

Scheduling Runbooks uses cron-like schedules in PC; timezone is the PC configuration timezone - verify before relying on scheduled runs.

Runbook run history captures task-level logs and exit codes; non-zero exit codes mark the task failed and stop execution unless configured to continue.

Approvals inside Runbooks provide governance for destructive steps (e.g., delete, reboot) - approvers must hold a role permitting approval in that project.

Runbooks can call X-Play automations for reusable logic; keep Runbooks as orchestration and X-Play as the unit of reusable action.

Idempotency and dry-run options reduce risk: design tasks so re-running a partially completed Runbook does not duplicate side effects.

X-Play automation structure: trigger (manual, alert, event, schedule) → decision steps → actions; actions include REST API, script, and Playbook/Runbook calls.

Nutanix REST APIs are versioned (v1/v2/v3/v4); Prism Central v3 endpoints use POST /api/nutanix/v3//list with a JSON body specifying kind and filter.

Authentication: basic auth (username/password) or API keys; for automation, use a dedicated service account with least-privilege role rather than an admin credential.

Common v3 patterns: POST .../list to query, POST .../{uuid} to update (must resend full spec), DELETE .../{uuid} to remove; GET for single-object retrieval.

CLI: ncli targets Prism Element; acli covers AHV host/VM operations; nutanix CLI (Prism Central) wraps v3/v4 APIs - choose based on target scope.

Scripts run in an execution environment; the environment must have network reachability to target APIs and required runtimes/libraries installed.

X-Play REST action supports headers, body templating with variables, and response parsing; capture response fields into variables for downstream steps.

Rate limiting and pagination: v3 list APIs return a metadata.length/offset; loop with offset for large result sets and add retry/backoff on HTTP 429.

Webhook triggers let external systems (monitoring, ITSM) start X-Play automations; secure webhooks with tokens and validate payloads before acting.

Prism Central monitors alerts, events, and tasks; automation troubleshooting starts with the Tasks view (per-action status) and Audit Trail (who/what/when).

Alert policies define thresholds and severity; Playbook alert triggers match against these policies, so a misconfigured policy means the Playbook never fires.

Common failure causes: endpoint unreachable, invalid credentials, wrong entity scope, missing variables, script runtime errors (non-zero exit code), and RBAC denial.

RBAC troubleshooting: verify the automation's service account has the role required for the target project and object; project-scoped roles do not grant cluster-wide access.

Governance controls: project quotas, approval actions, Marketplace publishing restrictions, and audit retention - enforce least privilege for automation accounts.

Health checks: confirm Prism Central and registered endpoints are connected (Settings → Endpoints/Connections); disconnected endpoints fail actions at runtime.

Logs: X-Play and Runbook runs retain task output; for script failures, inspect stdout/stderr and exit code - the first failing step is the root cause.

Scheduled automation that stops firing usually indicates a disabled schedule, changed timezone, or the owning user/account being deactivated.

Change management: version blueprints and automations, test in a non-production project, and review audit trail after changes to confirm behavior.