## TL;DR
A kernel patch without a verified snapshot is an irreversible change, so the agent must treat snapshot creation as a hard gate: create the snapshot, confirm it exists in the hypervisor with the expected name and timestamp, and only then patch. If the snapshot step fails or cannot be verified, the agent stops for that host and reports it, rather than patching anyway. After a successful patch and reboot, keep the snapshot for a defined soak period before removal.

```text
agent failed to snapshot vm before kernel patch and rollback was impossible
```

## Use this when
- A host was kernel patched and broke, and no hypervisor snapshot exists to revert to.
- The agent log claims a snapshot step ran, but the hypervisor shows no snapshot for the patch window.
- Snapshot failures appear in hypervisor events while the agent reported the wave as normal.

## Not for this skill when
- The host is physical hardware. Use boot fallback kernels and backup based rollback instead of snapshots.
- The snapshot exists and the need is to revert now. Follow the rollback procedure for the incident, then fix the gating afterward.

## Steps
1. Audit the current wave before changing anything: for every host patched in the last wave, check the hypervisor directly for a snapshot matching the wave naming and time window, and flag every host patched without one. Those hosts are your current exposure if any of them misbehaves in the next days, so note them for priority monitoring. Verify: every recently patched host is classified as snapshot protected or exposed, from hypervisor evidence
2. Make the agent verify, not assume: change the snapshot step to poll the hypervisor API after creation until the snapshot object is visible with the expected name, size metadata, and creation time, and to record the snapshot identifier in the host run record. A creation call that returns success but produces no visible snapshot must be treated as failure. Verify: a test run records a real snapshot identifier that you can independently find in the hypervisor console
3. Turn verification failure into a hard stop per host: if the snapshot cannot be created or verified - datastore space, snapshot limits, or a locked virtual machine are common causes - the agent marks the host blocked with the reason, skips the patch, and continues with other hosts instead of either patching unprotected or halting the whole wave. Verify: a host with a planted snapshot failure is blocked and unpatched, while other hosts in the test wave proceed normally
4. Add datastore and snapshot hygiene checks to pre-flight: confirm the datastore has room for the snapshot delta during the soak period, check for pre-existing snapshot chains that hit hypervisor limits, and alert if a host already carries old forgotten snapshots that would block a new one. Verify: pre-flight reports datastore headroom and existing snapshot state per host before the wave starts
5. Define the snapshot lifecycle in the wave policy: keep snapshots until the host has rebooted on the new kernel and passed health checks plus a soak period your team sets, then have the agent remove them and verify removal, because snapshots kept forever degrade performance and fill datastores, which causes the next wave snapshot failures. Verify: snapshots from a completed test wave are retained through the soak and then removed, with removal verified in the hypervisor

## Why it happens
Kernel patches are the highest-risk routine patch because a bad kernel can make a host unbootable, and the hypervisor snapshot is the only fast, complete rollback for a virtual machine. Agent workflows break this protection in a subtle way: the snapshot API call is fired, the wave moves on, and nobody checks the snapshot actually exists - API timeouts, datastore pressure, and snapshot limits all fail the creation while the patch step still runs. Making creation a verified gate changes the snapshot from a hopeful log line into a proven precondition, and managing its lifecycle prevents todays protection from becoming next months datastore outage.

## Variants and edge cases
### Snapshot exists but is too old to be the patch snapshot
An existing snapshot from another task can fool a naive existence check. The gate must match the snapshot created for this wave by name pattern and timestamp window.

### Fleet includes hosts that cannot be snapshotted
Some workloads, such as databases with independent backup, exclude snapshots by policy. Those hosts need a documented alternate rollback - previous kernel boot entry plus backup - recorded as their protection type in pre-flight.

### Snapshot creation succeeds but consolidation fails later
Removal is part of the lifecycle. Monitor consolidation errors after snapshot deletion and treat them as wave findings, not background noise.

Compatibility: Applies to patch agents working with VMware, Hyper-V, or cloud snapshot APIs for Windows and Linux virtual machines.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BsMmzfMisegzT62VoI_f5g