Prism Central at 2,600 VMs on the Small Footprint

Diagnosis: the cluster is healthy; the management plane is not. Four clusters beyond its design point, 2,600 VMs, a 380 GB database and a disk at 86% all point to a Prism Central VM that is CPU- and disk-constrained. Rising disk fill also slows the database, which explains alert latency and report failures.

Remediation, in order:

1. Free space and confirm growth cause - check whether the 380 GB is legitimate data (task history, alert history, report output, Flow logs) or log sprawl; purge or archive, and confirm the VM disk can be expanded before CPU work begins.
2. Scale the PC VM - move to the large form factor (more vCPU/RAM, larger disk). This needs a PC power-off, so book a window; PC downtime does not stop the clusters but does stop scheduled protection and policy changes.
3. Consider scale-out Prism Central - recent AOS releases support a multi-VM PC deployment that spreads management services across three VMs. At this cluster count and VM count that is the more durable answer than one bigger VM.
4. Relocate for blast radius - hosting PC on a cluster it manages couples management-plane failure to a production cluster. A small dedicated management cluster, or at minimum a cluster with independent failure domain, is preferable.

Then re-baseline: trim dashboards and reports to what is actually consumed, and monitor PC CPU and disk as production metrics.

VMs keep running; storage and AHV keep serving I/O. Each cluster retains Prism Element for local management: VM power operations, alerts, local snapshots and cluster health. A short PC outage is survivable - but the loss is real and specific:

• Multi-cluster operations stop: cross-cluster inventory, reporting, capacity planning and centralised alerting (alerts buffer, then age out).
• Policy-driven features stop changing: Flow policies already programmed into AHV continue to enforce, but no new rules or category changes can be made. Categories live in Prism Central, so VMs created in Prism Element during the outage will have no categories - and therefore may fall outside category-scoped Flow policies. That is a genuine security gap, not a cosmetic one.
• Scheduled data protection stalls: protection policies and their snapshot schedules are driven by Prism Central; local protection domains in Prism Element are the fallback.
• Leap, self-service and runbook-driven DR become unavailable exactly when a DR event might need them.

Mitigation: document the Prism Element break-glass path, restrict VM builds to Prism Central or add a manual category-assignment step for outage-created VMs, and put Prism Central behind a tested backup.

Treat Prism Central as a VM with state, not as an appliance that looks after itself.

What to back up:

• The Prism Central VM itself, via a protection policy or scheduled snapshot retained off the hosting cluster, so it can be restored or cloned if the VM is corrupted or its cluster is lost. Keep a copy at a second site if a DR site exists.
• A configuration record captured before any change: PC version and form factor, IP/DNS/NTP, cluster registration list, categories, Flow policies, protection policies, and role mappings. Screenshots and exports are enough; the point is to rebuild quickly.

Recovery playbook, tested at least twice a year:

1. Restore the PC VM snapshot, or deploy a fresh Prism Central and unregister/re-register clusters.
2. Verify categories and Flow policies survived - re-registration can leave VMs uncategorised.
3. Confirm protection policy schedules resumed and that no snapshot chain was missed during the outage.
4. Confirm alerts and reporting are flowing before closing the incident.

Guardrails: never store the only PC backup on the cluster PC manages, and record the deployment date and version so an out-of-support PC is caught before it becomes an outage.