It's been more than a decade so it was time for me to build a new desktop workstation computer in 2025. This time, I wanted to try an AMD Zen 5 architecture, using a Ryzen 9 series central processing unit, rather than Intel. There were plenty of tribulations building the new computer: a week selecting gamer level parts so ECC error correcting memory would work at less than the cost of server hardware, a day of depression when it mysteriously failed to turn on (power light just flashed slowly in an undocumented way), then joy at discovering it was a short in the CPU heat sink decorative lighting wires going through sharp fins, and then the usual snags installing stuff and figuring out how to turn off two different decorative lighting systems. I finally got it booting and running Fedora 42 Linux.
Unfortunately my existing BeOS in a VirtualBox virtual machine crashed during boot-up of BeOS with a VirtualBox Guru Meditation Error (shades of Amiga). It looks like the AMD hardware isn't fully compatible with instructions or system hardware or something on an Intel system. Be had help from Intel when writing BeOS, so maybe they used a specialised compiler that does tricks which only work on Intel CPUs. Fortunately my more recent Haiku OS virtual machines and Linux VMs ran without problems in VirtualBox. So it's just BeOS I need to worry about.
Inspired by John Millikin's excellent 2022 article on running BeOS in QEMU-386 I tried out QEMU (Quick Emulator) with a command like qemu-system-i386 -machine type=pc -m 768M -drive media=cdrom,file=BeOS_Tools.01.iso -drive media=cdrom,file=BeOS_Tools.02.iso -drive file=VirtualBeOShda.qcow and was pleasantly surprised that it worked (after you turn off Use BIOS Calls in BeOS safe mode). Likely it is doing software emulation of the CPU, so it's slower (about the speed of a circa 1998 computer) but doesn't crash like a hardware based VM.
I did try the QEMU/KVM (Kernel Virtual Machine) the hardware based virtual machine that comes with Linux (rather than VirtualBox which is a separate install from Oracle) and uses QEMU to emulate non-CPU devices, while the real CPU runs your code almost directly using kernel controlled hardware guardrails to pretend your software has the entire CPU to itself. First of all, you can't use it simultaneously with VirtualBox, so I'd have to move all my other virtual machines over. It also didn't work when emulating a Pentium-3 (my original PC had dual P3/550Mhz CPUs), but it does work with a 486 or Pentium-1, but even so it runs several times slower, painfully slower, than qemu-system-i386. Odd. But unlike qemu-system-i386, it does emulate multiple CPUs! And the mouse doesn't go off screen and get reset to somewhere else on screen. Pity, a working hardware VM running BeOS makes it super fast, so fast that it can even play videos. But this one isn't working right.
The next step was to convert my BeOS hard drive images from VirtualBox to QEMU format, which VirtualBox does easily with a media toolbox copy command, selecting the QCOW (QEMU Copy On Write) format. It just takes a while for 128GB disks to be converted and saved to a new file (most of the time was reading from my new 16TB spinning metal hard drive, about 250MB/s, writing to my new 1TB solid state drive went at 8000MB/s). After that, and the disabling of BIOS calls in BeOS, it worked. Even networking, though behind a QEMU NAT. BeShare works (in I'm Firewalled mode), ssh works (though the host needs legacy encryption algorithms enabled) and web browsing works as well as expected (modern https algorithms unrecognised, use FrogFind.com).
However, it was also really annoying having the mouse pointer get reset to somewhere else on screen whenever the real mouse went off the edge of the emulator window. I could really use VNC to access the screen with a working mouse, and support copy/paste, and allow remote access. Though QEMU supports VNC access to the emulated screen, I expect it would have the same mouse problems, and no clipboard access.
VNC for BeOS needs to run as a server, which means it needs its own network connection, not hidden behind QEMU's NAT. Same for BeShare if you want to share files. I tried a reverse SSH tunnel, but BeOS's ancient ssh couldn't connect it.
The next thing to try is a network "bridge" that's described in the QEMU wiki and
described many times elsewhere. One article specific to Fedora Linux and the
nmcli (Network Manager Command Line) tool is Miklos Halasz's
Bridged
Networking on Fedora Workstation for Virtual Machines. It was
helpful, and combined with information from several other posts I got bridged
networking to work, even with a static IP address for my host computer.
Here's how you create a network bridge using nmcli in Fedora 42
Linux. You only need to do this once since it gets saved in persistent mode by
default.
The first step is to turn off your Fedora system's wired ethernet connection, if you already have one set up. Maybe later delete it if it comes up by default on reboot and if you don't want that.
This is because only one connection can use the real hardware at a time,
and we want the new bridge to be that connection. Though you can keep
both, and later do nmcli connection down "Wired Ethernet" then
nmcli connection up "VirtWires" to switch between them.
Note that we need to use ethernet hardware and not a WiFi device because under the hood it runs the hardware in promiscuous mode. Operating in that mode, the host receives all data packets, not just ones addressed to the host computer's IP address. It's needed because the virtual servers we are setting up to use the bridge have their own IP addresses separate from the host computer. WiFi often doesn't allow that as a security thing, so you can't see data packets with other IP addresses on the WiFi network. Though sometimes the particular WiFi hardware and driver does allow it, and sometimes it doesn't in the next software & firmware update. So it may work with WiFi, sometimes. Best to stick with ethernet.
nmcli con down "Wired Ethernet"
Make the top level bridge connection (I called mine "VirtWires", avoiding the confusion of using "br0" for the bridge connection and "br0" for the bridge device, but you can call it whatever you want), and the associated device ("vwbr0" for virtual wires bridge #0). The associated device will show up like your existing ethernet devices and be used by web browsers and other software to access the network. Oddly, nobody mentions that fact, and there's no need to make an explicit device to connect the host computer to the bridge.
nmcli con add type bridge con-name VirtWires ifname vwbr0
I want a static IP address for my host computer, since it is also runs a
few network services. I set the IP static address on both the bridge
connection (has no effect but properties exist in the listing from
nmcli con show VirtWires and do get visibly saved) and the
bridge device (these ones actually work but these settings aren't listed in
the device properties though they do get remembered somewhere). Otherwise
it defaults to DHCP and you get a random address for the host computer
vwbr0, which is not good for a server.
nmcli con modify VirtWires ipv4.method manual ipv4.addresses
"192.168.123.234/24" ipv4.gateway "192.168.123.2" ipv4.dns 8.8.8.8
ipv4.dns-search agmsmith.ca ipv6.method disabled
nmcli dev modify vwbr0 ipv4.method manual ipv4.addresses
"192.168.123.234/24" ipv4.gateway "192.168.123.2" ipv4.dns 8.8.8.8
ipv4.dns-search agmsmith.ca ipv6.method disabled
Connect the real ethernet device to the bridge. You can replace "bridge-slave" with "ethernet" if there's a depreciation warning message, but I think bridge-slave is more descriptive of what's going on.
nmcli con add type bridge-slave con-name vwslave ifname enp16s0
master VirtWires
Finally, get the computer to try it out, if it hasn't already started
it up while you were defining it. You may want to have journalctl
--follow open in another window to see the log messages.
nmcli con up VirtWires
QEMU has a helper program that creates a tap0 device (external access point to the virtual machine simulated network) and connects it to your bridge. Usually it has setuid root enabled by the install so that it can do its stuff with root priviledges, but if your install didn't do it, you can do:
chmod -v u+s /usr/libexec/qemu-bridge-helper
Then add a line saying "allow vwbr0" to /etc/qemu/bridge.conf
And finally start QEMU in your user account (doesn't need admin privileges) using your bridge device and an emulated Intel e1000 network adapter (I earlier added drivers for it to my BeOS):
qemu-system-i386 -machine type=pc -m 768M -drive
file=VirtualBeOShda.qcow -drive media=cdrom,file=BeOS_Tools.01.iso -drive
file=VirtualBeOShdb.qcow -drive file=VirtualBeOShdc.qcow -device
e1000,netdev=mybeos,mac=08:00:27:B1:06:D0 -netdev
bridge,id=mybeos,br=vwbr0
And that should be enough to get BeOS on the network with its own IP address (set manually in BeOS network preferences), and the ability to run servers (if you forward the right ports in your router to the BeOS system's static IP address).
Copyright © 2025 by Alexander G. M. Smith.