Experimental KVM-based VMM, Written in Go • Hacker News Board

Re: Experimental KVM-based VMM, Written in Go

#11

Post by [deleted] » Wed, Jan 07, 2015, 5:23 PM UTC

philip1209 wrote: post #10

_wmd wrote: 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…

Could this in any way explain why Google Cloud does not support Ubuntu?

[deleted]

Re: Experimental KVM-based VMM, Written in Go

#12

Post by _wmd » Wed, Jan 07, 2015, 5:25 PM UTC

derefr wrote: post #9

_wmd wrote: 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…

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.

You could, but you almost certainly don't want to.. Network filesystems that try to emulate regular filesystem semantics fundamentally suck, not least because you basically can't do any useful caching, and the caching that is done (because it must be done) can introduce very hard to detect bugs (e.g. coherence between a file and its in-memory mapping. If you want to execute a program from the filesystem you need such a mapping).

Re: Experimental KVM-based VMM, Written in Go

#13

Post by onedognight » Wed, Jan 07, 2015, 5:25 PM UTC

_wmd wrote: 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…

> it forces the guest to do basically no useful caching of its file system

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.

Re: Experimental KVM-based VMM, Written in Go

#14

Post by DannyBee » Wed, Jan 07, 2015, 5:26 PM UTC

Xorlev wrote: post #3

yla92 wrote: post #2

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

No, evmar has it right. It means it is some random googler's code. It means Google has literally nothing to do with it, other than happening to own the code.

(IE it's not an experimental product, it's not a product at all. It's just some guy releasing some code)

Re: Experimental KVM-based VMM, Written in Go

#15

Post by 4ad » Wed, Jan 07, 2015, 5:26 PM UTC

derefr wrote: post #9

_wmd wrote: 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…

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.

Ignoring details like the impossibility of loading the kernel (because the Windows kernel requires to be loaded by its own bootloader, which does a lot of setup), you will not be able to boot from 9P.

Re: Experimental KVM-based VMM, Written in Go

#16

Post by shillster » Wed, Jan 07, 2015, 5:26 PM UTC

_wmd wrote: 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…

If you take a glance at Paragraph 1 of the Readme (its the main description for the project), it says, "Its goal is to provide an alternate, high-performance Linux hypervisor for cloud workloads." So you can probably answer your own question about the intentions of this project.

Re: Experimental KVM-based VMM, Written in Go

#17

Post by morpher » Wed, Jan 07, 2015, 5:31 PM UTC

philip1209 wrote: post #10

_wmd wrote: 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…

Could this in any way explain why Google Cloud does not support Ubuntu?

GCE added Ubuntu support recently:https://cloud.google.com/compute/docs/operating-systems/linu...

Re: Experimental KVM-based VMM, Written in Go

#18

Post by bstx » Wed, Jan 07, 2015, 5:39 PM UTC

Incidentally, someone is working on Go bindings for the OS X Hypervisor (https://github.com/penberg/go-osxhv).

Re: Experimental KVM-based VMM, Written in Go

#19

Post by bcantrill » Wed, Jan 07, 2015, 5:40 PM UTC

krakensden wrote: post #8

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

Re: Experimental KVM-based VMM, Written in Go

#20

Post by DannyBee » Wed, Jan 07, 2015, 6:03 PM UTC

evmar wrote: post #7

yla92 wrote: post #2

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