Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.

I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).

Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.

Containers solve a different problem than vms. The biggest issues (at least for me) are

1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.

2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.

  $ docker pull hello-world@sha256:7d91b69e04a9029b99f3585aaaccae2baa80bcf318f4a5d2165a9898cd2dc0a1

There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.

While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)