Experimental KVM-based VMM, Written in Go
Because it's not obvious without glancing at the code, this relies on 9P-over-virtio to implement the filesystem, which means its pretty much always going to be limited to running Linux images. This sounds like a nice and clean solution, but at least it forces the guest to do basically no useful caching of its file system, in order to remain coherent with the host fs.The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports.As always, making a couple of syscalls isn't a huge amount of work, and this project punts on anything difficult (e.g. supporting traditional boot environment & emulated devices) needed for handling basically any other OS. It can't even boot a standard vmlinuz.Not sure what gap this is supposed to fill. If you're running a Linux host, and you want ultra-quick dev machine booted from your filesystem, User Mode Linux already exists and has way more support and flexibility. If you need support, performance, and code that's been security audited, you probably want Qemu/Xen/libvirtedit: just because it may not be clear to a lot of people.. Literally KVM setup is a handful of ioctl() system calls, almost everything non-device-emulation related is handled by Linux for you. So when you say you're implementing a KVM-based hypervisor that doesn't implement any device emulation, that is to say there's very little real work being done. It's easy to claim to be fast when your code does nothing. The only special sauce left is a fundamentally slow method for handling the root filesystem which is worth avoiding for the reasons I mentioned.