They're not official but I have made Windows 95 and Windows 98 images for UTM, if anyone would find that useful:

https://archive.org/details/@davidga

I've recently tested UTM and Parallels Desktop (Intel Mac) with Linux workloads (Ubuntu and NixOS). IME, UTM seems to be considerably slower than Parallels. I haven't investigated this much, but it looked like a very slow IO (despite using a disk in raw format) + htop showed that the CPU spent a lot of time in the kernel.

Nonetheless, it is a pretty nice tool

Virtual Machine Manager takes the cake IMO

I like Virtual Machine Manager too. It's been a trusty workhorse for years. It had tried Vagrant and Docker and both didn't work out too well. With Docker being a container engine for instance, systemd doesn't work, so installing packages which start services and manage systemd units fails. There are some hacks and workaround but VMM just works as expected.

Does it work on Macs?

If this is the right "Virtual Machine Manager", it doesn't look like macOS or Windows is supported.

https://github.com/virt-manager/virt-manager/blob/main/INSTA...

not well. There are various ports in brew and macports but they are all hamstringed in various ways

Curious about all the negative experiences with UTM; for me it was a breeze to set up both an Ubuntu/aarch64 and a Windows 11 VM, though the process to get a windows installer iso was a bit silly.

Biggest problem for me is that it seems every solution for running a VM on Apple Silicon puts a big ding in the otherwise insane battery life. I'd love to have a Linux VM "at the ready" similar to WSL2 but there doesn't seem to be a great way to achieve this.

If only it were more developer-friendly (like Vagrant). Nevertheless, UTM is good.

FWIW, if you're comfortable with command-line, here's a way to use QEMU with `virt-builder`[a] and libvirt (the virtualization API):

(1) Download a Fedora image (or any one of the images that `virt-builder` supports: `virt-builder --list | less`)

    $> virt-builder fedora-36 --format qcow2 \
       -o vm1.qcow2 --root-password secret

(2) Import the image to libvirt:

    $> sudo virt-install --name vm1 --ram 4096 \
       --disk path=/var/lib/libvirt/images/vm1.qcow2,format=qcow2 \
       --nographics --os-variant fedora-36 --import

Then you can do various operations via `virsh` (the shell tool). Start a VM, and see the boot process on the serial console:

    $ sudo virsh start --console

Create a snapshot:

    $ sudo virsh snapshot-create-as vm1 snap1 "Clean Fedora 1"

With this kind of snapshot (called "internal snapshots"), the original and its delta, i.e. the snapshot, are stored in a single disk image file; this is convenient for moving it across machines. This only works with QCOW2 images. To revert to the snapshot:

    $ sudo virsh snapshot-revert vm1 snap1

And so on[b].

[a] https://libguestfs.org/virt-builder.1.html

[b] https://developer.fedoraproject.org/tools/virt-builder/about...

Does this work on Mac M1?

Last time I tried setting up libvirt/libguestfs on my work Mac M1 I ran into various problems and gave up. This was somewhere around April 2022.

So .. actually I've been porting libguestfs & guestfs-tools to Mac M1 a couple of weeks ago. I'm intending to write up docs on how to build it, and didn't get around to it, but it will eventually appear here: https://listman.redhat.com/archives/libguestfs/

I don't know. I'm a dev and just tried booting ArchLinux with UTM. All I got was a cryptic call trace on my M1. But yeah, if it had worked I would have considered it easy to use even for non devs.

Now I tried Debian as well. It boots fine, but the username & password mentioned are incorrect. There's some way to go until this thing is usable I would say.

I've found using ordinary qemu to be more convenient than those wrappers. It's faster to read man than to find what I need in those GUIs.

Be aware though, it was easy to crash M1 with default qemu settings few months ago.

Are you saying that it crashed the host OS, or just qemu?

Entire host macOS was crashed. Must be a bug with macOS. May be it is fixed by now, I don't really want to try as I don't like when my OS crashes. You can inspect qemu command line from UTM, I'm not sure if I saved my scripts, but there're some weird flags which I had no idea what they're for, but when I removed them, it was boom, reboot.

Were you trying to use more than 8GB of memory? There's an option to pass to qemu for highmem. Could be hitting this issue: https://github.com/lima-vm/lima/issues/713

I think that I hit something similar to this issue: https://github.com/utmapp/UTM/issues/3946

I didn't set too much RAM, definitely less than 8GB.

looks great on paper, managed to get the aarch64 version of Ubuntu server running on M1 but the intel version crashed somewhere in the install.