Running a nested Proxmox homelab and Docker development on the same Windows machine

Tags: docker, proxmox, homelab, windows I sat down to start a new project and Docker Desktop wouldn't run. I knew why immediately, because I'd already paid this bill once — in the opposite direction. When I first set up Proxmox nested in VMware, VMware wouldn't run either. I fixed it by turning the Windows hypervisor off so the nested VM could reach VT-x/EPT directly. It worked. What I didn't think about at the time was the other half: Docker Desktop needs that same hypervisor. So I had a working homelab and no development environment, and I'd done it to myself months earlier without noticing. The two are mutually exclusive on one machine: Hypervisor on: Docker Desktop works, nested Proxmox fails. Hypervisor off: Proxmox works, Docker Desktop has no engine. The switch itself is one line in an elevated prompt, and it needs a reboot either way: # nested Proxmox works, Docker Desktop and WSL2 do not bcdedit /set hypervisorlaunchtype off # back to the other side bcdedit /set hypervisorlaunchtype auto I didn't just want them to stop fighting, either. I wanted the new development setup to be able to reach PVE, not merely coexist with it. What didn't work I went to ChatGPT first. The answers weren't good enough — they were variations on "pick one", and I wanted both. The idea that actually solved it was mine: build a separate VM whose only job is to be the Docker engine for development. Then PVE keeps direct hardware access, development gets a real Docker daemon, and neither one is Windows' problem any more. The setup DEV01 — Ubuntu 24.04.5 in VMware, 4 vCPU, ~8 GB RAM, 100 GB disk. Docker Engine 29.8.0, Compose v5.5.1, containerd 2.3.5. The Windows Docker CLI talks to it through a context pointing at ssh://dev . Docker Desktop stays installed for the CLI only, and never runs. That's the whole trick. The daemon isn't on Windows, so it doesn't care what Windows did to its hypervisor. Passwordless SSH first The Docker context runs every command over SSH, so key auth has to w