Hello, I'm building a replacement for docker containers with a virtual machine with the ergonomics of containers + subsecond start times.
I worked in AWS previously in the container space + with firecracker. I realized the container is an unnecessary layer that slowed things down + firecracker was a technology designed for AWS org structure + usecase.
So I ended up building a hybrid taking the best of containers with the best of firecracker.
Hey this is super cool. I've been researching tech like this for my AI sandboxing solution, ended up with Lima+Incus: https://github.com/JanPokorny/locki
My problem with microVMs was that they usually won't run docker / kubernetes, I work on apps that consist of whole kubernetes clusters and want the sandbox to contain all that.
Does your solution support running k3s for example?
That's the one feature of similar systems that always gets left out. I understand why: it's not a priority for "cloud native" workloads. The world, however, has work loads that are not cloud native, because that comes at a high cost, and it always will. So if you'd like a real value-add differentiator for your micro-VM platform (beyond what I believe you already have,) there you go.
It helps if you offer a concrete use case, as in how large the heap is, what kinda of blackout period you can handle, and whether the app can handle all of it's open connections being destroyed, etc. The more an app can handle resetting some of it's own state, the easier LM is going to be to implement. If your workload jives with CRIU https://github.com/checkpoint-restore/criu you could do this already.
By what I assume is your definition, there are plenty of "non cloud native" workloads running on clouds that need live migration. Azure and GCP use LM behind the scenes to give the illusion of long uptime hosts. Guest VMs are moved around for host maintenance.
As does OCI, and (relatively recently) AWS. That's a lot of votes.
Use case: some legacy database VM needs to move because the host needs maintenance, the database storage (as opposed to the database software) is on a iSCSI/NFS/NVMe-oF array somewhere, and clients are just smart enough to transparently handle a brief disconnect/reconnect (which is built-in to essentially every such database connection pool stack today.)
Use case: a web app platform (node/spring/django/rails/whatever) with a bunch of cached client state needs to move because the host needs maintenance. The developers haven't done all the legwork to make the state survive restart, and they'll likely never get time needed to do that. That's essentially the same use case as previous. It's also rampant.
Use case: a long running batch process (training, etc.) needs to move because reasons, and ops can't wait for it to stop, and they can't kill it because time==money. It's doesn't matter that it takes an hour to move because big heap, as long as the previous 100 hours isn't lost.
"as in how large the heap is"
That's an undecidable moving target, so let the user worry about it. Trust them to figure out what is feasible given the capabilities of their hardware and talent. They'll do fine if you provide the mechanism. I've been shuffling live VMs between hosts for 10+ years successfully, and Qemu/KVM has been capable of it for nearly 20, never mind VMware.
"CRIU"
Dormant, and still containers. Also, it's re-solving solved problems once you're running in a VM, but with more steps.
Somewhat related: I have a branch of Ganeti that has first-class ZFS support baked in, including using ZFS snapshot replication to do live migration without shared storage or CEPH: https://github.com/linsomniac/ganeti
Current status is I'm looking for more feedback. In a few weeks when Ubuntu 26.04 comes out I'm going to set up my dev/stg clusters at work with it, at the moment I've only tested it in a test cluster at home.
It works this way: It creates a snapshot of the zvol, and replicates it to the secondary machine. When that's done, it does another snapshot and does a "catch up" replication (the first replication could take hours on large volumes). Pause the VM, do a final snapshot+replication. Replicate the working RAM. Start up the VM on the new host.
Live migrations and the tech powering it was the hardest thing I ever built. Its something that I think will come naturally to projects like smolVM as more of the hypervisors build it in, but its a deeply challenging task to do in userspace.
My team spent 4 months on our implementation of vm memory that let us do it and its still our biggest time suck. We also were able to make assumptions like RDMA that are not available.
All that to say — as someone not working on smolVMs — I am confident smolVMs and most other OSS sandbox implementations will get live migration via hypervisor upgrades in the next 12 months.
Until then there are enterprise-y providers like that have it and great OSS options that already solve this like cloud hypervisor.
I see. so right now smolvm can be stopped, and then "packed" (think of it as compressed), and restart on a different host. files in the disks are preserved, but memory snapshotting is still hard tbh
Ultimately the original does get stopped, but with additional techniques, we're talking milliseconds of downtime between when the old one stops and the new one resumes. (For live migration technology in general, no clue about smol machines.)
+1. i built something similar called shuru.run because i wanted an easy way to set up microVM sandboxes to run some of my AI apps, and firecracker wasn't available for macOS (and, as you said, it is just too heavy for normal user-level workloads).
Nice work on Shuru — I remember looking at it when I was researching this space. You went with a Rust wrapper on Apple’s Virtualization framework right?
I believe anyone with a spare linux box should be able to carve it into isolated programmable machines, without having to worry about provisioning them or their lifecycle.
The documentation’s still early but I have been using it for orchestrating parallel work (with deploy previews), offloading browser automation for my agents etc. An auction bought heztner server is serving me quite well :)
Yes, having a light-weight solution for local devices as well is one primary goal of the design. Another one is to make it easy for hosting, self or managed
What were the biggest challenges in terms of designing the VM to have subsecond start times? And what are the current bottlenecks for deceasing the start time even further?
Wsl2 runs a Linux vm so it definitely feasible and has the api's necessary.
It is on the roadmap, but frankly I haven't used Windows in a decade. I would love for a contributor to take that on as part of the free and open source spirit.
The images or rather portable artifacts rehydration on any platform plus the packaging is neat. I have been working on https://instavm.io for some time around VM based sandboxes and related infra for agents and this is refreshing to see.
hi, great project! Windows support is sorely lacking, though. As someone working a lot with sandboxed LLMs right now, the options-space on windows for sandboxing is _extremely lacking_. Any plans to support it?
Hey, thanks so much! yah we will definitely add windows support later. We are exploring how to get this work with WSL and will release it asap.
Stay tuned and thanks!
lxc/lxd are ~container managers, the kernel is still shared like docker containers. It runs on linux & needs to run in a linux virtual machine on macOS.
smolvm is a virtual machine with the ergonomics of containers like packaging and distributing, kernel is not shared. You'd run containers inside of smolvm.
Also, smolvm runs ontop of both kvm for linux and apple's hypervisor for macOS. So it's cross platform.
How "fat" are the packed machines? In other words, how much bloat is inevitable, or is that entirely controlled by the base image + the user's smolvm machine spec? How does smolvm's pack compare to something like dockerc [0] in terms of speed and size? Disclaimer: I just learned about dockerc!
I can't actually create and test a pack right now because of [1], but I love the idea of using this to distribute applications you might otherwise use a Docker image for.
yah, i guess everybody share the experience of "i messed up with my dev env" right? We want this "machine" to be shippable, meaning that once it is configured correctly, it can be shared to anyone and use right away.
I see the alpine and python:3.12-alpine images in your cli docs. Where does these come from?is it from a docker like registry or are these built in? Can I create my own images? Or this this purely done with the smolfile? Is there a Ubuntu image available?
Looks really nice btw. Hot resize mem/cpu would be nice. This could become a nice tech for a one-backend-per-customer infra orchestrator then.
What are you actually doing on top of libkrun? Providing really small machine images that boot quickly? If I run the smolvm run --image alpine example, what is "alpine?" Where is that image coming from? Does this have some built-in default registry of machine images it pulls from? Does it need an Internet connection that allows outbound access to wherever this registry runs? Is it one of a default set of pre-built images that comes with the software itself and is stored on my own filesystem? Where are the builds for these images? Where do these machine images end up? ~/.local/share/smolvm/?
Great job with the comparison table. Immediately I was like “neat sounds like firecracker” then saw your table to see where it was similar and different. Easy!
Basically any open source project nowadays run their software stack in containers often requiring docker compose. Unfortunatley Smol machines do not support Docker inside the microvms and they also do not support nested VMs for things that use Vagrant. I think this is a big drawback.
I tried something like this already, also including nested kvm. I think this will increase the boot time quiet a bit.
Also libkrun is not secure by default. From their README.md:
> The libkrun security model is primarily defined by the consideration that both the guest and the VMM pertain to the same security context. For many operations, the VMM acts as a proxy for the guest within the host. Host resources that are accessible to the VMM can potentially be accessed by the guest through it.
> While defining the security implementation of your environment, you should think about the guest and the VMM as a single entity. To prevent the guest from accessing host's resources, you need to use the host's OS security features to run the VMM inside an isolated context. On Linux, the primary mechanism to be used for this purpose is namespaces. Single-user systems may have a more relaxed security policy and just ensure the VMM runs with a particular UID/GID.
> While most virtio devices allow the guest to access resources from the host, two of them require special consideration when used: virtio-fs and virtio-vsock+TSI.
> When exposing a directory in a filesystem from the host to the guest through virtio-fs devices configured with krun_set_root and/or krun_add_virtiofs, libkrun does not provide any protection against the guest attempting to access other directories in the same filesystem, or even other filesystems in the host.
Thanks so much for the feedbacks. Yes these are valid concerns around libkrun security, We are planning and developing features around them actually, and hopefully that could alleviate the conerns.
for virtio-fs, yes the risk of exposing the host fs struture exists, and we plan to:
1. creating staging directory for each vm and bind-mount the host dir onto them
smolvm operates on the same shared responsibility model as other virtual machines.
VM provides VM-level isolation.
If the user mounts a directory with the capability of symlinks or a host OS with a path for guest software that is designed to escape - that is the responsibility of the user rather than the VM.
Security is not guaranteed by using a specific piece of software, it's a process that requires different pieces for different situations. smolvm can be a part of that process.
So directionally yes. But it relies on kvm. I focus on portability i.e. cross platform for local macOS and linux, so that is not top of mind for me right now.
What I really like about containers is quickly being able to spin one up without having to specify resources (e.g. RAM limit). I hope this would let me do that also.
Hey this is pretty neat! I definitely would try using this for benchmarks and other places where I need strong isolation as Docker is just too bloated and slow, but sadly I don't think I can run this natively on my Windows laptop. I hope you extend to WSL! Good luck and congrats on launch.
Hey thanks so much for the feedback. Yah try it and let us know. We have a discord if you want to join, but either github or discord feel free to report any issues you find to us.
We’re using smolmachines to create environments for our agents to execute code. It’s been great so far and the team is super responsive. The dev ergonomics are also great.
This project is very cool! One readme nit: "Pack a stateful virtual machine into a single file (.smolmachine) to rehydrate on any supported platform." For awhile I thought this meant that you could rehydrate a machine's memory like you can with a firecracker vm, but as far as I can tell you can't? It's stateful == disk?
unikraft's internals are not open source so I can't say.
But smol machines are not an implementation of unikernel - it's basically just the linux kernel but slimmed down. So, more compatible with most software.
smolvm is awesome. The team is highly responsive and very experienced. They clearly know what they’re doing.
I’m currently evaluating smolvm for my project, https://withcave.ai, where I’m using Incus for isolation. The initial integration results look very promising!
This looks super awesome. Very excited for you potentially open sourcing it, as I’d like to customize/extend it a bit for certain use cases. Re: smolvm vs in use, I think even if smolvm works great for it, why not keep incus as an option for people who want to use cave on VMs that don’t have access to /dev/kvm (Eg the user can pick either incus or smolvm for their cave deployment)
This is a very cool project and I'm happy to see it getting traction here. I stumbled upon it when I was looking to build something similar and surveying the state of the art...then I realized you built _exactly_ what I wanted!
im keen to check this out. since I've moved 100% to the Mac [1] I've been keen to move away from Docker to something like Apple Containers [2] which runs each "container" as an isolated vm. So I wanna try this out, too.
Neat! I work with the team on sbx. We built our own cross-platform VMM after running into limitations with the existing options. Happy to chat more about what you’ve built and what we’re doing: christopher<dot>crone@docker.com
@binsquare basically brute-force trimmed down unnecessary linux kernel modules, tried to get the vm started with just bare minimum. There are more rooms for improvement for sure. We will keep trying!
Yes. files on the disks are kept across stop and restart. We also have a pack command to compress the machine as a single file so that it can shipped and rehydrated elsewhere
question: why do you report that qemu is 15s<x<30s?
for instance with katacontainers, you can run fast microvms, and even faster with unikernels. what was your setup?
I ended up realizing that QEMU already supports microVMs and shipped https://github.com/rcarmo/pve-microvm yesterday. It's working out great for me, even if it's not portable in the same way (I can always do a .qcow dump, I guess)
This sounds great, except for one thing: you can scale your compute (CPU & RAM) as needed but your storage appears to scale with it.
So, if I use a "16 vCPUs, 32GB RAM, 400GB SSD" machine for a period of intense compute, and then want to scale that down to "2 vCPUs, 4GB RAM", most of my storage disappears?
That rather ruins the potential of the advertised scalability.
Hello, I'm building a replacement for docker containers with a virtual machine with the ergonomics of containers + subsecond start times.
I worked in AWS previously in the container space + with firecracker. I realized the container is an unnecessary layer that slowed things down + firecracker was a technology designed for AWS org structure + usecase.
So I ended up building a hybrid taking the best of containers with the best of firecracker.
Let me know your thoughts, thanks!
Hey this is super cool. I've been researching tech like this for my AI sandboxing solution, ended up with Lima+Incus: https://github.com/JanPokorny/locki
My problem with microVMs was that they usually won't run docker / kubernetes, I work on apps that consist of whole kubernetes clusters and want the sandbox to contain all that.
Does your solution support running k3s for example?
we will evaluate. I created this issue to track this: https://github.com/smol-machines/smolvm/issues/150
Really appreciate the feedback!
Curious what prevented you from running docker in a microvm? I've successfully run docker in qemu and firecracker microvms.
So we originally just wanted the vm to be light-weight and can start fast, so we removed docker. @binsquare has a change later to add docker back.
With instavm (https://instavm.io), you can provide an OCI image built from a dockerfile.
What is the status of supporting live migration?
That's the one feature of similar systems that always gets left out. I understand why: it's not a priority for "cloud native" workloads. The world, however, has work loads that are not cloud native, because that comes at a high cost, and it always will. So if you'd like a real value-add differentiator for your micro-VM platform (beyond what I believe you already have,) there you go.
Otherwise this looks pretty compelling.
It helps if you offer a concrete use case, as in how large the heap is, what kinda of blackout period you can handle, and whether the app can handle all of it's open connections being destroyed, etc. The more an app can handle resetting some of it's own state, the easier LM is going to be to implement. If your workload jives with CRIU https://github.com/checkpoint-restore/criu you could do this already.
By what I assume is your definition, there are plenty of "non cloud native" workloads running on clouds that need live migration. Azure and GCP use LM behind the scenes to give the illusion of long uptime hosts. Guest VMs are moved around for host maintenance.
"Azure and GCP use LM behind the scenes"
As does OCI, and (relatively recently) AWS. That's a lot of votes.
Use case: some legacy database VM needs to move because the host needs maintenance, the database storage (as opposed to the database software) is on a iSCSI/NFS/NVMe-oF array somewhere, and clients are just smart enough to transparently handle a brief disconnect/reconnect (which is built-in to essentially every such database connection pool stack today.)
Use case: a web app platform (node/spring/django/rails/whatever) with a bunch of cached client state needs to move because the host needs maintenance. The developers haven't done all the legwork to make the state survive restart, and they'll likely never get time needed to do that. That's essentially the same use case as previous. It's also rampant.
Use case: a long running batch process (training, etc.) needs to move because reasons, and ops can't wait for it to stop, and they can't kill it because time==money. It's doesn't matter that it takes an hour to move because big heap, as long as the previous 100 hours isn't lost.
"as in how large the heap is"
That's an undecidable moving target, so let the user worry about it. Trust them to figure out what is feasible given the capabilities of their hardware and talent. They'll do fine if you provide the mechanism. I've been shuffling live VMs between hosts for 10+ years successfully, and Qemu/KVM has been capable of it for nearly 20, never mind VMware.
"CRIU"
Dormant, and still containers. Also, it's re-solving solved problems once you're running in a VM, but with more steps.
Somewhat related: I have a branch of Ganeti that has first-class ZFS support baked in, including using ZFS snapshot replication to do live migration without shared storage or CEPH: https://github.com/linsomniac/ganeti
Current status is I'm looking for more feedback. In a few weeks when Ubuntu 26.04 comes out I'm going to set up my dev/stg clusters at work with it, at the moment I've only tested it in a test cluster at home.
It works this way: It creates a snapshot of the zvol, and replicates it to the secondary machine. When that's done, it does another snapshot and does a "catch up" replication (the first replication could take hours on large volumes). Pause the VM, do a final snapshot+replication. Replicate the working RAM. Start up the VM on the new host.
Really appreciate the suggestion! By "live migration", do you mean keeping the existing files and migrate them elsewhere with the vm?
Thanks
I mean making any given VM stop on host A and appear on host B; e.g. standard Qemu/KVM:
This is feasible when network storage is available and useful when a host needs to be drained for maintenance.Live migrations and the tech powering it was the hardest thing I ever built. Its something that I think will come naturally to projects like smolVM as more of the hypervisors build it in, but its a deeply challenging task to do in userspace.
My team spent 4 months on our implementation of vm memory that let us do it and its still our biggest time suck. We also were able to make assumptions like RDMA that are not available.
All that to say — as someone not working on smolVMs — I am confident smolVMs and most other OSS sandbox implementations will get live migration via hypervisor upgrades in the next 12 months.
Until then there are enterprise-y providers like that have it and great OSS options that already solve this like cloud hypervisor.
I see. so right now smolvm can be stopped, and then "packed" (think of it as compressed), and restart on a different host. files in the disks are preserved, but memory snapshotting is still hard tbh
Ultimately the original does get stopped, but with additional techniques, we're talking milliseconds of downtime between when the old one stops and the new one resumes. (For live migration technology in general, no clue about smol machines.)
It's also feasible without network storage, --copy-storage-all will migrate all disks too.
+1. i built something similar called shuru.run because i wanted an easy way to set up microVM sandboxes to run some of my AI apps, and firecracker wasn't available for macOS (and, as you said, it is just too heavy for normal user-level workloads).
Nice work on Shuru — I remember looking at it when I was researching this space. You went with a Rust wrapper on Apple’s Virtualization framework right?
I have been working on something similar but on top of firecracker, called it bhatti (https://github.com/sahil-shubham/bhatti).
I believe anyone with a spare linux box should be able to carve it into isolated programmable machines, without having to worry about provisioning them or their lifecycle.
The documentation’s still early but I have been using it for orchestrating parallel work (with deploy previews), offloading browser automation for my agents etc. An auction bought heztner server is serving me quite well :)
bhatti's cli looks very ergonomic! great job!
also, yes, shuru was (still) a wrapper over the Virtualization.framework, but it now supports Linux too (wrapper over KVM lol)
Is there a way to store configuration/data of applications running on a Bhatti VM on the host, ala Docker volumes?
Yes! Checkout the bhatti volume
They are ext4 blocks which exist independent of sandboxes.
Wow, that’s quite nice! I see that’s at VM time, any plans to add the ability to add them after the fact? I am really enjoying bhatti!
Yes, having a light-weight solution for local devices as well is one primary goal of the design. Another one is to make it easy for hosting, self or managed
What percentage of this code was written by LLM/AI?
For myself, I'd estimate ~50%
Not useful for things it hadn't been trained on before. But now I have the core functionality in place - it's been of great help.
What were the biggest challenges in terms of designing the VM to have subsecond start times? And what are the current bottlenecks for deceasing the start time even further?
No special programming tricks were used.
Linux was built in the 90s. Hardware improved more than a 1000x. Linux virtual machine startup times stayed relatively the same.
Turns out we kept adding junk to the linux kernel + bootup operations.
So all I did was cut and remove unnecessary parts until it still worked.
This ended up also getting boot up times to under 1s. The kernel changes are the 10 commits I made, you can verify here: https://github.com/smol-machines/libkrunfw
There's probably more fat to cut to be honest.
Any Windows support coming? My dev team is on Windows, this could be a game-changer.
Wsl2 runs a Linux vm so it definitely feasible and has the api's necessary.
It is on the roadmap, but frankly I haven't used Windows in a decade. I would love for a contributor to take that on as part of the free and open source spirit.
Sounds like it could be you? :)
>Sounds like it could be you? :)
I wish it could, but, like your housekeeper, I don't do Windows. ;-)
You could add OrbStack to the comp. table
Will do. Thanks for the suggestion!
The images or rather portable artifacts rehydration on any platform plus the packaging is neat. I have been working on https://instavm.io for some time around VM based sandboxes and related infra for agents and this is refreshing to see.
hi, great project! Windows support is sorely lacking, though. As someone working a lot with sandboxed LLMs right now, the options-space on windows for sandboxing is _extremely lacking_. Any plans to support it?
Hey, thanks so much! yah we will definitely add windows support later. We are exploring how to get this work with WSL and will release it asap. Stay tuned and thanks!
Yeah, it's in my mind.
WSL2 runs a linux virtual machine. Need to take some time and care to wire that up, but definitely feasible.
Not sure what level of sandboxing you need. Is Sandboxie not enough?
How is this different from lxd/lxc? How tied is this to kvm or could it work with other hypervisors like xcp-ng, VMware, or virtual box?
lxc/lxd are ~container managers, the kernel is still shared like docker containers. It runs on linux & needs to run in a linux virtual machine on macOS.
smolvm is a virtual machine with the ergonomics of containers like packaging and distributing, kernel is not shared. You'd run containers inside of smolvm.
Also, smolvm runs ontop of both kvm for linux and apple's hypervisor for macOS. So it's cross platform.
Just curious if this allow to sync file changes from host to vm which only Docker has that and no other VM alternative has that ability.
it has directory mounts - so access the same files: https://github.com/smol-machines/smolvm/blob/main/AGENTS.md?...
It also has file copy from host to inside the guest: https://github.com/smol-machines/smolvm/blob/70c97930dda5a92...
How is this different than Kara Containers?
kata containers is a container runtime that focuses on running containers inside a vm.
smolvm is a vm with some of the properties & ergonomics of containers - it's meant as a replacement for containers.
The feature that lets you create self-contained binaries seems like a potentially simpler way to package JVM apps than GraalVM Native.
Probably a lot of other neat usecases for this, too
yeah, it's analogous to Electron.
Electron ships your web app bundled with a browser.
Smol machines ship your software packaged with a linux vm. No need for dependency management or compatibility issues because it is baked in.
I think this is how Codex or Claude Code should be shipped by default, to avoid any isolation issues tbh
How "fat" are the packed machines? In other words, how much bloat is inevitable, or is that entirely controlled by the base image + the user's smolvm machine spec? How does smolvm's pack compare to something like dockerc [0] in terms of speed and size? Disclaimer: I just learned about dockerc!
I can't actually create and test a pack right now because of [1], but I love the idea of using this to distribute applications you might otherwise use a Docker image for.
[0] https://github.com/NilsIrl/dockerc
[1] https://github.com/smol-machines/smolvm/issues/159
pretty light weight!
About the same size as the docker image to be honest. Join the discord and I'm happy to give you a white glove experience with onboarding :)
https://discord.gg/E5r8rEWY9J
yah, i guess everybody share the experience of "i messed up with my dev env" right? We want this "machine" to be shippable, meaning that once it is configured correctly, it can be shared to anyone and use right away.
Can .smolmachine be digitally signed and self authenticate when run? Similar to https://docs.sylabs.io/guides/main/user-guide/signNverify.ht...
probably, don't see why not based on cursory glance.
will look into it
I see the alpine and python:3.12-alpine images in your cli docs. Where does these come from?is it from a docker like registry or are these built in? Can I create my own images? Or this this purely done with the smolfile? Is there a Ubuntu image available?
Looks really nice btw. Hot resize mem/cpu would be nice. This could become a nice tech for a one-backend-per-customer infra orchestrator then.
What are you actually doing on top of libkrun? Providing really small machine images that boot quickly? If I run the smolvm run --image alpine example, what is "alpine?" Where is that image coming from? Does this have some built-in default registry of machine images it pulls from? Does it need an Internet connection that allows outbound access to wherever this registry runs? Is it one of a default set of pre-built images that comes with the software itself and is stored on my own filesystem? Where are the builds for these images? Where do these machine images end up? ~/.local/share/smolvm/?
i run a custom fork of libkrun, libkrunfw (linux kernel), etc etc: https://github.com/orgs/smol-machines/repositories
Got a lot of questions on how I spin up linux VM's so quickly
Explanation is pretty straight forward.
Linux was built in the 90s. Hardware improved more than a 1000x. Linux virtual machine startup times stayed relatively the same.
Turns out we kept adding junk to the linux kernel + bootup operations.
So all I did was cut and remove unnecessary parts until it still worked. This ended up also getting boot up times to under 1s.
Big part of it was systemd btw.
those images are pulling from the public docker registry.
Great job with the comparison table. Immediately I was like “neat sounds like firecracker” then saw your table to see where it was similar and different. Easy!
Nice job! This looks really cool
Thanks so much
Basically any open source project nowadays run their software stack in containers often requiring docker compose. Unfortunatley Smol machines do not support Docker inside the microvms and they also do not support nested VMs for things that use Vagrant. I think this is a big drawback.
I can support docker - will ship a compatible kernel with the necessary flags in the next release.
I tried something like this already, also including nested kvm. I think this will increase the boot time quiet a bit.
Also libkrun is not secure by default. From their README.md:
> The libkrun security model is primarily defined by the consideration that both the guest and the VMM pertain to the same security context. For many operations, the VMM acts as a proxy for the guest within the host. Host resources that are accessible to the VMM can potentially be accessed by the guest through it.
> While defining the security implementation of your environment, you should think about the guest and the VMM as a single entity. To prevent the guest from accessing host's resources, you need to use the host's OS security features to run the VMM inside an isolated context. On Linux, the primary mechanism to be used for this purpose is namespaces. Single-user systems may have a more relaxed security policy and just ensure the VMM runs with a particular UID/GID.
> While most virtio devices allow the guest to access resources from the host, two of them require special consideration when used: virtio-fs and virtio-vsock+TSI.
> When exposing a directory in a filesystem from the host to the guest through virtio-fs devices configured with krun_set_root and/or krun_add_virtiofs, libkrun does not provide any protection against the guest attempting to access other directories in the same filesystem, or even other filesystems in the host.
Thanks so much for the feedbacks. Yes these are valid concerns around libkrun security, We are planning and developing features around them actually, and hopefully that could alleviate the conerns.
for virtio-fs, yes the risk of exposing the host fs struture exists, and we plan to:
1. creating staging directory for each vm and bind-mount the host dir onto them
2. having private mount namespaces for vms
they are both tracked in our github issues:
https://github.com/smol-machines/smolvm/issues/152 https://github.com/smol-machines/smolvm/issues/151
2 may need much more efforts than we imagine, but we will ensure to call this out in our doc.
For the concern around TSI, we are developing virtio-net in-parallel, it is also tracked in our github and will be released soon: https://github.com/smol-machines/smolvm/issues/91
Would like to collect mroe suggestions on how to make this safer. Thanks!
Security is a broad topic.
Here's how my perspective:
smolvm operates on the same shared responsibility model as other virtual machines.
VM provides VM-level isolation.
If the user mounts a directory with the capability of symlinks or a host OS with a path for guest software that is designed to escape - that is the responsibility of the user rather than the VM.
Security is not guaranteed by using a specific piece of software, it's a process that requires different pieces for different situations. smolvm can be a part of that process.
So Vagrant is launching the VM locally, is that why it needs nesting?
Would you be ok with a trampoline that launched the VM as a sibling to the Vagrant VM?
Could it be made even faster using some of the ideas from https://github.com/zerobootdev/zeroboot ?
Their idea is actually more akin to cloning and a more refined implementation is used in Lambda's snapstart: https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
So directionally yes. But it relies on kvm. I focus on portability i.e. cross platform for local macOS and linux, so that is not top of mind for me right now.
What I really like about containers is quickly being able to spin one up without having to specify resources (e.g. RAM limit). I hope this would let me do that also.
This does that.
I'm trying to do away the model of cpu and memory tbh.
Virtio- balloon dynamically resizes based on memory consumed.
CPU is oversubscribed by default
Sounds amazing! I hope it can replace "docker run --rm" for me. Nice work!
Hey this is pretty neat! I definitely would try using this for benchmarks and other places where I need strong isolation as Docker is just too bloated and slow, but sadly I don't think I can run this natively on my Windows laptop. I hope you extend to WSL! Good luck and congrats on launch.
If you're using wsl2, /dev/kvm should be available. You may need to install a couple extra packages to enable kvm etc.
Hey thanks so much for the feedback. Yah try it and let us know. We have a discord if you want to join, but either github or discord feel free to report any issues you find to us.
Cheers!
Is there a relation to the similarly-purposed and similarly-named https://github.com/CelestoAI/SmolVM
no relation, they build a sandboxing service using firecracker.
I build a virtual machine that is an alternative to firecracker and containers.
We’re using smolmachines to create environments for our agents to execute code. It’s been great so far and the team is super responsive. The dev ergonomics are also great.
Really appreciate it! Would love to work together to make this easier to use.
This project is very cool! One readme nit: "Pack a stateful virtual machine into a single file (.smolmachine) to rehydrate on any supported platform." For awhile I thought this meant that you could rehydrate a machine's memory like you can with a firecracker vm, but as far as I can tell you can't? It's stateful == disk?
Why would I prefer smol machines over docker sandbox? Do you have an elevator pitch?
Docker sandbox is also not open source
uhh sort of different things.
smol machines is a virtual machine that has properties and ergonomics of containers. It's not an ai project, it's designed to run any software inside.
docker sandbox sounds like it's running ai stuff inside of a microvm.
So if you need to use a virtual machine - use smol machines.
If you need a to run coding agents, use smol machines still because agents are just software.
I think I see one new VM / sandbox thingie a week.
> If you need a to run coding agents, use smol machines still because agents are just software.
I get mixed signals from your argument
it was a tongue in cheek response :), completely fair take
Sounds very similar to the various unikernel implementations floating around ? Such as Unikernel[1]
[1] https://unikraft.org
unikraft's internals are not open source so I can't say.
But smol machines are not an implementation of unikernel - it's basically just the linux kernel but slimmed down. So, more compatible with most software.
This looks very cool. Does the VM machinery still work if I run it in a bubblewrap? Can it talk to a GPU?
Can you pipe into one? It would be cute if I could wget in machine 1 and send that result to offline machine 2 for processing.
Haven't tried with bubblewrap - but it should.
Yes! GPU passthrough is being actively worked on and will land in next major release: https://github.com/smol-machines/smolvm/pull/96
Yea just tried piping, it works:
``` smolvm machine exec --name m1 -- wget -qO- https://example.com/data.csv \ | smolvm machine exec --name m2 -i -- python3 process.py ```
Give it a try folks. Would really love to hear all the feedbacks!
Cheers!
why did you seemingly create two HN accounts?
Edit: I see this appears to be a contributor to the project as well. It was not obvious to me.
this is me: https://github.com/phooq
@binsquare is this one: https://github.com/BinSquare
No worry at all! Thanks!
smolvm is awesome. The team is highly responsive and very experienced. They clearly know what they’re doing.
I’m currently evaluating smolvm for my project, https://withcave.ai, where I’m using Incus for isolation. The initial integration results look very promising!
This looks super awesome. Very excited for you potentially open sourcing it, as I’d like to customize/extend it a bit for certain use cases. Re: smolvm vs in use, I think even if smolvm works great for it, why not keep incus as an option for people who want to use cave on VMs that don’t have access to /dev/kvm (Eg the user can pick either incus or smolvm for their cave deployment)
Cannot thank you more for this! Lets' work together to see how we can make this easier for cave!
This is a very cool project and I'm happy to see it getting traction here. I stumbled upon it when I was looking to build something similar and surveying the state of the art...then I realized you built _exactly_ what I wanted!
Thank you, great work!
im keen to check this out. since I've moved 100% to the Mac [1] I've been keen to move away from Docker to something like Apple Containers [2] which runs each "container" as an isolated vm. So I wanna try this out, too.
[1] shameful self plug: https://gigatexal.blog/pages/i-heart-my-macbook/i-heart-my-m...
[2] https://github.com/apple/container
Let us know your thoughts! Thanks
Any integration with existing orchestrators? Plans to support any or building your own?
Will build a free open source self serve orchestration to enable subsecond vm vending
But should be easy for anyone to build their own integration with existing as well like nomad.
Doesn't Docker's sbx do this?
https://docs.docker.com/reference/cli/sbx/
sandboxing is one of the features of virtual machines.
I'm building a different virtual machine.
Neat! I work with the team on sbx. We built our own cross-platform VMM after running into limitations with the existing options. Happy to chat more about what you’ve built and what we’re doing: christopher<dot>crone@docker.com
see too[0][1] for projects of a similar* vein, incl historical account.
*yes, FreeBSD is specifically developed against Firecracker which is specifically avoided w "Smol machines", but interesting nonetheless
[0] https://github.com/NetBSDfr/smolBSD
[1] https://www.usenix.org/publications/loginonline/freebsd-fire...
that was one of my inspirations but I don't think they went far enough in innovation.
microvm space is still underserved.
> that was one of my inspirations
Colins FreeBSD work or Emiles NetBSD work?
netBSD, I love that focus on a minimal and simple, reproducible binaries.
You'll see that philosophy in this project as well (i hope).
freeBSD focuses on features, which is great too.
I see you support Linux and MacOS hosts. Any Windows support planned?
Yeah it's feasible, I don't have windows to test. Can you help? :D
This is very exciting. It enables a cross platform, language agnostic plugin system, especially for agents, while being safe in a VM.
Wow, this seems very useful for coding agent sandbox environments that have full browser installations and the like.
its a really innovative idea! very interested in the subsecond coldstart claim, how does it achieve that?
@binsquare basically brute-force trimmed down unnecessary linux kernel modules, tried to get the vm started with just bare minimum. There are more rooms for improvement for sure. We will keep trying!
With this approach I managed to get to sub-10ms start (to pid1), if you can accept a few constraints there's plenty of room!
Though my version was only tested on Linux hosts
would be interested to see how you do it, how can I connect with you - emotionally?
https://blog.davidv.dev/posts/minimizing-linux-boot-times/
Start with booze; always works :)
nice! for most local workloads, it is actually sufficient. so, do you ship a complete disk snapshot of the machines?
Yes. files on the disks are kept across stop and restart. We also have a pack command to compress the machine as a single file so that it can shipped and rehydrated elsewhere
hi! congrats for your work that's really nice.
question: why do you report that qemu is 15s<x<30s? for instance with katacontainers, you can run fast microvms, and even faster with unikernels. what was your setup?
thanks a lot
Would love to have this as a Proxmox guest type
Smolvm is free and open source, help me build the integration with proxmox - I'm not familiar with it
I ended up realizing that QEMU already supports microVMs and shipped https://github.com/rcarmo/pve-microvm yesterday. It's working out great for me, even if it's not portable in the same way (I can always do a .qcow dump, I guess)
How does it compare to podman with crun-vm ?
Congrats that looks really amazing!
This looks awesome. Thanks for sharing!
Thanks so much! Feel free to try it out if you have a chance, and let's us know your thoughts. Thanks!
https://shellbox.dev is a hosted version of something very similar
This sounds great, except for one thing: you can scale your compute (CPU & RAM) as needed but your storage appears to scale with it.
So, if I use a "16 vCPUs, 32GB RAM, 400GB SSD" machine for a period of intense compute, and then want to scale that down to "2 vCPUs, 4GB RAM", most of my storage disappears?
That rather ruins the potential of the advertised scalability.
How many smolvm can you find?
not enough and too much at the same time
congrats on the launch binbin, this is cool!
I like the name ! :)
Me too but I loove the icon
thanks, it's my hand traced over and then made pretty.
https://github.com/earendil-works/gondolin is another project addressing a similar use-case.
See also SmolBSD -- similar idea, similar name, using NetBSD.
I came across SmolBSD before too. Cool project!