Replies: 3 comments 2 replies
-
|
UTM uses QEMU as a backend. If you’re a developer what’s wrong with using QEMU directly? |
Beta Was this translation helpful? Give feedback.
-
You are absolutely right @osy, it's a valid question. I should have addressed QEMU already in the original post explicitly, my mistake. Anyway, here it comes. TL;DR: UX Unlike QEMU, in my understanding, UTM already takes the role of a hypervisor, in a sense that it manages - as a parent process - all the QEMU processes maintaining and representing machines. From what I can see, if one uses QEMU directly, this aspect would still need to be taken care of. Maybe this is a bit oversimplified, but I think it's one - or probably even the most important - part architectural-wise that UTM already brings to the table. Although, to be fair one can simply run I don't know how the rest of the world feels about QEMU's user experience, but IMHO it's kinda ... sub-optimal. Naturally, it's very complex, because it emulates a whole computer and many of its periphery. And, it seems to evolves rather rapidly while trying to consolidate, but all those different ways of configure the same thing ... Of course, UX is usually somewhat subjective. But at the same time standards & conventions emerged around UX, like Web A11y, as did a common sense for how CLIs should look like. How else can the amount of frameworks be explained to write a CLI. I don't have any numbers. Hell, the only evidence I have to show for is based on a single person, But I can't shake the feeling, that there are maybe a few others out there who share a similar struggle. On the other hand, maybe I'm just holding it wrong, didn't try hard enough to RTFM and thus don't have sufficient level of QEMU XP. Then again, it directly plays into the aspect of UX. It's software. It should make my life less painfull, not cause more. The proposal that I made, or rather the picture that I tried to paint, was meant to show a tool, similar to what Vagrant provides, but without the whole custom box format part and with a declarative and easy way to write & share machine configure. I guess it all boils down to having a nice user experience for a more tech-savvy audience. @osy as the creator of UTM, can you imagine this (headless UTM) as part of the UTM code base or would you rather see this as something separate though still part of the UTM ecosystem? I'm sorry, this comment escalated a bit. Though I hope, you can find some valid argument in here. |
Beta Was this translation helpful? Give feedback.
-
|
It's unfortunate that something like this does not currently seem to exist for the M1 ecosystem. The argument of "just use QEMU" completely dismisses the design philosophy of UTM - it's a user-friendly wrapper around an otherwise obtuse interface. The closest tool I can find that matches this same philosophy but applies it to the CLI instead of a GUI, is Multipass. However, it's incredibly biased (for obvious reasons) towards Ubuntu and is not ideal for running customized workloads. UTM seems to be in a good spot for integrating this functionality. |
Beta Was this translation helpful? Give feedback.
-
|
There are plans for this in #3718 but that’s still a long way off. |
Beta Was this translation helpful? Give feedback.
-
|
When I'm copying qemu launch command from UTM and try to execute it in terminal, I get an error:
Also,
Edit: Ok, as I found @ https://github.com/utmapp/UTM/blob/8b489b715605619e8f755d1cb4b0adf43f2fb1b5/Documentation/Architecture.md
Makes sense now. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
Ever since the M1 is out, I'm desperate to get rid of my Intel Macbook. Unfortunately, I'm a heavy user of Vagrant and VirtualBox. At first, I didn't have much hope until UTM came along. Over the last couple of months I pondered how to best adapt and integrate it into my declarative and automated workflows. In this post I want to lay out my train of thought, get feedback from the community and discuss the pros & cons of possible solutions.
TL;DR: my train of thought started with UTM as a Vagrant provider, but I shortly dismissed this idea due to the tight provider-box-coupling. Then, I went on to Terraform, but this approach would lack of a natural workflow for starting and stopping machines. So, I slowly started to realize that building something new might be the only option, or not?
Existing technologies
Vagrant
To spin up a machine with Vagrant - regardless which hypervisor is underneath - a box is required. This box, amongst other things, includes the disk image of the machine. The box and its content is described by a custom format. Each provider (means hypervisor) requires its own box, even if the filesystem of the disk image inside is identical. Vagrant has certain requirements for the operating system configuration (e.g. existing
Vagrantuser) to provide features like SSH connection, port forwarding or folders shared with the host system.As a result, a UTM provider plugin would make it necessary to also build, publish and most importantly maintain images - at least for common operating systems.
In mid 2021 Vagrant v3 was announced. Even though Vagrant is going to be rewritten in Go, the architecture for v3.x could suggest that Vagrant will require a continuously running process in the background. I'm still a bit puzzled about this part, but if that's the case, it doesn't sound like something you want.
Terraform, Pulumi etc.
While these technologies would provide certain functionality, like configuring machines declaratively, their interfaces lack of some essential use cases: explicitly start or stop machines - without creating or destroying them. All thought, such scenarios can be accomplished, it's only possible implicitly by changing input parameters of some sort (e.g. edit a configuration file).
On the other hand, their interface to add new providers is more generic and slim compared to Vagrant. Which means, UTM integration would be easier compared to Vagrant (e.g. inspired by the Docker provider for Terraform).
Proprietary Hypervisors (Parallels, VMware)
Both seem to do a decent job on Apple Silicon nowadays. And they work with Vagrant, but who wouldn't prefer an open source solution and its community (looking at you, UTM) over putting faith into a vendor hiding behind closed source.
I'm surprised, though. There isn't a machines-as-code alternative to Vagrant for either one of them. At least, I wasn't able to find any.
Are there other competitors than the ones mention above?
The proposal
So, none of these existing technologies seem fitting to integrate UTM with them. I mean, I'm not a big fan of the not invented here syndrome, but I don't see much of an alternative here. That said, I welcome any other lead to something we can build upon. In the meantime, the following is what I have in mind.
Intention
With UTM effectively functioning as a hypervisor - a control/management process to facilitate machine state and interaction - all that it's missing is a way to do interact with it via command-line and configure machines in files that can be versioned and shared.
The essential bits are already there:
I think, we can agree that the URL scheme is a great interface for automation but also not very handy for humans. And, the share feature make a great foundation for machines-as-code, but
.plistXML is not the most readable format let alone fun to write. Please, don't get me wrong, I'm not criticizing UTM and the way how it solves things. The mere purpose of this post is to find out whether the missing scenario brought up above isa) found useful by the community to begin with
b) something that is in or out of scope for UTM
Target audience
This is probably a bis biased, but my own motivation is to have a proper replacement for Vagrant+Virtualbox on M1. So, naturally I'd think of the kind of users whose primary focus are local software or infrastructure development. People who work on different stacks with a target environment other than macos arm64.
Wish list
THis is what a suitable set of requirements of an initial version would look like for me:
Fedora)
To conclude
Before I would go ahead and just write this thing, I first wanted to get some feedback and see if what I have in mind even makes sense. So, don't hesitate and rip it to shreds ;)
Aside form implementation details, I believe, the most important question that we have to answer, is whether this is going to be a separate project or part of the UTM code base.
Open questions:
Additional, optional requirements to UTM:
References
Beta Was this translation helpful? Give feedback.
All reactions