[larusso]

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 overcomplicated install setup.

[ikatson]

> 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 with than remembering tons of QEMU command line arguments.

[larusso]

Guess you misunderstood me. I know that UTM is built on top of qemu. I use it as well. I mean when already using this init image tooling etc why clicking through the UI to setup a VM. One would think to offload this also to a script. Because in the posts steps UTM is just a means to start the resulting image.

[ikatson]

Maybe I did misunderstand, I agree the post makes it overly complicated! You definitely don't need cloud-init just to run Linux on Mac OS

[jjtheblunt]

> Afaik UTM uses Qemu under the hood

During installation UTM asks if you’re willing to use Apple virtualization rather than qemu

[znpy]

> My thought was why use UTM? Most of this can be achieved with qemu alone :)

qemu needs to be studied a bit, UTM is fairly intuitive.

I recently decided to learn how to create VMs with bare qemu (using the command-line).

As I have an arm macbook for work, UTM helped me a ton with aarch64 virtual machines because I could enable debug log and see what qemu options/flags/switches would UTM use.

Unrelated: I have some ideas about writing a tool that aims at being a "spiritual successor" to vagrant (from hashicorp), but focused on targeting qemu rather than virtual box.

Anyone interested? Please let me know (upvote or comment)

[p_ing]

UTM uses a custom fork of QEMU, so not all flags will apply to the non-forked QEMU.

https://docs.getutm.app/settings-qemu/qemu/#qemu-arguments

[imtringued]

Here is some advice:

Theoretically the entire docker workflow can be translated to VMs. In practice it is a shit show.

The biggest problem by far is building a VM image, because it consists of multiple highly irritating steps.

1. Building custom packages for the target distribution.

Since we aren't using containers, we would in principle need a full VM per application. This is not a good idea in practice. We want to avoid containers, but we still want something very much like docker images on the application level. The obvious answer is building distro specific packages.

Building distro packages is annoying, because the developer machine doesn't necessarily run the same OS as the servers. This means that building the package requires you to spin up a temporary virtual machine or a docker container. Let me tell you, it is by far easier to build your packages inside a docker container and that's why I never even bothered with the VM route, even in situations where I'm deploying VM images. There needs to be a VM based alternative to "docker build" that doesn't necessarily spit out a VM image, but rather it spits out the result of your build (e.g. packages) onto a mounted directory on the host.

If you never built your own alpine packages. Try writing an APKBUILD. It is very easy.

2. Building VM images

Now let's say we are done and just want to build our VM images. There are already distro specific tools like https://github.com/alpinelinux/alpine-make-vm-image. What you want to do is install the packages created in the first step, run a simple bash script for finishing touches and setup cloud-init for the first boot. Unlike a Dockerfile, this should be kept very simple, because the packages are already doing everything the Dockerfile is expected to do. The only thing I would overcomplicate here is directly integrating a package repository into the tool to make it effortless.

3. Running the VM

At this point everything should be quite simple. The primary use case is to run the VM image locally on a developer computer before deployment. Some quality of life features like docker style port proxying and mounting directories would be nice. This is by far the easiest part because tools like virt-manager already exist.

[znpy]

Is this whole wall of text slop ai-generated content? It’s completely irrelevant wrt what i posted.

[nar001]

UTM does use QEMU, so really it's just "bare QEMU" or "QEMU with a nice UI"

[password4321]

In my dreams I make time to use qemu for entirely user mode Docker on Windows.

[imtringued]

Cloud-init isn't a replacement for ansible unless you're building your own VM images. cloud-init only runs on the first boot. You would use it to install and setup ansible.