I love this. Please never stop doing what you’re doing.<p>edit: Of course you’re the top contributor to IncludeOS. That was the first project I thought of while reading this blog post. I’ve been obsessed with the idea of Network Function Virtualization for a long time. It’s the most natural boundary for separating units of work in a distributed system and produces such clean abstractions and efficient scaling mechanisms.<p>(I’m also a very happy user of Varnish in production btw. It’s by far the most reliable part of the stack, even more than nginx. Usually I forget it’s even there. It’s never been the cause of a bug, once I got it configured properly.)
Oh. It's like Firecracker, only much faster 8-)<p>What I like most is the ability to instantly reset the state of the VM to a known predefined state. It's like restarting the VM without any actual restart. It looks like an ideal course of action for network-facing services that are constantly under attack: even if an attack succeeds, the result is erased on the next request.<p>Easy COW page sharing for programs that are not written with that in mind, like ML model runners, is also pretty nice.
Original post: <a href="https://fwsgonzo.medium.com/tinykvm-the-fastest-sandbox-564a1c5e9b42" rel="nofollow">https://fwsgonzo.medium.com/tinykvm-the-fastest-sandbox-564a...</a><p>You can find a bunch of posts related to this topic there as well.
This is really exciting. The 2.5us snapshot restore performance is on a par with Wasmtime but with the huge advantage of being able to run native code, albeit with the disadvantage of much slower but still microsecond interop.<p>I see there is a QuickJS demo in the tinykvm_examples repo already but it'd be great to see if it's possible to get a JIT capable JavaScript runtime working as that will be an order of magnitude faster. From my experiments with server rendering a React app native QuickJS was about 12-20ms while v8 was 2-4ms after jit warmup.<p>I need to study this some more but I'd love to get to the point where there was a single Deno like executable that ran inside the sandbox and made all http requests through Varnish itself. A snapshot would be taken after importing the specified JS URl and then each request would run in an isolated snapshot.<p>Probably needs a mechanism to reset the random seed per request.
Fascinating but I'm having trouble understanding the big picture. This runs a user process in a VM with no kernel? Does every system call become a VM exit and get proxied to the host? Or are there no system calls?
I'm new to this area, can someone ELI5 this? What's the difference/advantages/disadvantages compared to other process isolation like containers?<p>Would I use this to run a distributed infra on a server a bit like docker-compose? or it's not related?
this is really cool if it works for your use cases.<p>Some notes from the post<p>> I found that TinyKVM ran at 99.7% native speed<p>> As long as they are static and don’t need file or network access, they might just run out-of-the box.<p>> The TinyKVM guest has a tiny kernel which cannot be modified
This is so cool.<p>I’m exploring micro-VMs for my self-hosted PaaS, <a href="https://lunni.dev/" rel="nofollow">https://lunni.dev/</a> – and something with such little overhead seems like a really interesting option!
There's nothing in the article that suggests that it runs on top of Varnish; in fact, the author even says it's not intended to run Varnish in it.
Not entirely what this is intended for, but does anyone have experience running an X server (or Wayland, I don't care)?<p>I'm doing some dev (on Mac) against RDP server and occasionally have other needs like that for a client. Currently I use UTM (nice QEMU Mac frontend) along with a DietPi (super stripped-down Debian) VM for these sorts of things.<p>I'm pretty familiar with Docker, but have a good idea of what sorts of hoop-jumping might be needed to get a graphics server to run there. Wondering if there's a simpler path.