Beware of VirtualBox. While part of it is free, it's not very useful without the extension package. This package is easy to download on the same website as VirtualBox, but... it's not free.
Even better Oracle tracks the ips that download this extension and after a suitable amount of time they will come knocking on your company's door asking for an insulting amount of money (e.g. more expensive than VMware) or get sued. You need to read the fine print of the additional Eula printed in really small letters on the VirtualBox website to figure out the extension isn't free. It's almost a honeypot tactic. Scummy.
I don't know how Macs fare, but on Linux the extension package is not really a great feat, mostly adds RDP and some faster USB modes, but USB passthrough is marginal at most anyway.
That's a reductive way to phrase it, but more or less yes.
It's arguable if the container is "virtualized linux" as they all share a single linux kernel. In reality there's one virtual machine, one linux kernel, and many linux userspaces (one per container), which is kinda the whole point of containers.
Over docker+linux, the virtual machine is the only additional layer.
fwiw, I personally don't use macOS, so I've only got virtualized linux (containers) run by docker running on linux running on my hardware.
Are you trying to make a point or something here? Like, yes, we've built layers of abstraction that include different types of virtualization (VMs and containers), and they compose. Is that all you're observing?
> Are you trying to make a point or something here?
Nah, just curious/intrigued by how these stack.
OS-level virtualization is very much a thing. I'd be interesting to compare this to the approach taken by Docker Dekstop for Mac. I bet they do something quite similar (hypervisor-based virtualization like Virtualbox) - nothing fancy like WSL1 that I believe runs a sort of "tortured" Linux kernel inside the NT kernel.
WSL1 didn't run a Linux kernel at all - it was implementing the Linux user-space API over the Windows NT kernel. Well, some of it - not enough to run Docker, for example.
Docker on Windows and Mac does the same as what is described above - it runs a Linux VM and runs the docker server inside that, and then does a little magic to expose native OS paths and so on to that VM. On Windows, it uses WSL2 by default now, but WSL2 is also a Hyper-V VM in the end, with some Windows magic to blend it more nicely in Windows workflows.
That’s how it has to work when there’s a kernel mismatch from host to guest. You’re implying more layers than there actually are.
- MacOS running a hypervisor
- A Linux VM with Docker installed.
- A Linux container running on that VMs kernel.
Containers on Linux aren’t virtualized (normally, you could use runV I suppose if you wanted). The only overhead is the extra disk space to extract the root fs of the container image and the namespacing.
I’m also using Hyperkit w/ minikube, and after some heavy setup automation it works pretty great. What I worry about, though, is what I’m going to do when I switch to a Mac w/ Apple Silicon. AFAICT Hyperkit is x64-only.
Hyperkit is open source software that works on macOS.
https://minikube.sigs.k8s.io/docs/drivers/hyperkit/
Virtualbox is also a free (as in beer, and mostly libre) driver that works on all of windows/linux/macOS