Hacker News Reader

Comment by lnyng | Hacker News Reader

It reminds me of the ReVirt [1] paper read in an advanced OS class (actually mentioned in the slides). I didn't watch the complete talk. Wondering how much is it different from ReVirt and other record debugging tools.

[1] https://www.usenix.org/legacy/events/osdi02/tech/full_papers...

View on HN

The basic idea is the same as ReVirt, but there are a lot of different details because rr has to run as a pure user-space Linux application whereas ReVirt was baked into the hypervisor. For rr to run efficiently we have to use Linux APIs in creative ways. https://arxiv.org/abs/1705.05937 has more details.

VMware used to support record / replay of VMs in their commercial product, which was quite cool:

https://pubs.vmware.com/ws71_ace27/wwhelp/wwhimpl/js/html/ww...

It is probably more mature then a research prototype as it has received more real-world testing.

ReVirt logs non-deterministic inputs at the hypervisor level. RR will be recording these inputs at the Kernel level. So this makes the inability to replay the OS execution the biggest difference.

Interestingly, hypervisor-level logging of this stuff is both harder (because it has the constraints of kernel-level code) and simpler (because the non-deterministic behaviours are fewer and better-documented at the hardware level than the Linux API level!)

I think it's very likely that, overall, recording a single process is substantially more complex to implement than recording a whole VM. (With significant caveats - recording a whole VM with good performance is going to be hard and making it really useful probably is a whole load of extra code)

Reply on news.ycombinator.com