Live data from Hacker News

Experimental KVM-based VMM, Written in Go

github.com

21–30 of 48 posts

Re: Experimental KVM-based VMM, Written in Go

#21
post #7

Earlier quoted context omitted.

(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 fi…

"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 google…

It'd probably help to only publish official things under the google/ namespace on github, but I guess it's too late for that. :)

Re: Experimental KVM-based VMM, Written in Go

#22

On a related note, Google's compute service is supposed to be kvm+not qemu. Does anyone know anything about the latter?

I've only heard rumors of its code name: Vanadium (but would love to get confirmation of that). Would be great to get this open source -- the world could use KVM + not-QEMU. Speaking for us in SmartOS, we didn't like where QEMU was headed, and we have essentially forked it for our KVM implementation -- we would love to explore Vanadium, if that's even what it's called.. ;)

What is wrong with where QEMU is headed?

Re: Experimental KVM-based VMM, Written in Go

#23
post #21

Earlier quoted context omitted.

"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 google…

It'd probably help to only publish official things under the google/ namespace on github, but I guess it's too late for that. :)

github namespacing at the time made this kind of a pain (we still needed to be able to admin the projects, etc), but yeah.

Re: Experimental KVM-based VMM, Written in Go

#24
post #4

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…

9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance.

> 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.

Re: Experimental KVM-based VMM, Written in Go

#25
post #4

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…

>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.

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.

Re: Experimental KVM-based VMM, Written in Go

#26
Author here.

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/...

Re: Experimental KVM-based VMM, Written in Go

#28
post #4

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…

9p works from OSes other than Linux; there's a driver for Windows as well. That said, it will likely always work best in Linux. Unfortunately, even over virtio, 9p has awful performance. > 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…

I imagine seccomp and ptrace have pretty similar performance, since they both wake the 'host' using a signal, and stay out of the way until their trigger is met. As for UML stability, Debian have been providing packages of it for years, I can't remember the last time I built it directly.

Re: Experimental KVM-based VMM, Written in Go

#29

Author here. 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/...

i can't figure out which one of the several Go9P implementations you started with. or is this something you rolled out yourself? any differences between this and others?

Re: Experimental KVM-based VMM, Written in Go

#30
post #29

Author here. 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/...

i can't figure out which one of the several Go9P implementations you started with. or is this something you rolled out yourself? any differences between this and others?

It was go9p (https://code.google.com/p/go9p/).

But it was heavily modified (nearly rewritten, except fmt.go and p9.go) to suit my specific needs.

Post reply on HN