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:)
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.
+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.
I sure wish qemu were better documented. There's a lot of qemu documentation out there, but much is incomplete or out of date. A lot of Red Hat's documentation is virsh rather than qemu/kvm. It's fairly easy to get something simple up and going, but there are shortcomings when you try to do something more complicated.
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?
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.
I wonder if that's a security benefit, too... I would expect that KVM equals more attack surface, and direct to the host kernel at that. Now, weighing likelihood of exploiting KVM through qemu vs qemu through TCG (or whatever)... I'm not qualified to asses, and probably depends on your threat model. But it sure feels good if you can run qemu with no special privileges.
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.
> In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins.
Indeed. Nice to see that the cross-pollination is happening.
For folks interested in what can be accomplished with userspace VMMs, a very minimalist example is the Solo5 project (https://github.com/Solo5/solo5), specifically the 'hvt' tender.
Function as a service is certainly one place. Others include secure container runtimes (eg. Kata-containers), sandboxing applications in general, and libguestfs.
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:)
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.
+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.
3 replies →
Google does something similar: https://developers.google.com/season-of-docs/docs
I sure wish qemu were better documented. There's a lot of qemu documentation out there, but much is incomplete or out of date. A lot of Red Hat's documentation is virsh rather than qemu/kvm. It's fairly easy to get something simple up and going, but there are shortcomings when you try to do something more complicated.
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?
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
I wonder if that's a security benefit, too... I would expect that KVM equals more attack surface, and direct to the host kernel at that. Now, weighing likelihood of exploiting KVM through qemu vs qemu through TCG (or whatever)... I'm not qualified to asses, and probably depends on your threat model. But it sure feels good if you can run qemu with no special privileges.
What are the differences compare to Firecracker?
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.
> In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins.
Indeed. Nice to see that the cross-pollination is happening.
For folks interested in what can be accomplished with userspace VMMs, a very minimalist example is the Solo5 project (https://github.com/Solo5/solo5), specifically the 'hvt' tender.
> 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...
"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."
3 replies →
What kind of workloads make sense for this runtime? DIYFaaS? Or small, isolated long-running processes?
Function as a service is certainly one place. Others include secure container runtimes (eg. Kata-containers), sandboxing applications in general, and libguestfs.