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.
You are correct that nested virtualisation is not supported with macOS guests. Beyond that, I’m not sure if there’s much useful info I can give you. Let’s look at your remaining questions:
2- If not, should this be treated as an intentional current limitation … ?
Yes.
3- Is there a supported host-side API or validation behavior to detect this limitation before creating or starting the VM?
I don’t understand this question. As you’ve pointed at, the nested virtualisation properties are on VZGenericPlatformConfiguration rather than VZMacPlatformConfiguration, and creating a macOS guest requires the latter. Thus this lack of support is visible to you at compile time. There’s no need for dynamic validation.
One consequence of this is that, if support for this were added in the future, it would require new API. If and when that happens, you’ll be able to meaningful ask this question.
4- Is there any supported workaround … ?
Not really. The options you suggested will likely work, but they will result in a very roundabout solution. I can’t see any workaround that result in a direct solution.
I filed Feedback FB22859649 about nested virtualization for macOS guests
Thanks for that.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"