slpnix
Joined 7 years ago
Karma
180
Submissions
15
Member since
Jan 31
https://sinrega.org
https://github.com/slp
https://twitter.com/slpnix
https://mstdn.io/@slp
View on Hacker NewsRecent submissions
Comment · 2 years ago
Podman supports this since quite a while with the krun variant of the crun runtime (https://github.com/containers/crun/blob/main/krun.1), provided in Fedora by the "crun-krun" package.
Just add "--runtime=krun" to your podman command line along the other arguments and you'll get the container running inside a VM powered by libkrun.
Comment · 5 years ago
Behind the scenes, it's using QEMU with Alex Graf's patches for hvf (Hypervisor.framework) support, so it's Virtualization, not emulation. In other words, the performance is really good ;-)
BTW, in case you don't want to depend on a fork, upstream podman is going to gain M1 support (in the sense of 'podman-machine' knowing how to start aarch64 VMs with hvf) very soon.
Comment · 5 years ago
I can't comment on the comparison with Docker for Mac bacause, honestly, I have never used it.
With krunvm, each session initiated with "krunvm start" is an independent lightweight VM. The maximum amount of RAM the VM can use is configured with the "mem" flag (or it uses what's configured by default), but the VMM will always try to use the minimum possible amount of RAM by returning the pages the guest is no longer using to the host (virtio-balloon's free page reporting feature).
That said, you can also start a single VM (using "krunvm start"), run podman's service ("podman system service...") inside it, switch to another terminal in macOS and execute multiple containers inside the VM using "podman remote" [1]. Now I'm thinking I should probably write a tutorial about this option ;-)
[1] https://www.redhat.com/sysadmin/podman-clients-macos-windows
Comment · 5 years ago
The key is that libkrun (https://github.com/containers/libkrun), the library that krunvm uses for running the VMs, as recently integrated support for Hypervisor.framework on ARM64, in addition to KVM.
As for buildah, the Homebrew repo contains a build that includes this PR (https://github.com/containers/storage/pull/811).
Comment · 5 years ago
krunvm uses libkrun (https://github.com/containers/libkrun) for executing the VM, and while the later is also based in rust-vmm and shares some code with Firecracker and Cloud-Hypervisor, it's specialized in the process isolation use case. This means it implements a different set of devices (most notably, virtio-fs instead of virtio-blk, and virtio-vsock+TSI (Transparent Socket Impersonation) instead of virtio-net), and it takes the form of a dynamic library instead of a final binary.
In fact, the networking limitations are caused by this use of virtio-vsock+TSI. TSI (WIP implementation here: https://github.com/containers/libkrunfw/blob/main/patches/00...) is an experimental mechanism that provides inbound and outbound networking capabilities to the guest, with zero-configuration and minimal footprint, by transparently replacing user-space AF_INET sockets with AF_TSI, that have both an AF_INET and AF_VSOCK personality.
TSI has the additional advantage that, for the host side, all connections appear to come and go to the process acting as a VMM (in this case, krunvm, as it links directly with libkrun), which makes it very container-friendly in a way that even side-cars (such as Istio) work out-of-the-box.
Comment · 7 years ago
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...
Comment · 7 years ago
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.
Comment · 7 years ago
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.