OpenBSD is flaky with QEMU on macOS

[manxorist]

Failing runs:

• https://github.com/OpenMPT/openmpt/actions/runs/7489465703/attempts/1
• https://github.com/OpenMPT/openmpt/actions/runs/7489465703/attempts/4

Working runs (exactly identical configuration):

• https://github.com/OpenMPT/openmpt/actions/runs/7489465703/attempts/2
• https://github.com/OpenMPT/openmpt/actions/runs/7489465703/attempts/3

I did not see such intermittent crashes with xhyve.

[jacob-carlborg]

Strange. Different errors for the failing jobs. Could it be running out of memory or some other resource?

I did notice for the successful jobs, it takes 10 minutes to sync the files to the VM. Does it take that long with Xhyve as well?

[manxorist]

Strange. Different errors for the failing jobs.

It really looks like OpenBSD just running unstable in that VM.

Could it be running out of memory or some other resource?

No, unless the QEMU VM uses vastly more virtual CPUs as the Xhyve VM (I have not checked).

I did notice for the successful jobs, it takes 10 minutes to sync the files to the VM. Does it take that long with Xhyve as well?

typical run on Xhyve: https://github.com/OpenMPT/openmpt/actions/runs/7479081342/job/20355472047

Not sure where I can find that number, I looked at Startup VM total time, which is way faster with Xhyve (3..4min). Installing dependencies is also faster (~9min vs ~12min), but the actual compilation is faster with QEMU. Syncing files and installing dependencies is easily IO-bound, while compilation would be CPU-bound. File IO is notoriously slow on OpenBSD in general, but QEMU cache=unsafe should mitigate most of that, and that should be the default now, unless I misunderstood something.

[jacob-carlborg]

No, unless the QEMU VM uses vastly more virtual CPUs as the Xhyve VM (I have not checked).

It should be the same.

typical run on Xhyve: OpenMPT/openmpt/actions/runs/7479081342/job/20355472047

That takes just two minutes.

Not sure where I can find that number

When viewing a job on GitHub, there's a gear icon in the upper right corner, just after the Search logs input field. If you click that you can select to show timestamps. Then, in the output view, expand the Setting up VM line. Just before the Running command you should see a call to rsync. Just compare the timestamps to the previous line.

but QEMU cache=unsafe should mitigate most of that, and that should be the default now, unless I misunderstood something.

Yes, that's the default.

[manxorist]

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

[jacob-carlborg]

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

Hmm, interesting. I would expected QEMU to work the same on both macOS and Linux. Unless it's an issue with the hardware acceleration, which will be different.

[manxorist]

After #47, I do not have any use case for this any more. I am running OpenBSD on QEMU on Ubuntu now, which appears to work fine so far.

Hmm, interesting. I would expected QEMU to work the same on both macOS and Linux. Unless it's an issue with the hardware acceleration, which will be different.

QEMU with Linux KVM probably gets way more testing in practice than QEMU with whatever macOS provides as a acceleration interface,