Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Sub-millisecond VM sandboxes using CoW memory forking

github.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking

#61

Post by smj-edison »

hrmtst93837 wrote: post #45
crawshaw wrote: post #14

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 pyt…

[flagged]

Wouldn't you need to restart a process anyways if there's a security update? Sounds like you'd just need to kill all the VMs, start up the base again, and fork (but what do I know).

Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking

#63

Post by wamatt »

shayonj wrote: post #60
adammiribyan wrote: post #3

Earlier quoted context omitted.

Fair question. The fork engine itself is general purpose -- you could use it for anything that needs fast isolated execution. We say 'AI agents' because that's where the demand is right now. Every agent framework (LangChain, CrewAI, OpenAI Assistants) needs sandboxed code execution as a tool call, and the existing options (E2B, Daytona, Modal) all boot or restore a VM/container per execution. At sub-millisecond fork…

> you can do things that aren't practical with 100-200ms startup: speculative parallel execution (fork 10 VMs, try 10 approaches, keep the best), treating code execution like a function call instead of an infrastructure decision, etc. i am not following, why isn't it practical?

Off the top of my head trading or realtime voice come to mind. Probably plenty other domains could benefit

Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking

#64

Post by injidup »

BornaP wrote: post #54
injidup wrote: post #40

It's so frustrating seeing all this sandbox tooling pop up for linux but windows is soooooo far behind. I mean Windows Sandbox ( https://learn.microsoft.com/en-us/windows/security/applicati... ) doesn't even have customizable networking white lists. You can turn networking on or off but that's about as fine grained as it gets. So all of us still having to write desktop windows stuff are left without a good method of…

Feel you. That's why we're actively working on Windows and macOS sandbox support at Daytona - with proper isolation, agents tools, dynamic resizing etc; not just "networking on/off" level controls. If you're building agents on Windows and want to give it a spin, reach out for early access.

Our stack is msvc / cmake / ninja / incredibuild ? Can you support such things?

Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking

#66

Post by CompuIves »

indigodaddy wrote: post #17

Your 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...).

Re: Show HN: Sub-millisecond VM sandboxes using CoW memory forking

#68

Post by crawshaw »

hrmtst93837 wrote: post #45
crawshaw wrote: post #14

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 pyt…

[flagged]

That is very true. We use copy on write for exe.dev base images right now, and are accumulating a lot of storage because of version drift.

We believe the fix here is to mount the base image as a read-only block device, then mount a read-write block device overlay. We have not rolled it out yet because there are some edge cases we are working through, and we convinced ourselves we could rework images after the fact onto a base image.

Right now our big win from copy-on-write is cloning VMs. You can `ssh exe.dev cp curvm newvm` in about a second to split your computer into a new one. It enables a lot of great workflows.

Post reply on HN