Separate host-level causes from VM-level ones and hand over an ordered remediation.
1. Confirm it is a host from device details plus documentation (IT Glue / Hudu);
HV/ESX/VMH prefixes and class filters are hints, not evidence. Not RMM-managed (common
for ESXi) -> visibility is docs plus guest symptoms; route to the hypervisor console.
Map its guests and storage (local, SAN/NAS, cluster shared volume) — the blast radius.
2. Read the alert family from active alerts and activity, then split host vs VM. Most
guests affected, or host metrics elevated (CPU ready/queueing, memory pressure,
datastore latency) -> host-level. One guest sick while the host is comfortable ->
VM-level: route it as a normal server ticket (device-health-check), host exonerated.
3. Datastore capacity — find the consumer, in order: snapshot/checkpoint sprawl (grows
unbounded; top emergency cause), orphaned disks from deleted VMs, thin-provisioned
disks growing into overcommitted space, ISOs or backups parked there. Guests crash at
zero free: a datastore at real risk of filling is an emergency — raise the priority.
Inventory snapshots by age and size in the hypervisor console (hand off with a deep
link into the device in the RMM): consolidating a large old snapshot drives heavy I/O
for hours — window work, unless the datastore is critically full and the trade flips;
spell that out. A stuck backup snapshot points at the backup chain
(backup-failure-triage), not manual cleanup.
4. Host pressure: check activity and ticket history for guests recently added or resized,
and name the noisy neighbour where metrics allow. Ladder: rebalance or migrate guests,
right-size overallocated VMs, then hardware.
5. Output: verdict, ranked cause, ordered remediation with window requirements, and a note
of what was found and done (apply the PSA Note Discipline base skill — plain text, no
markdown or emojis). Reset the alert only after a real action or verified change;
without one it reads "reset, unresolved, recurrence expected". A chronic alert gets a
root-cause ticket, not a weekly reset.
Guardrails: never recommend deleting snapshots, disks, or files without saying what they
are and confirming the backup product is not mid-chain — deleting its working snapshot
corrupts the chain. Host reboots and storage migrations are change-window work needing the
full guest map and every guest handled gracefully; this integration cannot orchestrate
them — hands-on handoff only.
As a Flow: your entire reply posts verbatim as the note. Rank from tool evidence alone;
where it does not distinguish, state both and stop. Never reset alerts, never change
priority beyond board rules, never recommend deletions — findings and a next assignment
only. If the device is not confirmed a hypervisor host, output that line alone.
Magic Library