Initial socket support draft

[angerman]

This adds support for a utm.socket that can be used to list, start and stop VMs.

It allows controlling UTMData through a socket (if UTM is launched with --with-socket):

$ nc -U /Users/angerman/Library/Containers/com.utmapp.UTM/Data/utm.socket                                                  ~
UTM> list
UUID                                 Status   Name
FC379EA4-195C-499E-BDC9-066470BCA5C9 Stopped  macOS (blank backup)
UTM> start FC379EA4-195C-499E-BDC9-066470BCA5C9
FC379EA4-195C-499E-BDC9-066470BCA5C9 Stopped  macOS (blank backup)
UTM> list 
UUID                                 Status   Name
FC379EA4-195C-499E-BDC9-066470BCA5C9 Started  macOS (blank backup)
UTM> stop FC379EA4-195C-499E-BDC9-066470BCA5C9
FC379EA4-195C-499E-BDC9-066470BCA5C9 Started  macOS (blank backup)
UTM> list
UUID                                 Status   Name
FC379EA4-195C-499E-BDC9-066470BCA5C9 Stopped  macOS (blank backup)

The idea here is to launch UTM as a service, and then use the socket to communicate and control starting, stopping, ... VMs.

This is an initial draft, to start a discussion around whether or not such a feature is desirable, better approaches to it and so forth.

[osy]

FYI we had a socket command interface that was removed in favor of the scripting bridge interface https://github.com/utmapp/UTM/commit/d6fc3cdb81f68d1224cfad77f6cf9c33138ce3b8

[angerman]

FYI we had a socket command interface that was removed in favor of the scripting bridge interface https://github.com/utmapp/UTM/commit/d6fc3cdb81f68d1224cfad77f6cf9c33138ce3b8

That's interesting! Maybe I'm holding the scripting interface wrong, as I'm trying to figure out how to do this headless in an automated fashion. Utmctl doesn't like being run form within an ssh session.

[osy]

The way apple events works depends on the GUI app running under some logged in user. So no, you can’t do it from just a ssh session. However, I don’t think you’ll get it working well with sockets either because of sandboxing. You’d need to launch the GUI somehow no matter what.

[angerman]

The way apple events works depends on the GUI app running under some logged in user. So no, you can’t do it from just a ssh session. However, I don’t think you’ll get it working well with sockets either because of sandboxing. You’d need to launch the GUI somehow no matter what.

Yes, I can launch UTM as a launch item for the automatically logged in user on the host. Building a different headless executable seems much more involved.

[angerman]

In essence, what I'd like is something like tart.run, without the restriction to HVF only, if that makes sense?

[osy]

I think you may be better off using QEMU directly if you’re thinking about building a headless version.

[angerman]

osy, if it was for non-HVF applications yes. What I like a lot about UTM is

• It provides a unified interface across QEMU + HVF
• It can be used for initial bootstrap and interactive debugging of images.

I'm mostly interested in macOS on macOS. For Apple Silicon this is HVF, for Intel it's qemu. Using a common interface like utm has its appeal here. Just dealing with the graphical session is a bit annoying over high latency networks. If there is a way to run utmctl from a ssh shell that would pretty much solve all my needs right now, hence trying to sidestep the graphical login topic by using a unix socket for commandeering UTM. (To be fair though, it doesn't commandeer UTM directly right now, but just re-uses the UTMData structure and it's methods).

[ktprograms]

FYI what you're referring to is Virtualization.framework, that's the higher level framework used for macOS-on-macOS on Apple Silicon

HVF is the low level hypervisor, similar to kvm on Linux

[angerman]

After some experimentation here's what also works:

• launch UTM in the graphical session.
• launch Terminal, and tmux inside.
• send commands to the tmux session from an ssh session.

Now that feels a bit convoluted, but allows us to obtain almost the same functionality like this without modifying utm.

.------- graphical session --------.  .- ssh session -.
|               .- Terminal.app -. |  |               |
| .-----.       | .--- tmux ------------------------. |
| | UTM<+--OSA--+-+>              utmctl            | |
| '-----'       | '---------------------------------' |
|               '----------------' |  |               |
'----------------------------------'  '---------------'

I wonder if adding a socket interface to utmctl (e.g. the ability to launch utmctl --daemon would be appreciated?)

The motivation is to control UTM from the command line of a non-graphical session.