Don't forget about entropy! You've just created two identical copies of all of your random number generators, which could be very very bad for security.

The firecracker team wrote a very good paper about addressing this when they added snapshot support.

Nice to see this work! I experimented with this for exe.dev before we launched. The VM itself worked really well, but there was a lot of setup to get the networking functioning. And in the end, our target are use cases that don't mind a ~1-second startup time, which meant doing a clean systemd start each time was easier.

That said, I have seen several use cases where people want a VM for something minimal, like a python interpreter, and this is absolutely the sort of approach they should be using. Lot of promise here, excited to see how far you can push it!

Your write-up made me think of:

https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...

Are there parallels?

Does it only work with that specific version of firecracker and only with vms with 1 vcpu?

More than the sub ms startup time the 258kb of ram per VM is huge.

Does this need passthrough or might we be able to leverage PVM with it on a passthrough-less cloud VM/VPS?

The tricky part of doing this in production is cloning sandboxes across nodes. You would have to snapshot the resident memory, file system (or a CoW layer on top of the rootfs), move the data across nodes, etc.

Similar to sprites.dev?

This is how android processes work, but it's a security problem breaking some ASLR type things.

Can you run this in another sandbox? Not sure why you'd want to... but can you?

[dead]

Mods: can we merge with https://news.ycombinator.com/item?id=47412812?