Right, and and xhyve, Hypervisor.framework, and kvm are all frameworks for creating and running virtual machines. In contrast, Docker for linux runs using a native container mechanism without using a VM at all. macOS doesn't support containers, but it could.
The general case is developing software on a desktop OS in containers that are intended to be deployed on Linux boxes. Since the whole point of containers is that the container runs against the host OS kernel directly, clearly that is not really possible on a desktop that isn't running Linux as there isn't a Linux kernel there to run against. there are two ways past this. Emulate a Linux kernel, or run a real linux kernel in virtualisation for the container to run against
WSL 1 chose the first approach so the container thought it was running against a Linux kernel but it was actually a windows kernel plus a syscall shim. That's all fine and dandy in theory, but not running against real Linux means there was always the risk of different behaviour on Windows versus on the Linux deployment host. In WSL 2 Microsoft switched to running a real linux kernel in a hypervisor, which is basically the same approach as on the Mac.
> xhyve, Hypervisor.framework, and kvm are all frameworks for creating and running virtual machines
> In contrast, Docker for linux runs using a native container mechanism without using a VM at all
Thanks for pointing this out. As I'm slowly getting familiar with container-based workflows and underlying technology, your statement helped clear up my confusion about the essential differences between containers and VMs.
I found an informative table in Microsoft's documentation for "Containers on Windows", that compares and contrasts the two approaches:
This helped me understand how Docker for Mac using xHyve is different from Docker on Linux with native containers as a much thinner layer with a shared kernel.
Aside from the container/VM architecture, a performance bottleneck of Docker for Mac is (apparently) how mounted volumes work, on the file system level.
---
> macOS doesn't support containers, but it could
According to a random Reddit thread (so, with a grain of salt) I found on this topic:
> Using a shared kernel container (via cgroups, for example) isn't feasible with macOS because of licensing restrictions and because the Linux syscall interface isn't compatible with macOS.
Which seems to imply that there's some fundamental reason why Docker for Mac must rely on VMs, that macOS is not (yet?) capable of providing containers that are as native as on Linux.
They also mention how the file system on macOS has design limitations that make containers more difficult.
> The net result is that performance is probably going to be near-native for light workloads, but macOS depends on other fundamental technologies like APFS which aren't designed for datacenter type workloads.
---
EDIT: Aah, right, this is why a comment higher up mentioned:
> Apple said they were working with Docker to make sure MacOS on ARM is a first class host for Linux Docker containers.
