5 ms·
Nemu – Modern Hypervisor for the Cloud by Intel
- jitl 8y agoTangentially 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/master/README.md https://github.com/firecracker-microvm/firecracker/blob/mast...
- lima 8y agoAnd it's written in Rust! Fun fact: Firecracker originated in the Google ChromeOS project as "crosvm" and is now powering AWS.
- transpute 8y agoSeveral of those groups are now converging on a common base, rust-vmm, https://opensource.com/article/19/3/rust-virtual-machine https://opensource.com/article/19/3/rust-virtual-machine > The rust-vmm project came to life in December 2018 when Amazon, Google, Intel, and Red Hat employees started talking about the best way of sharing virtualization packages. More contributors have joined this initiative along the way... The goal of rust-vmm is to enable the community to create custom VMMs that import just the required building blocks for their use case.
- whalesalad 8y agoGlad you mentioned this, I came here to say something similar. The readme on the NEMU project definitely echoes a lot of the Firecracker project. Hopefully they both continue to push the boundaries of lightweight virtualization.
- fulafel 8y agoThere'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 8y agogvisor 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/
- ris 8y agoThere's also Kata containers, also originally an Intel project https://katacontainers.io/ https://katacontainers.io/
- _wmd 8y agoSo 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
- jarym 8y agoMaybe they want to add experimental ideas as a testing ground? I'm sure anything worthwhile could later be upstreamed if necessary?
- eatonphil 8y agoSounds like what OpenBSD has done with LibreSSL as a slimmed down fork of OpenSSL. Or even OpenBSD itself as a slimmed down fork of NetBSD. Makes sense to me.
- MuffinFlavored 8y agoBut now you have a more fragmented BSD market.
- eatonphil 8y agoKinda. Work is frequently shared between the big ones (video and network drivers for instance).
- MuffinFlavored 8y agobut like, how much further along would hard things like video/network drivers be if instead of managing 3 separate "everything else", it was just 1? think of the time and effort in documenting all of their code, compiling, getting hosting set up. bootloaders, different filesystems, different libc implementations, different command line tool implementations. all to have an opinion?
- ansible 8y ago
- asimpletune 8y agoCan someone teach me what is needed for “cloud” based workloads?
- geofft 8y agoI 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 8y agoThanks for the thoughtful and thorough explanation!
- deleted 8y ago[deleted]
- 0x8BADF00D 8y agoCalling 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.