Hello, It's great that you ask that. For my initial use case I used `guix system vm` which uses qemu behind the scenes, but I wanted a bit more flexibility similar to what guix container provides but using a VM instead for isolation.
Microvm and the `guix system vm` does share concepts, both generate normal raw images, use the same procedure to access data from the operating-sytem records and use that information to start cloud-hypervisor or qemu. I am not reinventing the wheel. Microvm is just a fancy word for having the minimum hardware support required to boot a machine quickly; it's a subset. See qemu document <https://www.qemu.org/docs/master/system/i386/microvm.html> on it. In my first PoC, I experimented with modifying the Guix VM implementation to support MicroVM and increase its flexibility. But I found it risky since tests infrastructure depends on it. I think it would have been more disruptive and possibly a harder sell.. :) So, I chose to use cloud-hypervisor. I gained a good understanding of the current internals, but using another vmm gave me the opportunity to create a higher level API to support other vmm like qemu, firecracker, etc. Also, I would like to *make it possible to run other OS.* Note that using cloud-hypervisor has downsides that qemu doesn't have if you use the 9p filesystem. (qemu also requires virtiofsd if you use virtiofs, virtiofs is preferred because it's faster.) If you share a *Host* directories it requires virtiofsd to make it available in the host. You need some form of orchestration to ensure that *virtiofsd* starts before the vmm. Sorry for the long introduction, but I wanted to provide more context for what I was thinking. On Sat, May 23, 2026 at 12:46 PM Ricardo Wurmus <[email protected]> wrote: > > > Have you considered supporting microvms with "guix system vm"? Or > do they use the same underlying image format? Regarding adding microvm support for (guix system vm), I thought about it and my current plan is to add support for qemu to microvm, either for any machine type or just the microvm type. Then, we could write a small wrapper that converts a 'virtual-machine' into a microvm. However, I need to investigate several things to determine if my suggestions above are possible: - I don't know how Marionette works with the current VM setup. - Are there tests that require fancy hardware that a microvm doesn't provide? (requiring the code to support multiple machine types). - What happens in different architectures. Because of that, it's totally possible that microvm and the current vm answer completely different use cases and that's OK too. Thanks for the replies; I'm happy to chat about it. As I've said it's an experiment. -- ph
