Docker Desktop 4.11 supports development inside enterprise virtual desktops
Business support for VMware ESXi and Azure VMs depends on nested virtualization. The important boundary is between running Desktop inside a configured guest and supporting the hypervisor configuration beneath it.
A virtual desktop can provide a developer's Windows environment while leaving another virtualization requirement unresolved. Docker Desktop uses a Linux VM for Linux containers, so installing it inside that Windows desktop requires the outer virtual machine to support another guest. Docker Desktop 4.11 makes this arrangement a supported option for Business customers on VMware ESXi and Azure VMs, according to its July 28 release notes.
The mechanism is nested virtualization. The outer hypervisor must expose the capabilities needed by the virtualization layer inside its guest. A Windows desktop that boots successfully does not by itself establish that those capabilities are available. That distinction is central to understanding the new support commitment.
I value being able to move a Docker image between machines without reconstructing its application environment. A virtual desktop adds another environment around the tools that build that image. The portable artifact remains useful, but the development machine still needs a supported execution arrangement beneath it.
Desktop remains responsible for an inner environment
Docker's contemporary VM and VDI guide explains that Desktop for Windows can run inside a properly configured virtual desktop. It identifies the Linux VM containing Docker Engine and the containers as the reason nested virtualization is essential. The added support does not replace that VM with direct execution inside the outer host.
The resulting arrangement has distinct administrative responsibilities. An infrastructure administrator supplies and configures the outer machine. Desktop installs and runs within that machine after the required capabilities are available. An application container then runs inside Desktop's environment. A failure at one level may prevent the next level from starting before the application itself does any work.
This gives a more precise interpretation of a report that Docker does not start in VDI. The first question concerns whether the guest can use nested virtualization at all. If it cannot, changing an application's Dockerfile does not address the missing prerequisite. The build description operates above the layer that is failing.
The support boundary is explicit
The guide says Docker's support extends to installing and running Desktop inside the VM once nested virtualization is configured correctly. It directs problems outside Docker's control to the hypervisor vendor. This qualification matters because the release notes' concise support statement covers a combination of products maintained by different companies.
Docker's document is particularly careful about VMware. It says nesting another hypervisor such as Hyper-V inside vSphere is not a supported VMware scenario, although running it can be technically possible. Exposing hardware-assisted virtualization and receiving support for every nested configuration are different things. Docker's willingness to support its application cannot independently change the hypervisor vendor's policy.
For an organization choosing a virtual desktop platform, that distinction affects ownership of failures. A supported Desktop subscription gives a defined route for problems in Desktop. It does not establish that every infrastructure configuration underneath it has equivalent vendor coverage. The relevant agreement is the one associated with the failing component. A provisioning record should therefore identify the outer platform and its configuration separately from the installed Desktop package, so a support report can describe both environments without conflating their responsibilities.
My preference is to document that boundary alongside the developer setup procedure. An installation instruction that ends with downloading Desktop leaves out the prerequisite that determines whether the product can run. Naming the owner of the outer VM makes that dependency actionable without turning an application developer into the hypervisor administrator.
Azure requires a suitable machine size
Docker's guide says Azure users must select a VM size that supports nested virtualization. Its internal testing used D4s_v5 machines, which it recommends as a starting specification for Desktop performance. This is a documented test configuration, not a claim that every Azure machine exposes the same virtualization capabilities.
The distinction between compatibility and capacity is useful here. A machine can need the required virtualization support before its CPU and memory allocation become relevant. Increasing resources on a VM whose selected type does not support the required nesting does not establish that Desktop will work. Conversely, having nested virtualization available says little about the capacity needed for a particular development workload.
The VMware section records an internal test VM with one CPU, four cores and 12 GB of memory. That detail describes what Docker used in its testing. It should not be generalized into a performance promise or a complete sizing rule for applications with different resource requirements.
The release also addresses managed installation
Desktop 4.11 adds a Windows installer flag, --no-windows-containers, to disable Windows container integration. It also adds --backend=windows to select Windows containers as the default backend. Those options concern different installation intentions. An automated deployment should express which integration and default it actually requires.
On Mac, the installation command gains --user to prepare Desktop for a specific user without an administrator password on first run. That is a separate host capability, but it fits the release's broader attention to supplying development environments through managed installation. The documented value is the ability to state that user selection during setup.
These installer changes do not remove the nested virtualization prerequisite for a Windows virtual desktop. They operate after the organization has selected the host arrangement. Keeping the steps distinct makes a deployment procedure easier to interpret when a workstation image contains Desktop but its virtual hardware does not meet the requirement.
A supported environment still has a concrete identity
The release also advances Compose to 2.7.0 and Kubernetes to 1.24.2. Those versions identify part of the development package that now runs in the supported virtual desktop arrangement. They remain separate from the version and settings of the outer hypervisor.
For engineers who prefer explicit build definitions, the practical gain is access to the integrated Desktop environment within an approved enterprise desktop. Its successful operation depends on the configured virtualization below it. The guide's division of responsibilities gives a concrete way to describe that dependency when provisioning the environment or reporting a failure.