41–50 of 76 posts
Earlier quoted context omitted.
UTM uses Rosetta via qemu. It’s the most direct way of emulating x86 on Apple Silicon, using native Apple emulation layer.
Then you're emulating everything that runs in the VM, as opposed to using an ARM vm and only emulating the x86 program you want to run. This makes things a lot slower.
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 :) 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 i…
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.
I really like UTM, I especially like UTM remote on the iPad. The issue is that of course Apple computers that are large enough to run VMs are… expensive. So I have instead found myself using proxmox on a cheaper (by comparison) threadripper machine. The added bonus is that xterm.js (the default LXC console viewer) works wonderfully on the iPad- Though of course you can use prompt3 for heavier duty stuff. The other us…
> The issue is that of course Apple computers that are large enough to run VMs are… expensive. Expensive compared to what? UTM uses Apple Virtualization Framework, which lets the guest VM only occupy as much memory as it's actually using (instead of reserving all of its available memory). This means it's viable to run a Linux VM on e.g. an 8GB RAM MacBook Air.
Maybe memory compression helps, but it doesn’t appear so to me right now.
Ever since I discovered OrbStack, my M1 has become the perfect laptop for me. OrbStack has great UX, massive FS performance, Docker & Kubernetes support, and a bunch of really clever people behind it. Everyone doing linux development on a Mac should try it
UTM is OK for light workloads, but if you can justify the cost of Parallels, you’ll be far better off using that.
I hate most things about Parallels. I spun up a Windows VM using Parallels for work purposes, and it decided to change from using native Chrome to open html files to using Edge in the Windows VM. So double-clicking a html file would first start the Windows VM, if it wasn't already started, and then open it in Edge inside the VM. WTF is wrong with you Parallels?
"Parallels doesn't change the file associations. Parallels registers Windows apps (like Edge) for macOS in case users want to open them/files using macOS interface. macOS then decides what apps to use for this or that file type or protocol. Based on our testing if there is already a file association, then a new app registered in the system doesn't change it. Tip: Parallels provides an option to disable sharing Windows apps with macOS. It is enabled by default as the vast majority of customers like it. File associations can also be changed anytime using "Get Info" in file context menu and then "Open with:" and "Change All..."."
In other words, it looks like .html files were associated to your (in-Windows) Edge, hence it booting up a VM etc. but that can easily be mitigated.
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…
During installation UTM asks if you’re willing to use Apple virtualization rather than qemu
Earlier quoted context omitted.
> 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…
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.
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 :) 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 i…