Virtualbox in UTM on Mac M1 machine possible?

[igel1]

Dear experts,

is it possible to run debian inside Virtualbox which itself is running in Windows 10 X86_64 installed inside UTM on a Mac M1 machine? (might be a trivial question, but I am no virtualization expert at all)

I get this error message:

Cannot enable nested VT-x/AMD-V without nested-paging and unrestricted guest execution!
(VERR_CPUM_INVALID_HWVIRT_CONFIG).
Result Code:
E_FAIL (0x80004005)
Component:
ConsoleWrap
Interface:
IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8}

---

What do I have to do / to configure if it is possible?

Kind regards

A.

[Br0des]

why would you do this even

[igel1]

Because I have to test a vagrant-deployment which provisions into a VirtualBox starting ansible within that box and deploying the box. This setup / the whole mechanism has to work on Windows x86_64/VirtualBox and on Mac M1/Parallels.

And since I have only the Mac M1, I need to emulate an x86_64 machine ...

[Stromweld]

Using co-pilot I found this is not possible on M1 macs. Apple virtualization framework doesn't support it for any mac version at the moment but M2 and above does support nested virtualization. You'd have to add a qemu argument to the box config in UTM to enable that.

Here's the output about M1 from co-pilot:

Nested virtualization is not possible on an M1 Mac running a Windows guest in UTM. The limitation is due to the Apple M1 processor hardware, which does not support the necessary virtualization features.
Here is a breakdown of why this configuration does not work:
M1 hardware limitation: The Apple M1 chip was designed with an ARM architecture and does not have the hardware capabilities to support nested virtualization. Newer M2 and M3 chips support the necessary Armv8.4-A specification, but Apple's macOS virtualization frameworks do not expose this feature to users for virtual machines.
Platform mismatch: The process of running Windows on an M1 Mac with UTM is already a complex process involving multiple layers of emulation and virtualization.
Level 1: macOS uses the Hypervisor framework (hvf) to virtualize the ARM architecture.
Level 2: UTM/QEMU runs a Windows-on-ARM guest, which is a virtual machine using the ARM architecture.
Level 3: Windows-on-ARM includes a built-in emulator for x86/x64 applications. This is not nested virtualization, but a software-based emulator.
Level 4 (unsupported): Trying to run a hypervisor inside the Windows guest (like Hyper-V or another emulator) would require nested virtualization, which the M1 hardware cannot perform.
What are your options?
Since nested virtualization is not possible on an M1 Mac, consider these alternatives depending on your needs:
Use an Intel Mac: If you have access to an Intel-based Mac, you can follow the instructions for Intel Macs to enable nested virtualization, as the hardware supports it.
Upgrade to an M3 or newer Mac: The Apple M3 chip supports the hardware-level features for nested virtualization. However, the software support is currently limited. The macOS 15 release notes mention support for Linux guests with the Apple Virtualization backend, but support for Windows guests is not yet available.
Use a cloud-based solution: If you need to run nested VMs for testing or development, use a cloud service that offers ARM-based VMs with nested virtualization support.
Test on a dedicated PC: For workloads that require nested virtualization, a dedicated PC with an Intel or AMD processor running Linux is the most reliable option.

[igel1]

Thank you for your effort - doesn't sound very promissing for my approach.
I think I will stop investing more time in this subject.

[JuiceB0xC0de]

I think that the emulation debate for this issue still has strong grounds even on an M1 chip. If this is something you’re still willing to work on I’d be happy to break that down and find a solution. I’m not certain this is something you will encounter often or not. Copilot isn’t trying to find solutions to a problem that may not have been explored thoroughly. It’s giving a historical analysis of previous attempts. There’s nothing I love more than proving AI assistants wrong. I do it regularly. They save us time they don’t replace the Dev mindset.