justinandClaude Opus 5 2a35397e99 demo: commit the recording harness
The demo tooling only existed in a session scratch directory, which is
temporary. This puts it in the repo so the video can be rebuilt.

Terminal only: tmux drives a two pane session, asciinema records it, agg
renders it, ffmpeg encodes it. The left pane runs the loop against a live
ZVM, the right pane polls the VPG journal so the tagged checkpoint appears
on camera as it lands.

Narration is synthesised per beat and aligned to marks the driver writes
while it runs, rather than to predicted timings, so a slow API call or an
FLR mount that takes longer than usual does not drift the audio. Two
things that has to respect are written down in the README: agg's
idle-time-limit must exceed the longest pause or it compresses idle time
and breaks the wall-clock mapping, and each beat holds for its narration
length so no line is cut off.

demo_win.json carries live guest credentials, so only an example with
placeholders is committed and the real file is gitignored, along with the
generated wav, cast, gif and mp4.

The xAI key path and voice id come from the environment now instead of
being hardcoded to one machine.

Also records the narration gotchas that cost time: mapping an acronym to
run-together phonetics ({"VM": "vee em"}) is spoken as one word, "vem";
prose written for the page sounds robotic read aloud; and volumedetect
reports no samples when aimed at a file whose first stream is video,
which makes a working audio track look silent.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn
2026-09-22 19:39:54 -04:00
2026-09-22 19:39:54 -04:00
2026-09-22 19:39:54 -04:00

zerto-ai-rewind

PoC MCP that makes an agent pin a Zerto tagged checkpoint before it changes a VM, then pull a file back from that tag.

If the loop works, these tools are the delta to add to official ZVM MCP (ZVM.MCP, 10.9). This repo is one MCP process for the demo. It is not a second full ZVM catalog.

What it does

  1. zerto_check_tool — before running anything against a VM: read_only (go), mutating (guard first), or unknown (ask the human whether to checkpoint).
  2. zerto_find_protection — VM name, hostname, or vmIdentifier to exactly one VM and every VPG. Zero or two-plus VMs: stop.
  3. zerto_create_tagged_checkpoint / zerto_guard_before_mutate — same tag on every protecting VPG, wait until listed. The name records which agent and what it is doing: ai:<agent> | <action> | vm=<vm> | change=<id> | <utc>.
  4. zerto_recover_file — FLR after a human sets confirmed=true. Linux and Windows guest paths. Locally replicated VPGs only: FLR runs at the VPG's recovery site. Reports its own unmount; zerto_list_flr_sessions / zerto_end_flr_session find and reap a mount orphaned by a crashed recovery.
  5. Two catalogs — mutating_tools (guard first) and read_only_tools (safe). Both cover Linux (ssh, ansible) and Windows (winrm, powershell, smb), and both are illustrative, not exhaustive. A tool in neither is unknown, not safe: ask the human.

Official ZVM MCP already has inventory and failover test. It does not insert tagged checkpoints or run FLR.

Setup

Python 3.12+.

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cp config.example.json config.json
# edit zerto_url, username, password

Keycloak password-grant, client_id zerto-client on 10.x. Appliance certs are self-signed; verify_tls defaults to false.

stdio MCP (Claude Desktop, VS Code, Cursor, OpenCode):

{
  "mcpServers": {
    "zerto-rewind": {
      "command": "zerto-rewind-mcp",
      "env": {
        "ZERTO_REWIND_CONFIG": "/absolute/path/to/config.json"
      }
    }
  }
}

Copy skills/zerto-rewind/SKILL.md into the client's skill path.

pytest

Demo

Protected app VM. Agent is about to edit a guest config file.

  1. Guard: discover VPG set, insert tagged checkpoint, wait.
  2. Agent writes the bad config.
  3. Human confirms.
  4. zerto_recover_file from that tag.

Git never had the file. RPO is the journal, not last night's backup.

Certified for this PoC

vSphere ZVM 10.x and ZCA on AWS/Azure, same REST paths. HVM is out (separate swagger). Failover Live is not a tool.

Tagged checkpoints do work when the protected site is Azure or AWS. The 9.0 API reference says they cannot be inserted; that is wrong on 10.9.10, where both were accepted and the task reached Completed.

What differs is latency and granularity, both set by the protected site:

protected at journal gap tag visible after
vSphere 5s ~4s
Azure 60s ~34s
AWS 630s ~128s

The tagged checkpoint is also stamped about 30s after the insert request, so on a cloud-protected VPG a prompt mutation can land inside the checkpoint meant to precede it. Recover from the newest checkpoint that already existed when the guard ran, not from the tag.

Not this product

Moholo Agent Rewind snapshots the agent's laptop tools. This server uses the Zerto journal as the snapshot store. Do not copy their file blobs.

Upstream

Ask Zerto engineering to add to ZVM.MCP: find-by-unique-VM-with-all-VPGs, tagged checkpoint insert that waits, FLR. Keep VPG settings CRUD where it already is.

S
Description
No description provided
Readme
285 KiB
Languages
Python 100%