No networking inside forks? This is not usable.
Show HN: Sub-millisecond VM sandboxes using CoW memory forking
81–85 of 85 posts
Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking
#82Earlier quoted context omitted.
Isn't this what -HUP is supposed to be for in the first place? Maybe a -STOP/-HUP/-HUP situation?
HUP is short for "hangup" which was supposed to be sent when the tty controlling the session the process is in hung up.
Right, so tty's go stale prior to the freeze and they must be renewed after the freeze .. seems to me there's a missing system heuristic here.
Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking
#83No networking inside forks? This is not usable.
Not yet. Current design is run code, return result. Adding virtio-net to forks is on the roadmap. What's your use case that needs it?
Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking
#84Really impressive work. Sub-millisecond cold starts via CoW forking is a pretty clever approach. The tricky part we keep running into with agent sandboxes is that code execution is just one piece, bcs agents also need file system access, memory, git, a pty, and a bunch of other tools all wired up and isolated together. That's where things get hairy fast.
[deleted]
Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking
#85Your write-up made me think of: https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s... Are there parallels?
I think this is very similar! Really cool to see. The first version we launched used the exact same approach (MAP_PRIVATE). Later on, we bypassed the file system by using shared memory and using userfaultfd because ultimately the NVMe became the bottleneck ( https://codesandbox.io/blog/cloning-microvms-using-userfault... and https://codesandbox.io/blog/how-we-scale-our-microvm-infrast... ).
I tried to do something similar well over a decade ago during an internal hackathon (the motivation back then being speeding up destructive integration tests). My idea was to have the memory be a file on tmpfs, and simply `cp --reflink` to get a copy-on-write clone. Then you wouldn't need to bother with userfaultfd or slow storage as the kernel would just magically do the right thing.
Unfortunately, the Linux kernel didn't support reflink on tmpfs (and still doesn't), and I'm not genius enough to have been able to implement that within 24 hours. :-)
I still believe it'd be nice to implement reflink for tmpfs, though. It's the perfect interface for copy-on-write forking of VM memory.