📈 GH Trending Explorer 🎲 Surprise me

← all repos

fzakaria / rewindvm

git clone https://github.com/fzakaria/rewindvm.git v0.8.1 · 6d ago

Deterministic Linux VMs you can scrub, rewind and fork. Find and replay flaky builds and tests.

—
stars, 24h
—
stars, 7 days
+84
stars, 30 days · #2,719
84
★ total
3
forks · 2 open issues

Star history starts 2026-10-20; the chart appears after the second daily snapshot.

LanguageRust
LicenseMIT
Created2026-09-30 (20d ago)
Last push3d ago
Watchers3
OwnerUser

GitHub topics

Links

README excerpt
Rewind VM 
 Deterministic Linux VMs you can scrub, rewind and fork. 
 Catch a flaky build or test once, then replay it exactly, step through it, and branch it.
 Website ·
 Nix tutorial ·
 Container tutorial ·
 Design ·
 Releases 
Rewind VM runs a Nix build, a test suite or any Linux command inside a KVM
virtual machine whose every run is a function of its inputs. The same inputs
give the same run, at the same steps, every time. A failure you saw once is a
failure you keep: replay it, scrub through it step by step, read any file as it
was at any step, and fork it with a different thread interleaving from any
point.
 [code] 
## Install
On x86_64 Linux with KVM:
 [code] 
With Nix, run it straight from the flake, or install it into your profile:
 [code] 
On NixOS, add the flake as an input and turn on its module:
 [code] 
Or take the tarballs from the
latest release
yourself:
 [code] 
`/dev/kvm` must be readable and writable by you. On AMD Ryzen and EPYC, run
`sudo rewind pmu enable` once after each boot so the VM's clock can follow the
work done inside it; Time inside the VM explains why.
## Use it
 [code] 
A program can say what a correct run is from the inside with the
Rewind SDK, a file or two for C, Rust, Go, Python, Java or
shell: `rewind check` judges every run by its assertions, and the app marks
where one broke.
## The desktop app
The app scrubs a recorded run. Drag the playhead along the timeline and the
build log, process tree and files follow it, or jump to the failure or to
where the run parts from a passing one.
- Click a file to read it as it was at the playhead, syntax colored, or as a
 colored hex dump.
- Show source (`s`) opens the line of the program's own code the thread was
 on, with the stack frames that led there; click a frame to see its line.
 Debug info and sources come from the program itself, or from
 nixseparatedebuginfod2 for Nix packages.
- Search (`Ctrl+F` or `/`) finds text in the build log, the console, file
 paths and events, and takes the playhead to each match.
- Bookmarks (`b`) mark a step with a note, kept with the run and in its
 `.rwd` exports.
- Two runs that differ only in their schedules show the step where the
 schedules part, as a dashed blue mark, and the card says what only one of
 them got there, such as a reschedule.
- The Compare tab sets the two runs' events side by side from just before
 they part, in full, with what differs marked; `x` swaps to the compared
 run at the matching step.
- Show threads (`t`) draws a lane per thread over a window of steps, a bar
 where the thread held the CPU, this run above the compared run.
- Previous and Next can stop at one thread, process, file or kind of event.
- Open shell and Attach gdb work inside the VM at the playhead.
- Fork from here branches the run under another schedule. Its menu turns it
 into Check from here, which tries 8 to 64 schedules from the playhead and
 counts how they ended, a cell per schedule.
- The Runs panel draws a build's runs as a tree