Fun with QEMU monitor

[sentient06]

So I've been reading about how to automate certain stuff on QEMU, and I stumbled across the monitor option. I thought I might share it here for anyone interested, as I didn't find any topics about his in the forum yet.

I'm on Mac, but this should be pretty similar on Linux. I'm not really sure how this behaves on Windows, I'll let someone else poke around on that point.

One can enable monitor by creating a socks file by adding the monitor parameter to the QEMU command:

Code: Select all

-monitor unix:/tmp/qemu-monitor.sock,server,nowait

In the example above I put my socks file in the tmp directory as a result of my QEMU running with sudo, but I reckon it can live anywhere. It's convenient as it's tucked away anyway.
QEMU will create that file when it starts up.

So, the first thing I thought is useful is to send a cmd+opt+esc combo to QEMU. If I try that combination I get macOS 15's "force quit" window.
To access the monitor directly, one can hold ctrl+opt+2. To return to the emulator's interface, ctrl+opt+1.
To access the monitor from the command line, do this:

Code: Select all

nc -U /tmp/qemu-monitor.sock

(nc stands for netcat)

That should show a prompt "(qemu)".
If that doesn't work, perhaps you are running QEMU as root, like me, then just sudo it. Ctrl+C should close the monitor.

To send keys, use the command "sendkey" to the monitor. Most keys are just their names, e.g. 'esc', 'tab', 'f1', etc. The option key is 'alt' and the command key is 'meta_l' or 'meta_r'.
Letters and numbers are their own values. (Yes, we can type texts like this.)
You can send a "close window" command like so:

Code: Select all

sendkey meta_l-w

And cmd+opt+esc like so:

Code: Select all

sendkey meta_l-alt-esc 100

The 100 represents an amount of time the keys should be held.
You can send the command to the monitor without opening the monitor like so:

Code: Select all

echo "sendkey meta_l-alt-esc 100" | nc -U /tmp/qemu-monitor.sock

If you need root, the sudo would have to come after the pipe.

If you want to automate this as an environment function, and not enter the password every time, this is where things get complicated. But it's doable.
I put my password into a text file on my mac. It's not really safe if people can access it, so be careful when doing this. I get the value from the file and issue commands as sudo. I wrapped the monitor code in separate functions and I added root versions. Like so:

Code: Select all

qemu::send:cmd:opt:esc() {
    echo "sendkey meta_l-alt-esc 100" | nc -U /tmp/qemu-monitor.sock
}

qemu:force() {
    pwd=$(cat ~/Profile/Variables/pwd.txt)
    echo $pwd | sudo -SE zsh -c '
        source ~/.zshrc
        qemu::send:cmd:opt:esc
    '
}

autoload -Uz qemu::send:cmd:opt:esc

This is a file I import on my profile, so I can just type "qemu:force" in the console and it sends the key combo to QEMU.
Another handy thing I've been using is a command to mount a CD-ROM image on the fly. I'm using this to test the Retro68 tool, and it's been very handy. First, in the QEMU command, I added these options:

Code: Select all

-device ide-cd,bus=ide.1,drive=cd0 \
-drive if=none,id=cd0,media=cdrom \
etc

To mount the image I use this command:

Code: Select all

echo "change cd0 /Users/user/Classic/Discs/MyImage.img" | nc -U /tmp/qemu-monitor.sock

Same deal with the root stuff. I actually use a script for that like this:

Code: Select all

#!/bin/bash

# Path to your CD-ROM image
CDROM_IMAGE="$1"

# Send commands to QEMU monitor socket
send_monitor_command() {
    printf "$1\n" | nc -U /tmp/qemu-monitor.sock
}

# Eject current media (if any)
send_monitor_command "eject -f cd0"

# Insert new media
send_monitor_command "change cd0 $CDROM_IMAGE"

There's a lot more that can be scripted with monitor. Check the docs here: https://www.qemu.org/docs/master/system/monitor.html
You can forcefully quit it, create a snapshot of the machine, pause and resume, generate a memory dump, manipulate the mouse, get useful info, and some advanced stuff.
I imagine these tools can be used for potential user interfaces, bash scripts, apple scripts, and other clever things.

[adespoton]

It's probably worth pointing out that on the macOS build of QEMU, you can access the monitor directly from the menu bar Of course, using the monitor this way, output is redirected to the monitor window OR a standard video output window, not both -- you have to flip between them. Creating a socket allows you to have a monitor window running in the terminal while video is still being displayed, which can have its benefits, especially on a multiscreen system.

[sentient06]

Creating a socket allows you to have a monitor window running in the terminal while video is still being displayed, which can have its benefits, especially on a multiscreen system.

