MicroVMs: Run isolated sandboxes with full lifecycle control
131–140 of 222 posts
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#132Earlier quoted context omitted.
Source? https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir... says > Battle-Tested – Firecracker has been battled-tested and is already powering multiple high-volume AWS services including AWS Lambda and AWS Fargate.
Counterpoint: https://justingarrison.com/blog/2024-02-08-fargate-is-not-fi... And also, you’ll notice that Fargate takes minutes to launch while Lambda takes a second or less. You’re waiting on AWS to launch a EC2 with your config and pull your containers into it. (that article matches things I heard from Amazon when I asked why my stuff is slow)
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#133For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand. This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#134Earlier quoted context omitted.
Any reason why you wouldn't use gVisor's bwrap interface yet? We're working on it precisely to make DIY sandboxing on Linux as easy as possible in order to get Linux-sandboxing-at-home to mature beyond the current syscall-filter-and-namespaces duct tape stage, so I'm curious to know what you'd like to see.
It just didn't seem fully baked yet, the 'do' subcommand works fine while the 'bwrap' alias has this problem: `bash: cannot set terminal process group (1): Not a tty`. When executing 'bash -li'. Also the EROFS feature of 'do' should probably be included in 'bwrap', it can be useful. Include overlay options. Also some things you can do to make gvisor better are Wayland passthrough, vulkan support (or virtio native con…
The tty issue is known, should be fixed soon too, though contributions welcome as it sounds like it should be simple fix and we love more contributions :)
FWIW, X11 apps work well, I have a personal hacky project in which I've been running Librewolf in gVisor, with the window being reflected as a native Wayland window. It uses `Xvfb -fbdir` aimed at a bound tmpfs mount to get a shared memory region containing the window's pixel data which can be read directly from out of the sandbox, has Pulseaudio audio passthrough, and a socket server passing through mouse/keyboard events to make the window interactive. Works smoothly even for YouTube playback, and I successfully played a game of Unreal Tournament 2004 at 24fps in it, with no noticeable mouse/keyboard latency :) We're basically making baby steps to get there less hackily.
Thanks for the feedback!
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#135Earlier quoted context omitted.
It just didn't seem fully baked yet, the 'do' subcommand works fine while the 'bwrap' alias has this problem: `bash: cannot set terminal process group (1): Not a tty`. When executing 'bash -li'. Also the EROFS feature of 'do' should probably be included in 'bwrap', it can be useful. Include overlay options. Also some things you can do to make gvisor better are Wayland passthrough, vulkan support (or virtio native con…
Thanks. We're working on rootless network setup to make `runsc do --rootless` work with networking enabled when `passt` is installed right now. See issue #13337 (yes that's a cool issue number) which should unblock this. The tty issue is known, should be fixed soon too, though contributions welcome as it sounds like it should be simple fix and we love more contributions :) FWIW, X11 apps work well, I have a personal…
Wayland is tricky because there are memory buffers being shared between the compositor and the client. crosvm (also by google) adopted 2 custom solutions to it of which one got merged into mainline.
Achieving audio passthrough is trivial as it's just a unix socket. `-host-uds=all`
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#136> MicroVMs support up to 8 hours of total runtime Does this mean you effectively can't use them as long-lived developer environments? It sounds like even if you suspend them, this is the hard limit on the total time it can run.
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#137Earlier quoted context omitted.
Fly.io's Sprites [1] do offer public web access as an option. They also have dynamic pricing. https://sprites.dev
To a first approximation everything in this space has dynamic pricing. If it's not priced dynamically, you're presumably paying a premium either on a commit or in gym pricing.
(Both make sense for their respective use cases.)
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#138Earlier quoted context omitted.
Fargate does not use Firecracker, it is simply ec2 instances.
Source? https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir... says > Battle-Tested – Firecracker has been battled-tested and is already powering multiple high-volume AWS services including AWS Lambda and AWS Fargate.
Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#139Re: MicroVMs: Run isolated sandboxes with full lifecycle control
#140We have this page which compares a whole bunch of sandbox providers in different categories https://engine.build/lab/agent-sandboxes Will add MicroVMs there today (and any others that are missing if you let me know!)
Do you mind adding https://isorun.ai ? We just launched last week. Founder here (Staff SRE with 20 years in Linux, fastest and cheapest SaaS agentic runtime running on heavily modified Firecracker)