
Show HN: microvm – a minimalist machine type for QEMU inspired by Firecracker - slpnix
https://github.com/qemu/qemu/blob/master/docs/microvm.rst
======
yjftsjthsd-h
Oh, nice: props for including precise, fully worked example commands to
actually use this. This is so helpful in terms of onboarding and being able to
actually get people to use a project:)

~~~
bloopernova
If I was an eccentric billionaire, I'd reward good documentation with an open
source doc prize.

It's so difficult to impress upon some people just important documentation is.
And when they do it, they half-ass it by copying stuff from source code and
not adding any context.

~~~
gigatexal
+100 to this. I’ve become a cheerleader for some projects just because the
documentation was so good that it was easy to get started. It’s how I became a
ZFS zealot among other things.

~~~
voltagex_
OT: where do you find the good ZFS documentation? Googling always seems to
turn up Oracle's documentation, which may not match what's in FreeBSD or ZFS-
on-Linux

~~~
stock_toaster
The zfs man pages (at least on FreeBSD) are actually pretty decent for finding
command usage. The FreeBSD handbook[1] covers some typical usages.

[1]:
[https://www.freebsd.org/doc/handbook/zfs.html](https://www.freebsd.org/doc/handbook/zfs.html)

------
maxmcd
Firecracker requires KVM, but QEMU can be used with instruction emulation,
correct? Does that make this potentially a little easier to develop with in
certain environments?

~~~
slpnix
That's correct. The initial versions of the microvm patch series did require
KVM, but the one that got upstreamed does work with TCG [1], thanks to the
QEMU's maintainers feedback.

That said, I'm not sure for which kind of use cases it would be useful to run
it this way, as the performance won't be amazing. I find TCG acceleration
mainly useful for debugging and foreign systems emulation.

[1]
[https://wiki.qemu.org/Documentation/TCG](https://wiki.qemu.org/Documentation/TCG)

------
StreamBright
What are the differences compare to Firecracker?

~~~
slpnix
From the guest perspective, the differences are minimal. Even boot time of the
guest (thinking about a custom-built minimalist Linux kernel here) is roughly
the same.

On the host side, things are more interesting. Firecraker has a smaller TCB
(Trusted Computing Base), is written in Rust, and is statically linked. On the
other hand, QEMU provides more features (especially in the block layer, with
more formats, network-based block devices, asynchronous I/O...), can be
configured at build time to adapt it to a particular use case, and has a
pretty good security record.

In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from
each other, giving users more options to choose from. Everybody wins.

~~~
rrdharan
> QEMU... has a pretty good security record

That's an interesting and I would argue, contrarian take?

[https://www.theregister.co.uk/2017/01/30/google_cloud_kicked...](https://www.theregister.co.uk/2017/01/30/google_cloud_kicked_qemu_to_the_kerb_to_harden_kvm/)

"QEMU has a long track record of security bugs, such as VENOM, and it's
unclear what vulnerabilities may still be lurking in the code."

~~~
slpnix
I think the slide 14 from the talk "Reports of my Bloat Have Been Greatly
Exaggerated" [1] presented by Paolo Bonzini at KVM Forum 2019 gives some good
perspective about QEMU's security track:

"Of the top 100 vulnerabilities reported for QEMU:

\- 65 were not guest exploitable

\- 3 were not in QEMU :)

\- 5 did not affect x86 KVM guests

\- 3 were not related to the C language

\- Only 6 affected devices normally used for IaaS

The most recent of these 6 was reported in 2016"

The rest of this talk was also very interesting. I encourage everyone with 10
minutes to spare and an interest in VMMs to take a look at the slides.

[1]
[https://static.sched.com/hosted_files/kvmforum2019/c6/kvmfor...](https://static.sched.com/hosted_files/kvmforum2019/c6/kvmforum19-bloat.pdf)

~~~
mato
> "Of the top 100 vulnerabilities reported for QEMU:

> \- 65 were not guest exploitable

> [...]

Which leaves about 30 that presumably were guest exploitable.

Don't get me wrong -- QEMU is _useful_. As a "kitchen sink" solution that runs
anything, anywhere, with any useful combination of emulated
{devices,processors,systems}.

However, this is also its biggest weakness. Which is why Google and Amazon all
run their own custom VMMs for their IaaS services.

The microvm machine type as described here is a great step to improve this
situation. The next step in my book would be to reconfigure QEMU's build
system to allow building a binary that _only_ supports the devices provided by
microvm, and nothing else.

------
reilly3000
What kind of workloads make sense for this runtime? DIYFaaS? Or small,
isolated long-running processes?

~~~
rwmj
Function as a service is certainly one place. Others include secure container
runtimes (eg. Kata-containers), sandboxing applications in general, and
libguestfs.

