> You can also just run the VM's using Apple's own API's.

"just".

Where "just" is:

- download and install XCode

- download sample project

- download a sample project

- download a Linux Kernel image

- load a RAM disk into memory

- write some Swift code to configure run parameters. Swift code is different if you want to run non-UI and UI versions

- you can only run one VM at a time or write your own code to manage that

- ....

Or, you know, use Docker Desktop, or lima, or...

This one is absolutely brilliant.

I used it to run Ubuntu on an x86 on an M1 Mac because a vendor's alpha SDK could only run on x86 Ubuntu.

Yes, UTM is very easy to use and would recommend to anyone.

I keep debating over spending the time to implement an Apple Virtualization Framework vagrant provider. Maybe I'll get around to it after I unbury myself from the rest of my self imposed side projects.

This would be very welcome. I had hopes that Veertu would provide this (they used Hypervisor.framework at the time) but they pivoted away from regular VM usage before it ever eventuated.

With the current state of Vbox on Arm it would be good to have a reliable free/cheap alternative to Parallels or VMWare for vagrant use.

cloud-init and multipass made me forget all about vagrant

I second multipass, it is pretty cool if your target is Ubuntu. I think it is closer to "Docker for Ubuntu VMs" than Vagrant though.

In the latest releases hey are dropping support for native virtualization on mac and moving to QEMU only. I my experience the QEMU backend has not been as stable as the hyperkit one, but YMMV as usual.

you know what i need this very minute? to run a m1 vm on an x86 mac. why? because there seems to be no god damn way to faithfully build m1 wheels on github's mac runners without such a contrivance. note, cibuildwheel claims it can pull off this trick but in fact it screws something up and pip install x86 dependency wheels.

The problem is probably not cibuildwheel. That having been said, the maintainers are knowledgeable and responsive, so I would try to open an issue first. Speaking from personal experience, they were able to help me to solve my problem in a couple of hours.

I opened an issue but then also plowed through the source. I'm pretty sure the issue is pip is basically intransigent and will not let you easily install packages for whatever arch it insists you have (which most certainly close to the canonical platform.machine). You end up having to chain --platform --only-binary=:all:. Okay great but I'm cross-compiling - this is exactly the time I do want source distributions.

People say it a lot but I never really felt it until I tried it - python packaging is infuriating and is beyond a shadow of a doubt proof that python is a shit professional language. Not because professional languages need to have bulletproof packaging systems (see C/C++) but because the fact that python can't make it work after so long means python is fundamentally flawed. And don't tell me "well you're implicitly talking about C extensions". Yes I am but that's a language feature and if you design a language feature that your language fundamentally precludes you from being able to support, then again that's on you.

m1 Mac:mini is about $400 used (sold by vain people). If you are worried it will come with pet hair stuck in the fan blades, pay an extra $100 to buy from a reputable reseller. If you are constrained to software or work in a chair meant for eating or sun bathing, another option is Mac Orka/Anka.

yes this is basically the decision i've arrived at after pulling my hair out today.

You can also use AWS M1 instances, with the huge disadvantage that they must be run a minimum of 24 hours at a time.

https://aws.amazon.com/ec2/instance-types/mac/

Does this offer any performance benefit over using Lima, particularly when running x86 VMs on Apple Silicon? Or is Lima already using the same APIs?

To be clear, you can't run an x86 Linux VM on Apple Silicon using Apple's virtualization framework. It says right in the docs,

>The kernel and RAM disk image must support the CPU architecture of your Mac.

You _can_ run x86 via Rosetta inside the VM. But that's not the same thing as running an x86 VM.

To answer your question, Lima supports two VM types - QEMU and vz. QEMU is the default and is what's used by other projects to run x86. If you select a vz VM type then it uses MacOS' native APIs. I wouldn't expect a performance improvement in using a vz-typed VM with Lima and Apple's own instructions.

Thank you for clarifying!

Lima has experimental supports for Apple's native virtualization framework, but the default is still QEMU.

It should have a performance benefit when running Arm64 Linux, I suppose.