CharlesS wrote: Tue Jul 11, 2023 2:25 pm
Update: turns out that when I changed the hard drive to IDE, even though it still wasn't showing up in Disk Utility, diskutil was able to see it in the Terminal, and I was able to format that way as APFS, after which I was able to start the installer and get the installation files copied over to the drive. Unfortunately, on rebooting, the only option in the OpenCore boot menu was to boot from the iso again. So I shut down, removed the ISO from the VM thinking that perhaps if the HD was the only thing to boot from, it would work. No luck there—the OpenCore boot menu only has OpenShell.efi and Reset NVRAM as options.
Now, the part that really grinds my gears: Even if I put the ISO back, now it doesn't show up in the OpenCore boot menu either! And worse than that, even if I download the template fresh and select the ISO, it doesn't show up as a boot option there. Nor do any of several other boot images that were working before. Fiddling with order and IDE/USB doesn't seem to change anything here; I seem to have somehow globally lost the ability to boot from ISOs to this VM, so I can't even get back to where I was last night. Do you know what might have caused this, or any way to force this thing to accept something as a boot disk?
UTM up to 4.3.1 only supports a single IDE cable; if you've got 3 virtual images on the IDE bus, one of them won't be addressed correctly. This is one of the reasons I had some stuff set to USB.
It's possible that's what's going wrong here. Unfortunately, USB has some latency issues, so you can end up with read/write errors if the process is expecting it to work faster than it does. So it's best not to use USB for anything that is writing large files or requires low latency.
I think I figured it out; instead of adding the install image as a CD/DVD ISO, I converted it to a raw image with qemu-img and mounted it as a plain old drive and it boots again. Makes sense; the usual way to use the images made by createinstallmedia is, after all, to image them onto a USB stick, which is read-write, not a read-only medium like a DVD.
I've got an installation going on now, fingers crossed that it succeeds.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
CharlesS wrote: Tue Jul 11, 2023 10:59 pm
I think I figured it out; instead of adding the install image as a CD/DVD ISO, I converted it to a raw image with qemu-img and mounted it as a plain old drive and it boots again. Makes sense; the usual way to use the images made by createinstallmedia is, after all, to image them onto a USB stick, which is read-write, not a read-only medium like a DVD.
I've got an installation going on now, fingers crossed that it succeeds.
Ah; yes -- it needs to be an actual ISO or disk image mounted raw, not a dmg.
CharlesS wrote: Tue Jul 11, 2023 4:20 am
Yeah, and the x86 code for the TCG emulator must be bad. I know the M1 Max is faster than the old Core i9 Macs, but not this much faster.
QEMU's JIT is quite advanced, including its own optimiser, and is well-known to be one of the quickest around. What sort of numbers are you seeing? I have a test WinXP image which is fairly vanilla, and on my 12 year old core2duo I get the following numbers from startup to the login screen:
adespoton wrote: Mon Jul 10, 2023 3:16 pm
I suspect that something Osy's done with version 4 has forced x86 hosts to use the TCG emulator as well. And with the switch to QEMU 8 for 4.3.x (still in beta), it appears all sorts of things have broken (PPC and x86_64 emulators). Some of those things appear to be broken in QEMU though, not specifically UTM.
Just out of interest have you got any more information about what is broken? Specifically the QEMU versions, command lines and guest OSs in use would be good to know to understand if this is an upstream or UTM-only issue.
adespoton wrote: Mon Jul 10, 2023 3:16 pm
I suspect that something Osy's done with version 4 has forced x86 hosts to use the TCG emulator as well. And with the switch to QEMU 8 for 4.3.x (still in beta), it appears all sorts of things have broken (PPC and x86_64 emulators). Some of those things appear to be broken in QEMU though, not specifically UTM.
Just out of interest have you got any more information about what is broken? Specifically the QEMU versions, command lines and guest OSs in use would be good to know to understand if this is an upstream or UTM-only issue.
I'll dig it up; there's an issue filed on my utmconfigs project and the utm app, but I've replicated the one issue on qemu-system-x86_64 8.0 and 8.0.2 homebrew running on an M1 Pro running 13.4.1.
CharlesS wrote: Tue Jul 11, 2023 4:20 am
Yeah, and the x86 code for the TCG emulator must be bad. I know the M1 Max is faster than the old Core i9 Macs, but not this much faster.
QEMU's JIT is quite advanced, including its own optimiser, and is well-known to be one of the quickest around. What sort of numbers are you seeing? I have a test WinXP image which is fairly vanilla, and on my 12 year old core2duo I get the following numbers from startup to the login screen:
Just tried firing up my UTM VM on my i9 and timing it; it took approximately 8 minutes 20 seconds. It looks like UTM uses -accel hvf when "Use Hypervisor" is selected. With "Use Hypervisor" turned off, it switches to -accel tcg. There doesn't seem to be an obvious way to force it to use -accel kvm (setting the "KVM" options for "CPU" under "System" doesn't seem to do it either AFAICT).
On my M1 Max, it takes closer to 60 seconds. It's odd.
It also performs reasonably responsively on the M1 Max, whereas on the i9 you get things like clicking on the Start button and then waiting 13 seconds before the menu opens. Not very pleasant.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
... okay, that's weird. Instead of using UTM, I decided to try it using qemu from homebrew, using the same command line you used and it took... 39 seconds with -accel tcg, almost exactly the same as yours. With -accel kvm I get an error message: "qemu-system-x86_64: -accel kvm: invalid accelerator kvm". With -accel hvf it takes 2 minutes and 2 seconds, and has the same really bad lag when clicking on anything. What the heck.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
Thinking it might have been the fact that the stable version of UTM, 4.2.5, uses an older version of QEMU, I just tried it with the 4.3.1 beta. Unfortunately, it still takes around 6 minutes to get to the desktop on my i9 with -accel tcg. So, it's got to be either something UTM is doing in wrapping QEMU, or something off in the VM's settings. Hrm.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
CharlesS wrote: Thu Jul 13, 2023 3:35 am
Just tried firing up my UTM VM on my i9 and timing it; it took approximately 8 minutes 20 seconds. It looks like UTM uses -accel hvf when "Use Hypervisor" is selected. With "Use Hypervisor" turned off, it switches to -accel tcg. There doesn't seem to be an obvious way to force it to use -accel kvm (setting the "KVM" options for "CPU" under "System" doesn't seem to do it either AFAICT).
KVM is the OS hypervisor for Linux (compare with Hyper-V for Windows and HVF for macOS) and requires that the host OS architecture matches the guest OS architecture, so it only makes sense to enable "Use Hypervisor" on your i9.
CharlesS wrote: Thu Jul 13, 2023 3:35 am
On my M1 Max, it takes closer to 60 seconds. It's odd.
It also performs reasonably responsively on the M1 Max, whereas on the i9 you get things like clicking on the Start button and then waiting 13 seconds before the menu opens. Not very pleasant.
I wonder there is some odd magic going on and -accel hvf is somehow invoking Rosetta in the background?
Last edited by mcayland on Thu Jul 13, 2023 5:42 am, edited 1 time in total.
CharlesS wrote: Thu Jul 13, 2023 4:00 am
... okay, that's weird. Instead of using UTM, I decided to try it using qemu from homebrew, using the same command line you used and it took... 39 seconds with -accel tcg, almost exactly the same as yours. With -accel kvm I get an error message: "qemu-system-x86_64: -accel kvm: invalid accelerator kvm". With -accel hvf it takes 2 minutes and 2 seconds, and has the same really bad lag when clicking on anything. What the heck.
Right that's much more like what I would expect with -accel tcg so there must be something different that UTM does here. Clearly there is something odd is happening with -accel hvf but again that should only be enabled for an x86 guest on an x86 host. Unfortunately testing Apple stuff for QEMU is hard because not many developers have access to the hardware, and not many CI services offer a macOS VM on x86/AS due to licensing restrictions
According to MAINTAINERS HVF is supported (see https://gitlab.com/qemu-project/qemu/-/ ... INERS#L492) so it's probably up to osy to file an appropriate bug report and help debug as appropriate. FWIW bugs that require more than a small amount of discussion are best reported via a thread on the qemu-devel list (with maintainers added as CC) as they will get a much wider audience.
CharlesS wrote: Thu Jul 13, 2023 3:35 am
On my M1 Max, it takes closer to 60 seconds. It's odd.
It also performs reasonably responsively on the M1 Max, whereas on the i9 you get things like clicking on the Start button and then waiting 13 seconds before the menu opens. Not very pleasant.
I wonder there is some odd magic going on and -accel hvf is somehow invoking Rosetta in the background?
CharlesS wrote: Thu Jul 13, 2023 4:00 am
... okay, that's weird. Instead of using UTM, I decided to try it using qemu from homebrew, using the same command line you used and it took... 39 seconds with -accel tcg, almost exactly the same as yours. With -accel kvm I get an error message: "qemu-system-x86_64: -accel kvm: invalid accelerator kvm". With -accel hvf it takes 2 minutes and 2 seconds, and has the same really bad lag when clicking on anything. What the heck.
Right that's much more like what I would expect with -accel tcg so there must be something different that UTM does here. Clearly there is something odd is happening with -accel hvf but again that should only be enabled for an x86 guest on an x86 host. Unfortunately testing Apple stuff for QEMU is hard because not many developers have access to the hardware, and not many CI services offer a macOS VM on x86/AS due to licensing restrictions
I should have been more clear; I was using -accel hvf on the i9, where Rosetta shouldn't be a thing. On the M1 Max, -accel tcg is the only option that is provided, as you would expect. On the i9, -accel hvf works, but somehow makes the virtualization slower than it is with tcg.
According to MAINTAINERS HVF is supported (see https://gitlab.com/qemu-project/qemu/-/ ... INERS#L492) so it's probably up to osy to file an appropriate bug report and help debug as appropriate. FWIW bugs that require more than a small amount of discussion are best reported via a thread on the qemu-devel list (with maintainers added as CC) as they will get a much wider audience.
Thanks, I'll look into it. Still will need to dig into the settings in UTM to see if any of the huge array of parameters it sends to QEMU are the problem that causes it to run slowly, or whether it's something UTM itself is doing, but once I get that figured out it may make sense to report that to the UTM team as well.
There's no earthly way of knowing, which direction we are going, for the rowers keep on rowing, and they're certainly not showing any signs that they are slowing.
CharlesS wrote: Thu Jul 13, 2023 3:35 am
On my M1 Max, it takes closer to 60 seconds. It's odd.
It also performs reasonably responsively on the M1 Max, whereas on the i9 you get things like clicking on the Start button and then waiting 13 seconds before the menu opens. Not very pleasant.
I wonder there is some odd magic going on and -accel hvf is somehow invoking Rosetta in the background?
CharlesS wrote: Thu Jul 13, 2023 4:00 am
... okay, that's weird. Instead of using UTM, I decided to try it using qemu from homebrew, using the same command line you used and it took... 39 seconds with -accel tcg, almost exactly the same as yours. With -accel kvm I get an error message: "qemu-system-x86_64: -accel kvm: invalid accelerator kvm". With -accel hvf it takes 2 minutes and 2 seconds, and has the same really bad lag when clicking on anything. What the heck.
Right that's much more like what I would expect with -accel tcg so there must be something different that UTM does here. Clearly there is something odd is happening with -accel hvf but again that should only be enabled for an x86 guest on an x86 host. Unfortunately testing Apple stuff for QEMU is hard because not many developers have access to the hardware, and not many CI services offer a macOS VM on x86/AS due to licensing restrictions
I should have been more clear; I was using -accel hvf on the i9, where Rosetta shouldn't be a thing. On the M1 Max, -accel tcg is the only option that is provided, as you would expect. On the i9, -accel hvf works, but somehow makes the virtualization slower than it is with tcg.
According to MAINTAINERS HVF is supported (see https://gitlab.com/qemu-project/qemu/-/ ... INERS#L492) so it's probably up to osy to file an appropriate bug report and help debug as appropriate. FWIW bugs that require more than a small amount of discussion are best reported via a thread on the qemu-devel list (with maintainers added as CC) as they will get a much wider audience.
Thanks, I'll look into it. Still will need to dig into the settings in UTM to see if any of the huge array of parameters it sends to QEMU are the problem that causes it to run slowly, or whether it's something UTM itself is doing, but once I get that figured out it may make sense to report that to the UTM team as well.
Charles, do you want to raise an issue against https://github.com/utmapp/UTM/issues ? if not, I'll do it so osy can track on the UTM side as well as file a QEMU report if needed.
My guess is that this particular issue is specific to UTM because osy disables defaults and manually sets all the config flags via UTM, managing them with UTM logic. And most of us are testing on Mx Macs, not x86_64 at this point, which explains why this got missed when something in the UTM config got changed (possibly in the migration from 3 to 4?).
This is I'm sure a silly question, but if I'm running OCLP on a 2011 Mac mini with UTM installed - as according to @Cat_7 because it doesn't have metal (2012 and above), the chances of getting an operational VM is near zilch, correct?
EagleDTW wrote: Thu Jul 20, 2023 9:10 pm
This is I'm sure a silly question, but if I'm running OCLP on a 2011 Mac mini with UTM installed - as according to @Cat_7 because it doesn't have metal (2012 and above), the chances of getting an operational VM is near zilch, correct?
TIA!
That's my understanding, yes.
UTM makes extensive use of Metal, and that will break. Much better to go with vanilla SDL QEMU -- which doesn't have the UI or the integrated SPICE engine or Apple VM, but is identical in all other respects.
UTM makes extensive use of Metal, and that will break. Much better to go with vanilla SDL QEMU -- which doesn't have the UI or the integrated SPICE engine or Apple VM, but is identical in all other respects.
That's terrific to know and thank you! I'm now looking into using Qemu alone is there a link for a good way to enable SDL capabilites/version?
Last edited by EagleDTW on Fri Jul 21, 2023 12:48 am, edited 1 time in total.
Has anyone figured out how to specify a bios that is not included in the UTM distribution? Every time that I try to launch a VM I get "could not load prom" with whatever bios I specify with '-bios <path to bios file>'.
I'm assuming that is due to sandboxing. Has anyone figured a way around that? I have lots of different BIOSes that I use that are not shipped with UTM.
ajacocks wrote: Tue Sep 12, 2023 5:51 pm
Has anyone figured out how to specify a bios that is not included in the UTM distribution? Every time that I try to launch a VM I get "could not load prom" with whatever bios I specify with '-bios <path to bios file>'.
I'm assuming that is due to sandboxing. Has anyone figured a way around that? I have lots of different BIOSes that I use that are not shipped with UTM.
- Alex
You just need to stick the file inside the sandbox folder. You can get there from the specific UTM config by right clicking it and selecting "Show in Finder".
Is there a reason you need a specific BIOS though? The ones for PPC Macs and Intel Macs are already included.
For qemu-system-ppc the -bios option only works if you want to load alternative openbios ppc elf files.
The two currently available are the standard openbios and the sound-enabled openbios.
So unless you compiled your own specific openbios, you cannot pass into qemu other files than the ones already provided.
However, you say you have many bios files to try. This leads me to believe you might not be using this option the way it should be by attempting to pass in another type of file.
You cannot change e.g., the machine type by loading a different rom.
Whether and why files might disappear is a question best asked on the appropriate channels.
I am having a weird issue, I had sound working with UTM for MacOS 9.2 for a long time since I have built this vm, but now I no longer have it working and I can't figure out why...
I have even lowered the RAM, disabled virtual memory in OS, reduced the resolution, looked around the machine config in UTM... the screamer is selected.
Another thing of note is that I have these virtio drivers for OS 9 by elliotnunn, so I could access a share on my host mac.
Bruninho wrote: Mon Feb 23, 2026 1:24 pm
I am having a weird issue, I had sound working with UTM for MacOS 9.2 for a long time since I have built this vm, but now I no longer have it working and I can't figure out why...
I have even lowered the RAM, disabled virtual memory in OS, reduced the resolution, looked around the machine config in UTM... the screamer is selected.
Another thing of note is that I have these virtio drivers for OS 9 by elliotnunn, so I could access a share on my host mac.
Which UTM version are you using? Osy does his own custom UTM builds for PPC that are different from the ones on here; he may have updated something.
The virtio drivers are built in to his version now, so no need to re-inject them yourself -- the file sharing checkbox "just works" on OS 9.
Possibly Osy switched from using Screamer audio to USB audio in a recent version? I know he did some tweaking of USB support.
Bruninho wrote: Mon Feb 23, 2026 1:24 pm
I am having a weird issue, I had sound working with UTM for MacOS 9.2 for a long time since I have built this vm, but now I no longer have it working and I can't figure out why...
I have even lowered the RAM, disabled virtual memory in OS, reduced the resolution, looked around the machine config in UTM... the screamer is selected.
Another thing of note is that I have these virtio drivers for OS 9 by elliotnunn, so I could access a share on my host mac.
Which UTM version are you using? Osy does his own custom UTM builds for PPC that are different from the ones on here; he may have updated something.
The virtio drivers are built in to his version now, so no need to re-inject them yourself -- the file sharing checkbox "just works" on OS 9.
Possibly Osy switched from using Screamer audio to USB audio in a recent version? I know he did some tweaking of USB support.
So here is the thing, I ran a couple of tests. First I restored a backup of my VM. My tests have shown that the problem is the chosen mac sound output.
When I use the external monitor (a LG 4K 32" TV) the sound comes out from it just fine. I tested using a video on cornica.org of Steve Jobs unveiling the Mac 128K. I can hear him talking just fine. As well as some of the OS 9 sound effects (like, navigating the dropdown menus does a "ploc" like sound?).
Then when I use the speakers of my own MacBook Pro (M4 Pro), the sound also comes out just fine from the same tests. But when I use what I really want to use, the bluetooth audio, there is no sound.
I am hearing impaired, so I use a Cochelar Nucleus 8 hearing aid, the latest model from Cochlear Americas, which is MFi certified (Made For iPhone), therefore it pairs with my Mac and iPhone directly, no other bluetooth device required. I use it to listen to songs and youtube videos on my host mac just fine. It's just UTM that is not working well with any bluetooth output audio, apparently.
I also ran two more tests. I have a dock with extra ports. When I plug a headphone jack on it, no audio too. But if I plug the headphone jack directly on my Mac, there is audio to my headphones. For now, thats the only way to get audio in a private environment without disturbing people around me. If we ignore the dock issue, I think UTM has an issue with outputting audio to bluetooth audio devices.
Do you know what might have caused this, or any way to force this thing to accept something as a boot disk?
