Hello,
I filed Feedback FB22859649 about nested virtualization for macOS guests and would like to confirm the supported API surface / limitation through Developer Forums as well.
We are using Virtualization.framework to run macOS guests on Apple silicon hosts. The use case is isolated macOS VM workspaces for development and AI-agent automation. In those workspaces, developers often need to run container or VM-backed tooling inside the guest, for example Apple Container workflows, Docker/Colima/Lima-style Linux VM workflows, local Kubernetes, CI sandboxes, testcontainers, or local MCP server stacks that expect hardware-assisted virtualization from inside macOS.
Environment I used for the Feedback:
Apple silicon host: MacBook Air with Apple M4
Host OS: macOS 26.5 build 25F71
Xcode: 26.5, macOS SDK 26.5
Guest type: macOS VM configured through Virtualization.framework with VZMacOSBootLoader and VZMacPlatformConfiguration
From the current SDK headers, I see nested virtualization support exposed on VZGenericPlatformConfiguration via nestedVirtualizationSupported and nestedVirtualizationEnabled. VZMacOSBootLoader says a macOS guest must use VZMacPlatformConfiguration, and VZMacPlatformConfiguration does not appear to expose an equivalent nested virtualization property.
Could Apple/DTS please confirm the intended support boundary?
Is nested virtualization currently supported for macOS guests created with Virtualization.framework on Apple silicon using VZMacPlatformConfiguration?
If not, should this be treated as an intentional current limitation of macOS guests / VZMacPlatformConfiguration rather than a missing configuration option?
Is there a supported host-side API or validation behavior to detect this limitation before creating or starting the VM?
Is there any supported workaround for container workflows inside a macOS guest that require a nested Linux VM or hypervisor, or is the recommended architecture to run those container/VM workloads on the host or in a Linux guest instead?
I am not asking for roadmap or ETA. I am trying to document the correct supported behavior and avoid misleading users of macOS VM workspace tools when container or AI-agent workflows fail because the macOS guest cannot run its own virtualization backend.
The broader impact is that disposable macOS VM workspaces are a strong isolation boundary for GUI automation, browser/app state, credentials, local files, and agent runtime state. Without a supported nested virtualization path, the GUI side of the workspace can run in a macOS guest, but common container-backed developer workflows have to move outside that workspace.
Thank you.
1
0
223