
Nemu – Modern Hypervisor for the Cloud by Intel - lelf
https://github.com/intel/nemu
======
_wmd
So a fork of Qemu that makes no promises to keep AMD support, and uses words
like "leverages".

Its not clear why this needs to exist, as opposed to working with upstream to
produce a single tree that can be built with a slimline profile enabled

~~~
pm215
The NEMU folks did a talk at KVM Forum last year -- the impression I got was
that their intent was to use NEMU as a testbed and demo platform of what you
could do to produce a slimmed-down version of QEMU, and then as they
established workable approaches to then propose/submit them upstream to QEMU
piecemeal.

On the upstream end, one of the features that landed in 4.0 was a 'Kconfig'
system that hopefully will make it easier to build slimline versions of QEMU
which don't compile in the kitchen sink.

~~~
swiley
If you want slimed down qemu on x86 only we already have temu.

~~~
geofft
Can you provide a link to it? Google found
[http://bitblaze.cs.berkeley.edu/temu.html](http://bitblaze.cs.berkeley.edu/temu.html)
which seems like the wrong thing (it's stuff _added to_ qemu, and it's from
2008).

Maybe [https://bellard.org/tinyemu/](https://bellard.org/tinyemu/) ? Seems
like the right thing but it's not based on qemu I think. Anyone tried it with
production workloads? It does seem like it should work - it does KVM and has
virtio devices. Although at first glance I don't see either multiple CPU
support or live migration support - not having multiple CPU support would
basically rule it out for real workloads.

------
jitl
Tangentially related, but with even less features: AWS’s Firecracker, a
hypervisor with even less features for running containers as VMs:
[https://github.com/firecracker-
microvm/firecracker/blob/mast...](https://github.com/firecracker-
microvm/firecracker/blob/master/README.md)

~~~
fulafel
There's also Google's Gvisor, for also running containers as VMs:
[https://github.com/google/gvisor](https://github.com/google/gvisor)

(Handily it works with standard Docker, just put in an extra line in your
/etc/docker/daemon.json)

~~~
mjb
gvisor is a fundamentally different thing from Firecracker (or the role QEMU
or NEMU play when used with KVM). There's a pretty good summary here:
[https://gvisor.dev/docs/architecture_guide/](https://gvisor.dev/docs/architecture_guide/)

------
0x8BADF00D
Calling this “hypervisor for the cloud” is a bit disingenuous. There is no way
it would compete with the existing commercial solutions out there by
VMWare/Pivotal, Joyent, and Red Hat. Where is the HA capability? No way to
monitor cluster health. No k8s support either. This is just a fork of Qemu.

------
asimpletune
Can someone teach me what is needed for “cloud” based workloads?

~~~
geofft
I think the backstory for this project is that QEMU is a full-featured
virtualization project, capable of emulating many machines including
_actually_ emulating them (i.e., not using hardware virtualization features,
just interpreting machine code), doing userspace virtualization (running a
binary for a different CPU in the same kernel, instead of emulating an entire
machine), supporting all sorts of hardware, supporting features needed for
debugging OS development, etc. Most of that isn't useful in the cloud - in the
cloud you've got hardware virtualization, almost always on x86-64 but
occasionally on ARM64 and virtualizing the same platform as the host. In the
cloud you're typically running an OS that can have custom drivers for your
virtualization platform, you're not running old/historic OS images that need
to run faithfully. In the cloud you generally _want_ custom drivers for your
virtualization platform because they're higher-performance, and you wouldn't
want to emulate certain models of real-world network cards/disks/etc. in the
first place - and in QEMU, those turn out to be huge attack surfaces. In the
cloud you generally do not need a local graphical display and often do not
need a graphics driver at all, since you're logging into machines over SSH
(and if you need early boot debug output, you can do that over a virtualized
serial port). In the cloud you don't need a floppy disk or a parallel port. In
the cloud you probably don't need the standard PC bootup process where it
starts in 16-bit mode for compatibility with old bootloaders, which themselves
switch to 32-bit and then to 64-bit: you can have the hypervisor directly
start EFI in 64-bit mode.

NEMU only does hardware virtualization on x86-64 machines and only exposes an
emulated "machine" type that has the various virtualization-optimized devices
and no emulation of real-world devices.

Maybe "production workloads" would be a better descriptor here than "cloud."

~~~
asimpletune
Thanks for the thoughtful and thorough explanation!

