firecracker VS cloud-hypervisor

What he said is true, AWS uses Rust heavily in some of AWS core systems https://aws.amazon.com/blogs/devops/why-aws-is-the-best-plac....

Some of the open source projects you can find are AWS Firecracker https://github.com/firecracker-microvm/firecracker and Cloudflare Pingora https://github.com/cloudflare/pingora

This architecture leverages microVMs for rapid scaling and high-density workloads. But does it work for GPU? The answer is no. You can look at the old 2019 GitHub issue and the comments to it to get the bigger picture of why it is so.

Hi, I'm the CEO of the company that built this SDK.

We're a company called E2B [0]. We're building and open-source [1] secure environments for running untrusted AI-generated code and AI agents. We call these environments sandboxes and they are built on top of micro VM called Firecracker [2].

You can think of us as giving small cloud computers to LLMs.

We recently created a dedicated SDK for building custom code interpreters in Python or JS/TS. We saw this need after a lot of our users have been adding code execution capabilities to their AI apps with our core SDK [3]. These use cases were often centered around AI data analysis so code interpreter-like behavior made sense

The way our code interpret SDK works is by spawning an E2B sandbox with Jupyter Server. We then communicate with this Jupyter server through Jupyter Kernel messaging protocol [4].

We don't do any wrapping around LLM, any prompting, or any agent-like framework. We leave all of that on users. We're really just a boring code execution layer that sats at the bottom that we're building specifically for the future software that will be building another software. We work with any LLM. Here's how we added code interpreter to Claude [5].

Our long-term plan is to build an automated AWS for AI apps and agents.

Happy to answer any questions and hear feedback!

[0] https://e2b.dev/

[1] https://github.com/e2b-dev

[2] https://github.com/firecracker-microvm/firecracker

[3] https://e2b.dev/docs

[4] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...

[5] https://github.com/e2b-dev/e2b-cookbook/blob/main/examples/c...

As far as I know, Fly uses Firecracker for their VMs. I've been following Firecracker for a while now (even using it in a project), and they don't support GPUs out of the box (and have no plan to support it [1]).

I'm curious to know how Fly figured their own GPU support with Firecracker. In the past they had some very detailed technical posts on how they achieved certain things, so I'm hoping we'll see one on their GPU support in the future!

[1]: https://github.com/firecracker-microvm/firecracker/issues/11...

I pass through a GPU and USB hub to a VM running on a machine in the garage. An optical video cable and network compatible USB extender brings the interface to a different room making it my primary “desktop” computer (and an outdated laptop as a backup device). Doesn’t get more silent and cool than this. Another VM on the garage machine gets a bunch of hard drives passed through to it.

That said, hardware passthrough/VFIO is likely out of the current realistic scope for this project. VM boot times can be optimized if you never look for hardware to initialize in the first place. Though they are still likely initializing a network interface of some sort.

“MicroVM” seems to be a term used when as much as possible is stripped from a VM, such as with https://github.com/firecracker-microvm/firecracker

According to their own FAQ it is indeed: https://github.com/firecracker-microvm/firecracker/blob/main...

What about microVMs like firecracker?

Dynamic memory management - Firecracker's RAM footprint starts low, but once a workload inside allocates RAM, Firecracker will never return it to the host system. After running several workloads inside, you end up with an idling VM that consumes 32 GB of RAM on the host, even though it doesn't need any of it.

Firecracker has a balloon device you can inflate (ie: acquire as much memory inside the VM as possible) and then deflate... returning the memory to the host.

https://github.com/firecracker-microvm/firecracker/blob/main...

Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons

https://github.com/firecracker-microvm/firecracker/search?q=...

The fact that 'unsafe' even exists in Rust means it's no better than C with some macros.

Don't get me wrong, Rust has it's place, like all the other languages that came about for various reasons, but it's not going to gain wide adoption.

Future of programming consists of 2 languages - something like C that has a small instruction set for adopting to new hardware, and something that is very high level, higher than Python with LLM in the background. Everything in the middle is fodder.

If the calls first pass through a memory safe language as what gvisor does, isn’t the attack surface greatly reduced?

It does seem however that Firecracker + GPU support (or https://github.com/cloud-hypervisor/cloud-hypervisor) is most promising though.

There is no mention of cloud-hypervisor[1] (also in the rust-vmm ecosystem) in the article. It has the memory reclamation feature they require. It also support VFIO and virtiofs.

[1] <https://github.com/cloud-hypervisor/cloud-hypervisor>

https://github.com/tandasat/Hypervisor-101-in-Rust is there to help

https://github.com/cloud-hypervisor/cloud-hypervisor isn't educational necessarily but is one of the most technically progressive fastest developing highest funded vm projects ever, and there are oodles of tech talks on it. I am not qualified to make any specific recommendations, but there's tons of stuff here.

> The goal of the Cloud Hypervisor project differs from the aforementioned projects in that it aims to be a general purpose VMM for Cloud Workloads and not limited to container/serverless or client workloads.

Firecracker is such a great piece of technology. I'm amazed that AWS actually open-sourced it. All kudos to them. We're using Firecracker at our company to allow API companies build interactive demos like this one we built for Prisma [1].

[0] https://github.com/cloud-hypervisor/cloud-hypervisor

[1] https://playground.prisma.io

Relatively new project 'Cloud Hypervisor' https://github.com/cloud-hypervisor/cloud-hypervisor seems to launch images faster.

The Chrome OS hypervisor was then evolved/forked into Firecracker and Intel's Cloud Hypervisor, with the latter supporting both Linux and Windows. Perhaps Cloud Hypervisor would serve as a good backbone for sandboxing, with its Rust implementation and focus on security?

GitHub - cloud-hypervisor/cloud-hypervisor: A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.

Did you guys think about live migrations? https://github.com/cloud-hypervisor/cloud-hypervisor seems to support it and it shares a good amount of code with firecracker.