
Announcing qboot, a minimal x86 firmware for QEMU - mmastrac
https://lwn.net/Articles/645455/
======
viraptor
This is great, but lately I just can't keep up with the virtualisation
changes. I got really excited about google's novm - that's dead now. kvmtools
never got included into kernel afaik. qboot will be great, but it looks like
it doesn't really support the light IO solutions (like novm's file, rather
than block access). Now there's clear containers which is actually kvm, which
looks like docker-meets-qboot. And many others in between.

This doesn't seem right, honestly. Half of the projects have the same approach
or goals. (quick boot time and no legacy supported) So why do they die and get
reinvented every single time?

Something is wrong...

~~~
stefanha
> it doesn't really support the light IO solutions (like novm's file, rather
> than block access)

That is incorrect. novm just implements the virtio-9p device that QEMU has
supported for years.

Clear Linux does add something new: a pmem (NVDIMM) device that bypasses the
guest kernel's page cache. This involves host kernel, guest kernel, and
kvmtool changes.

The advantage of pmem is that short-lived VMs can directly access data from
the host instead of copying in. But this feature needs to be added to QEMU/KVM
anyway to support new persistent memory hardware (see
[http://pmem.io/](http://pmem.io/)) so it won't be unique for long.

~~~
antocv
Also virtio-9p is slow as hell.

~~~
throwaway7767
> Also virtio-9p is slow as hell.

I've heard that from others, but I wonder why that is. I would expect a file-
level abstraction to be faster due to less I/O roundtrips for transfers and
the removal of the block-abstraction. Is it just an inefficient protocol or
are there some inherent bottlenecks in a file-level sharing protocol that I'm
missing?

How slow is it really? Slower than NFS for example?

~~~
dezgeg
If you want both the host and the VM to have a coherent view of the
filesystem, the VM can't really do efficient caching.

~~~
throwaway7767
> If you want both the host and the VM to have a coherent view of the
> filesystem, the VM can't really do efficient caching.

That makes sense, though it's surprising then that it's not possible to
explicitly enable caching if that's the bottleneck and a coherent view from
the host side is not a necessity for a given workload.

------
ghshephard
New Industries (EC2 and friends) in hosting/cloud services were created with
the advent of convenient virtualization. technologies.

I wonder what types of services/industries will be created when you can
reliably spin up a hosted instance in 40-60 ms.

~~~
vidarh
I don't want to spin up instances. I want to spin up functions.

~~~
ghshephard
Essentially that's what a call out to Amazon's varied AWS services are though,
right?

~~~
vidarh
Except that means you're calling out to fixed functions except for with
Lambda, but the overheads with Lambda are still orders of magnitude above what
you'd want for it to be practical to just decompose your app into functions
run separately like that.

To be fair, making a system like that efficient is an unsolved problem even in
far more tightly integrated supercomputer systems - IO quickly becomes a
massive bottleneck and current hardware is CPU rich and IO poor.

------
gwu78
Next up: a minimal QEMU.

