Live data from Hacker News

MicroVMs: Run isolated sandboxes with full lifecycle control

aws.amazon.com

121–130 of 222 posts

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#121

Earlier quoted context omitted.

I understand that but micro VMs don't provide better security isolation than regular VMs. So that leaves faster boot times. Faster boot times and then the agent does what ? And at how many token/s? And what's the "time to first token" anyway? How do the time to first token and then the token/s inherent limitations of LLMs not totally dominate the running time? I just don't get the use case.

imagine installing an agent in slack at a company with 1000 employees, and you want each request to have its own VM for data analysis, downloading repos and working on them, ... regular VMs just use too much memory, a typical ubuntu uses 512 MB as a baseline

^ this. a single long session may use 20 subagents, each of which need their own VM, on top of the parent agent's VM, all of which may need separate security credentials, isolation, in addition to the spinup time, and resources used. each user might do 100 sessions a week. so that's 2,000 VMs per week per user. each regular VM takes, let's say, 10s to boot up. that's 5.5 hours per week just waiting for VMs to start (for a single user).

then there's the disk iops used for spinning up all these VMs (loading and booting a whole distro), the security attack vectors of an entire VM vs microVM, the maintenance of the images, the hypervisor abstraction to handle all this automation, ssh for the agent to run in the VM, etc.

compared to mounting an extracted container image to a folder, starting a microVM kernel with folder mount, with specific credentials attached. minimum memory and CPU allocated, minimum possible system resource use, fastest operation, least maintenance. you get more time, more resources, more security.

(micro VMs do provide better security isolation. they have kernels with fewer built-in vulnerabilities, fewer hardware drivers to exploit, a more locked-down network, and they lack a full OS's applications and filesystem permissions to exploit)

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#123
post #111

I’ve been working with AgentCore that uses the same MicroVMs. They are capable in many ways but for coding agents that load a big got repo they get bloated quickly with the git repo. I’m building this google3 style mounting to address this. https://github.com/mohsen1/git-lazy-mount Still work in progress but for now I am seeing promising results

ramp i think just prebuilts the image/snapshot with the latest checkout version regularly [0]. do you think putting it into the image would address it? [0] https://builders.ramp.com/post/why-we-built-our-background-a...

Nice thing about the microvm is that you can snapshot it and restore it. Keeping the fs minimal is my goal. Snapshots restore much faster if they do not include 5GB of source code

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#124
post #120

Earlier quoted context omitted.

The simplest worthwhile DIY sandbox you can have is to layer two tools: bwrap and gvisor. bwrap args -- gvisor args do args -- /path/sandboxee args bwrap will set up the environment and then gvisor elevates it into a true sandbox. Standalone gvisor (not the 'do' subcommand) used to be a mess with the OCI json requirement, but recently they began work on presenting their own bwrap interface (likely to pursue AI agent…

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 context). Being able to get gvisor to populate a network interface inside itself through a 'passt' (or 'containers/gvisor-tap-vsock') socket on the host would also be ergonomic. All of those are available on 'muvm' (based on libkrun) which if you have the time to set up is the next step in DIY sandboxing of graphical apps as well. See: https://git.clan.lol/clan/munix>

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#125
post #32

There are sooooo many sandbox providers out there. They do spike on different features like: - snapshotting and forking - good SSH and VPN access for end-users - agent-friendly features, like obscuring secrets at network layer Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolat…

Why isn't libkrun good enough for hosted stuff? I use it as a podman backend in a microservice architecture.

That's super interesting - have you written up anything on this? I'd love to read it.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#128

Earlier quoted context omitted.

Setting up your own is not that hard and if you bought some compute before the Altman squeeze, very cheap.

How do you do it?

It probably depends on your use case. I have a nice setup for putting claude code in a sandbox for development, but that's likely quite different from running production workloads for customers at scale.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#129
post #104

Earlier 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)

Container pulls are slow. Lambda starts fast as it's not unpacking your container to a local disk on every start.

Re: MicroVMs: Run isolated sandboxes with full lifecycle control

#130
post #64

I don’t get it we are paying at least hundreds or maybe thousands per month on ai costs. Just get a regular vm ?

You absolutely can run agents on a regular VM. But if you want to build multi-tenant and multi-agent systems with strong security boundaries, then having a VM or MicroVM per agent session (or session with a group of agents) really simplifies things. When we did AWS AgentCore Runtime last year we introduced session isolation, with MicroVMs per session. You can think of Lambda MicroVMs as the same stack, but generalize…

why use agentcore runtime then
Post reply on HN