Yes! It's great for automating. There's a thread in the Basilisk forum, I think, where there's a debate on how to start up a VM without Finder and go straight into an app by using some MPW tool, and I reckon that could be replicated in QEMU by using socket. The ability to attach a volume on the fly and type key combinations can be used for immediate transfer of files and even apps and creating a whole world of workflows. One could even create some Apple scripts in the guest OS and execute other kinds of automation.

I just want to figure out how to get information out of QEMU's guest OS now. The whole experience with QEMU has been very one-sided so far. The only effective way I can get stuff out of QEMU is by mounting a writable img volume and mounting it on macOS after terminating QEMU. =(

[Cat_7]

You might run an FTP server on Qemu.

Best,
Cat_7

[adespoton]

Creating a socket allows you to have a monitor window running in the terminal while video is still being displayed, which can have its benefits, especially on a multiscreen system.

I just want to figure out how to get information out of QEMU's guest OS now. The whole experience with QEMU has been very one-sided so far. The only effective way I can get stuff out of QEMU is by mounting a writable img volume and mounting it on macOS after terminating QEMU. =(

Which guest OS are you using?

Under Mac OS 9, shared folder support works out of the box now (data fork only). I've also had success using an NFS share on the host with MacNFS on the guest, and with AppleShare IP on the host/guest. And as Cat_7 said, FTP also works.

I haven't yet figured out a way that preserves metadata or resource forks, so you'll have to encode everything first. Of course, if you use Fetch on the guest, it automatically encodes stuff in MacBinary and automatically decodes MacBinary files when downloading....

[sentient06]

Which guest OS are you using?

Mac OS 9.2.2 is my favourite atm. It's the most stable for me.

Under Mac OS 9, shared folder support works out of the box now (data fork only). I've also had success using an NFS share on the host with MacNFS on the guest, and with AppleShare IP on the host/guest. And as Cat_7 said, FTP also works.

Do you mean sharing a folder as one would do to share on Apple Talk? Or a built-in QEMU share?

I haven't yet figured out a way that preserves metadata or resource forks, so you'll have to encode everything first. Of course, if you use Fetch on the guest, it automatically encodes stuff in MacBinary and automatically decodes MacBinary files when downloading....

Yes, I have encountered a lot of nuisance with resource forks since I started using QEMU. Mounting the volumes on macOS keeps them untouched, that's one reason why I use it most. The QEMU shared volume seems to corrupt files at random. I noticed a few files get the name garbled up on occasion. If I just drop a SIT file there, it typically works, as long as I restore creator and type.

You might run an FTP server on Qemu.

Yes! Thanks! I feel quite stupid now because I never thought about hosting the FTP in the guest; in my mind I always pictured FTP running in the host and thought it would be annoying to use an FTP client to exchange files. But it's obvious, if I host it in the guest it would be way simpler as I could mount the FTP on the host.

I mean, that's all about files, which is an important piece of the experience, but my initial thought in this thread concerned text data. My initial concern was to get a serial output to log some code, and then I thought about automating spitting the clipboard out the same serial port. All my attempts to do that failed however. I've been looking for an app to test the serial ports to see if perhaps the code I got is not doing what it's supposed to be doing, but I didn't find anything useful yet.

[adespoton]

Which guest OS are you using?

Mac OS 9.2.2 is my favourite atm. It's the most stable for me.

Under Mac OS 9, shared folder support works out of the box now (data fork only). I've also had success using an NFS share on the host with MacNFS on the guest, and with AppleShare IP on the host/guest. And as Cat_7 said, FTP also works.

Do you mean sharing a folder as one would do to share on Apple Talk? Or a built-in QEMU share?

Built-in QEMU share: viewtopic.php?t=11973

That thread starts with Elliot creating stand-alone drivers, but those were eventually merged into a QEMU VirtIO patch and can be loaded directly into OpenFirmware as part of the QEMU command line (see later in the thread). So you can use VirtFS to just mount a host folder in QEMU.

Code: Select all

-device virtio-9p-pci,fsdev=UNIQUENAME,mount_tag="Host Share" \
-fsdev local,id=UNIQUENAME,security_model=none,path=/PATH/TO/HOST/FOLDER

You can change the mount_tag value from "Host Share" to whatever you want to call the mounted virtual disk, UNIQUENAME to some unique device name ID, and path to the path you want to share. If the path is to a hardware device, you may need to run QEMU as root to have read/write access.

You do need to run a QEMU that has the VirtFS patch applied -- we have those on here in the PPC QEMU downloads thread. Elliot has the latest version of the drivers to drop in the QEMU folder available here: https://github.com/elliotnunn/classicvirtio/releases -- last update was 3 weeks ago.

More info available here: https://github.com/elliotnunn/classicvirtio

[edit] Looks like Elliot's got appledouble resource handling working now too -- that means you can write files with full resource and metadata out to the file share, although it won't take advantage of named forks on modern macOS, instead using appledouble on all platforms.

Also, to bring this full circle: notice that there's also a debug output device available