Experimental KVM-based VMM, Written in Go
github.com
github.com
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/libvirt
edit: 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.
* Terms and conditions apply.
Of a filesystem was the impression I got. The author implied that you could, in addition, mount any block device provided to you in any way you wanted.
> It can't even boot a standard vmlinuz.
It was mentioned at the end that while it won't run the real-mode code therein, it will attempt extract the elf binary and run that.
> The remaining alternative is on-demand synthesis of a block image given a directory tree, which IIRC Qemu supports.
If you mean vvfat, that hasn't worked in quite a while, and it never supported writes.
> 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.
UML tends to bitrot; it's hit or miss whether it even compiles in each new release, and it doesn't get any significant new development. It also relies on ptracing the target process, which is rather awful; unfortunately there's no better way to implement userspace syscalls.
I wonder if UML could be accelerated by adding some new features to the BPF-based seccomp to support syscall emulation? BPF could translate each syscall into some efficient communication to the UML kernel process.
Alternatively, with a 64-bit address space available, UML could learn to do its own memory and process management, and not rely on host Linux processes at all.
UML used to have some host kernel patches that were a lot faster for intercepting syscalls. There was never enough interest (even before Vanderpool/Pacifica) to merge it though.
The throughput is passable, if you do large enough reads; however, the latency for individual operations is terrible. Try booting via virtio-9p and building a kernel inside the virtual machine, as compared to the host system. Last time I tried it, it took several orders of magnitude longer, due in large part to the latency of simple operations like stat or open/read/close.
That being said, calling QEMU's 9P "9P", is a stretch. 9P was designed wit multiplexing in mind, but it's not multiplexed in QEMU, in fact multiplexing in QEMU uses a completely different mechanism. You can't mount QEMU's thing in Plan 9 (unless someone added support for this when I wasn't looking).
Do you have a link to the Windows virtio 9p driver? I'm not aware of such a thing existing.
Sure, but I assume the host/hypervisor is doing the caching on its side, so this may not be a huge loss for the gain.
Although the Linux implementation for 9p isn't great, there's nothing "fundamental" that limits the caching in the guest. For many use cases, you will have no shared mutable state in the host. Think docker: you have some shared read-only state, but the write bits are yours alone. You may cache anything freely.
This project was simply about playing with these ideas (and implementing a VMM using Go). You should check the slides out to understand the gap that I was looking at, but suffice to say I think there's a wide opportunity for something that gives you a process-like model but whose interface is that of a virtual machine. The key point is that you don't really want an ultra-quick "machine", you probably want to run a process ala Docker. I still want it to be contained as a VM however, for security and compatibility reasons.
As noted at the top of the README (and by others here), this is not an official Google product. It's an experimental project, mostly to play with some ideas (and Go).
I gave a talk at LinuxCon in August about novm. The slides may also be of interest, and are available here: http://events.linuxfoundation.org/sites/events/files/slides/...
But it was heavily modified (nearly rewritten, except fmt.go and p9.go) to suit my specific needs.
I have no idea how used it is. If it's useful to you, I'll happily invest more time to address some niggling issues (flakey tests, etc.) and maintaining it.
It's been a lifesaver at my startup, especially when we are running many different (micro)services.
(IE it's not an experimental product, it's not a product at all. It's just some guy releasing some code)
Google has two paths to open sourcing code: in one Google retains the copyright (but grants a permissive license like Apache), and in the other you retain the copyright but cannot work on it on Google time or Google hardware. (You can tell which category a given piece of software is under by looking at the license headers on the code; the linked software is the first category.)
It's easier to release software under the first category, even if it's just some random hack you tinker with. (I frequently hack on stuff on my corporate-provided laptop.) But if you do so then the code has the word Google all over it even if it's not something the company intends to support. I don't know for certain the reasoning but I imagine the sentence you quote helps reduce confusion about who is sponsoring the project.
Yes. I've updated the sentence a bit for future projects. But historically, what has happened, is that people make a lot of assumptions about code Google releases and what it means for X or Y.
I've seen entire press stories about how Google has created some new product that does X or Y, when it's just some random googler's code.
(This started even before it was in the google namespace on github, and it was just a random code.google.com project).
It seems without some disclaimer, it is roughly impossible to get people to disassociate the two.