Experimental KVM-based VMM, Written in Go
1–10 of 48 posts
Re: Experimental KVM-based VMM, Written in Go
#2Off topic. In README, it says "This is not an official Google product.". I've seen that line in some repos under github.com/google organizations. What does it really mean ?
Re: Experimental KVM-based VMM, Written in Go
#3Off topic. In README, it says "This is not an official Google product.". I've seen that line in some repos under github.com/google organizations. What does it really mean ?
20% projects maybe? If nothing else, it's a nice perk.
Re: Experimental KVM-based VMM, Written in Go
#4Because 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/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.
Re: Experimental KVM-based VMM, Written in Go
#5Best bit from the README file:
"novm was originally called pervirt, but this name was changed after it was suggested that this name could be misconstrued."
Re: Experimental KVM-based VMM, Written in Go
#6Because 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…
Is it interesting if only because it's written in a "memory-safe"* language?
* Terms and conditions apply.
Re: Experimental KVM-based VMM, Written in Go
#7Off topic. In README, it says "This is not an official Google product.". I've seen that line in some repos under github.com/google organizations. What does it really mean ?
(Edit: comment below from DannyBee is authoritative.)
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.
Re: Experimental KVM-based VMM, Written in Go
#8On a related note, Google's compute service is supposed to be kvm+not qemu. Does anyone know anything about the latter?
Re: Experimental KVM-based VMM, Written in Go
#9Because 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…
One could write a Windows IFS driver for 9P if that had some benefit. As it is, there's a Windows IFS FUSE driver that has a 9P server written for it.
Re: Experimental KVM-based VMM, Written in Go
#10Because 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…
Could this in any way explain why Google Cloud does not support Ubuntu?