[MacOS] Start VM Headless/In Background

[heywoodlh]

Is there some way to start the VM in the background without needing to open the UTM app? I know UTM uses QEMU under the hood, is there a way to easily interface with the instance of QEMU provided by UTM?

The use case I'm trying to tackle is that it would be nice to have my UTM VM launch automatically in the background when my Mac boots up.

[conath]

I'm 99% sure this isn't currently possible, but I am also 99% sure it can be implemented. Here's how (which would work both on macOS and iOS):

• add a URL scheme (maybe utm:// or utmapp://)
• handle a "start-vm" path with query of the VM to start (e. g. utmapp://start-vm?name=windows10)
• start the vm according to the query
  Then your workflow to make it start on macOS login would be:
• create an Automator workflow that opens this URL
• add the workflow to your Login Items (System Preferences => Users => Login Items)

Would that be adequate for your use case?

[heywoodlh]

That would work perfectly for me

[osy]

I think your use case is more suitable for QEMU. UTM is nothing but a fancy UI wrapper around QEMU, but it seems like your use case would be solved by launching the QEMU command line at startup.

[heywoodlh]

@osy being able to extract the arguments that UTM is passing to QEMU and then writing a script or launchd service to run the QEMU instance bundled with UTM directly would be perfect.

It seems like 48a8fc7 would do the trick for me, correct?

[osy]

Yes

[bovi]

Is there actually a command-line frontend for qemu delivered in the software for the Mac? I was searching in the pre-compiled installation folder but only found the qemu-system-* libs. Or do I correctly assume that you need to compile qemu by yourself in parallel to use the arguments?

[mbreese]

While, I could set this up manually, having the UTM GUI is really nice.

I would personally find it helpful if you could setup UTM to start when I login, but minimized to the menu bar. Then be able to start/stop VMs from UTM as opposed to needing to (a) find/build a compiled qemu binary, and (b) share configurations b/w UTM and my qemu scripts.

I don't think the full headless option as described above is really needed here. That seems very complicated (do-able, but complicated). But a menu-bar interface to manage VMs, and allow the VMs to operate w/o having a GUI window connected would be amazing. If those two things were possible, it would be great!

[benpye]

+1 to what mbreese said. I would love to have a UTM icon in the top menu bar that would allow me to keep VMs running and start/stop them as needed. It would then be great to be able to connect to the GUI if desired as well, but that's very much secondary for me.

[ITJamie]

+1 would love this for vagrant!

[dmuth]

Also throwing in my vote for being able to use UTM as a provider for Vagrant so I can run headlessly.

I am a creature of the command line, and would love to be able to spin up/SSH into/teardown VMs with UTM on the back end. I'm still an Intel Mac, so I do it now with Vagrant and VirtualBox, but the latter won't be an option when I make the switch to M1.

[lucendio]

use UTM as a provider for Vagrant so I can run headlessly.

... and I'd be happy to chip in and write a Vagrant plugin. Some sort of CLI interface provided by UTM would certainly ease the integration.

[conath]

I recently implemented a URL scheme, maybe it can be used in your use case?

Not merged yet due to crashing with a specific feature it introduces. See #2670

[lucendio]

I just looked into:

It seems like 48a8fc7 would do the trick for me, correct?

and didnt notice #2670. Awesome work! Indeed it would. Invoking open utm://... seems to do the trick. And as far as I can see your PR already includes all essential commands.
Does a headless: BOOL flag exist (as in: start minimized - as mentioned earlier in this thread)? I'll dig a little bit deeper, but if it's really just QEMU options we should be able to get this integrated with Vagrant as soon as the PR lands.

[conath]

It's now (2.3.0 beta) possible to run VM at login. I've added a note to the Wiki on using the new URL scheme to run VMs at login. https://github.com/utmapp/UTM/wiki/URL-Scheme-–-Automation-for-UTM-app-&-VMs#auto-start-vm-on-mac This is written from a non-Terminal user's perspective, of course you don't have to invoke UTM from Automator. ;)

[ktprograms]

@osy If I understand the code correctly, we'll need to change how a VM gets started since right now QEMU is launched after the VM window opens but in headless mode there won't be any window opening.

[ITJamie]

@lucendio now that the utm urlscheme exists do you have enough for writing a vagrant plugin as you mentioned?

[lucendio]

@ITJamie as far as I can see, yes. But as always, issues are only uncovered along the way. I want to start on this next week.

[ktprograms]

@lucendio Just to let you know, opening the utm://start... URL will open both the UTM window and the VM window and as far as I can see there isn't any way to minimise it.

Also it would probably only work with a VM in Emulated VLAN mode since in the other network modes there isn't any way to find out what IP address the VM was allocated in order to SSH. (With Emulated VLAN you specify a port forwarding and ssh to localhost. For example if the port forwarding is :22 ➡️ :2222 you would ssh using ssh -p 2222 user@localhost)

[conath]

Has the SSH worked for anyone using the emulated VLAN? #3143 suggests using shared network to make it work.

[ktprograms]

@conath it works for me pretty consistently.

[johnalanwoods]

To clarify if I start a VM with UTM can I close UTM and thus the GUI and still leave the machine running in 3.0.3?

then I can just use qemu CLI for interaction?

UTM is great by the way.

[conath]

@johnalanwoods Thank you. UTM does not currently offer such a feature, and this issue is about starting a VM without a GUI. Feel free to create a new issue about your feature request and, if you do, please describe your use case in detail.

[johnalanwoods]

Thank you! @conath

[lucendio]

[...] I want to start on this next week.

Apparently, I haven't started anything yet, but, I tried to put together all my thoughts on this so far: #2496 #3618 . I'd love to hear your opinion!

[pbowyer]

@lucendio Is this the link you meant? #3618

[ideologysec]

One additional thing that would be very helpful here would be a list command, to be able to get a list of VMs that UTM knows about, for additional processing later, in case you want to dynamically start a VM whose name you don't necessarily know - useful for things like Alfred workflows, for example.

[mjgardner]

One additional thing that would be very helpful here would be a list command, to be able to get a list of VMs that UTM knows about, for additional processing later, in case you want to dynamically start a VM whose name you don't necessarily know

I've created a macOS shortcut to do this and described it in the show and tell discussion category.

[wivaku]

One additional thing that would be very helpful here would be a list command, to be able to get a list of VMs that UTM knows about, for additional processing later, in case you want to dynamically start a VM whose name you don't necessarily know - useful for things like Alfred workflows, for example.

This has now been added to 4.15:

/Applications/UTM.app/Contents/MacOS/utmctl list

(also possible to use utmctl to start a VM)

[toddlindner]

This is great, thanks! Any way to hide the actual UTM screen of the VM? I see the --hide argument to start can hide the main UTM window, but I am asking about the actual VM window.

[wivaku]

You could make the VM headless, by removing the display device in the VM config.

[bumfo]

I think your use case is more suitable for QEMU. UTM is nothing but a fancy UI wrapper around QEMU, but it seems like your use case would be solved by launching the QEMU command line at startup.

Although this use case is covered by QEMU, it is still beneficial to be able to have UTM launching at system boot, launching wanted VMs automatically in the background, and being able to manage them in the UI. By using QEMU directly, one loses all the benefits of UTM.

A problem of current headless mode is that you can't have a display without rebooting the VM. It would be much better to be able to hide the display instead, either by an option to start the VM with hidden display, or by closing the window without killing the VM.