31–40 of 76 posts
UTM is OK for light workloads, but if you can justify the cost of Parallels, you’ll be far better off using that.
Hmm I haven't tried x86 linux on utm on an arm mac (i have an x86 linux box i can ssh in), but i tried x86 windows. It was so slow as to be unusable. Edit: would command line linux be usable, considering it doesn't have to emulate all those pixels?
An x86 Linux VM on an ARM Mac is roughly native speed because it can utilize Rosetta 2: https://docs.getutm.app/advanced/rosetta/
Looks like you need to install an arm distro and x86_64 binaries on top of it though. May be a lot of trouble in some cases.
Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" show…
My thought was why use UTM? Most of this can be achieved with qemu alone :). But it showed me something new. The cloud init tool was new to me. From my toolbox I would have used ansible or something. But I think it very interesting that this runs all automatically during first boot. But I agree one needs to read between the lines to understand what the purpose of this post is. As you said it reads like a overcomplica…
For example, try installing a Windows 2000 vm. It won’t even get past the initial setup screen because it runs so slowly.
My saving grace has been that Windows 11 ARM also has its own x86 translation layer, so I can still run many (but not all) 32bit windows apps. But it’s been frustrating having such a powerful machine that can’t run an x86 vm.
Earlier quoted context omitted.
With virtualisation you can use Rosetta 2 for Linux to run x86_64 binaries. That's what I do and it's more efficient.
UTM uses Rosetta via qemu. It’s the most direct way of emulating x86 on Apple Silicon, using native Apple emulation layer.
Earlier quoted context omitted.
A lot of dev tooling still expects x86_64. Example off the top of my head, Cosmopolitan will not build ARM binaries and will not compile on ARM. (But it WILL build x86_64 universal binaries that will run on Apple Silicon and macOS via Rosetta.) There is also the issue of wanting to have your dev environment be as close to your prod environment as possible, and the vast majority of cloud-based hosting is still x86_64.
Building on a virtual x86_64 barely achieves the performance when building on host, if there was an applicable way.
At the very least, I could test mock deploys from the Apple Silicon side to the x64 VM running locally (over loopback) as an extra data point
I don't actually use it for this use-case but now that I'm thinking about it, I might try, because this seems useful
I've had a really good time using https://github.com/lima-vm/lima
Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" show…
If you just need a single Linux VM, you don't need to fiddle with cloud-init. If you want repeatability or automation, that's when you'd reach for it, whether for setting up per-project VMs, shareable VM configs between developers etc. Also, you don't need all 4 Linux images, just the one you want to run as your guest OS. Emulation / virtualization depends on the guest OS CPU architecture.
The easiest way is to just choose from the UTM gallery. But I wanted Fedora 41, not 38 which is the latest in the gallery.
Earlier quoted context omitted.
My thought was why use UTM? Most of this can be achieved with qemu alone :). But it showed me something new. The cloud init tool was new to me. From my toolbox I would have used ansible or something. But I think it very interesting that this runs all automatically during first boot. But I agree one needs to read between the lines to understand what the purpose of this post is. As you said it reads like a overcomplica…
> My thought was why use UTM? Most of this can be achieved with qemu alone Afaik UTM uses Qemu under the hood, but provides a nice UI on top for the basic use cases. It also has a library of prepared images, so that your VM is a few clicks away from intention to have one. It can also modify the VM, resize storage after creation etc. Of course all of it can be done with QEMU alone, but this makes it easier to deal wit…