Notes on using 86Box for server virtualization

Introduction

86Box is a popular emulator for vintage PC hardware. If you're into retrocomputing, you've probably used it to play old DOS and Windows games, or experiment with obscure operating systems. But did you ever think of using it to run a server? Bare metal servers have been passé for a long time now, and your retro setups need not be an exception. Hypervisors like QEMU and VirtualBox are popular options for server virtualization in the modern age, but older OSs tend to struggle with the emulated hardware they provide. That's the gap that 86Box can fill in.

That said, 86Box was pretty clearly never meant to be used like this, and there are some downsides:

High host CPU load: Even while idle, an 86Box VM will often use around 25-33% of one of your host's CPUs. Depending on how hard you're running things, that could rob power from other VMs or desktop applications, and might raise your electric bill.
Low guest performance: On a modern server-grade CPU, your VM will probably only be able to manage performace equivalent to a single 100- to 166-MHz Pentium CPU, and there is no support for SMP. But this is a retro server, so that's probably not a real problem.
Irregular speed: If your host isn't able to run the emulator at full speed (usually caused by heavy disk I/O rather than CPU load), the entire VM will be slowed to keep everything in sync. This makes keeping accurate time difficult.
No remote control: 86Box is meant to be run as an interactive graphical desktop application, so there's no elegant way to stop, restart, or modify running VMs from a script or shell.

Despite all that, it can still be a good option if more traditional hypervisors won't do the trick. Here are some tips on getting the most out of this somewhat peculiar setup.

Networking

86Box supports three forms of networking: SLiRP, PCap, and VDE.

SLiRP creates a "host-only" virtual network which allows your guest to communicate with the host machine, and uses NAT to provide the guest with access to the rest of your network. If you're using tunneling, load balancing, or a reverse proxy that might be just what you need. In most cases though it's not a good choice for a server.

PCap attaches to one of your host's network interfaces, giving the guest direct access to your network. This isn't a "true" bridge though, and it comes with the caveat that your host won't be able to talk directly to the guest (unless you have multiple interfaces).

If you want to use PCap on Linux without running 86Box suid root, you'll need to give it permissions:

	setcap cap_net_raw,cap_net_admin=+ep /usr/local/bin/86Box

Note that this will not work with AppImage or Flatpak.

Virtual Distributed Ethernet (VDE) uses userspace software to create virtual networks. You use "switch" and "cable" tools to build a virtual LAN in analogy to physical networks. If you're running Linux or MacOS on your host machine you can use this to get true bridged networking, simliar to the way QEMU does it. 86Box doesn't currently support VDE on Windows hosts.

Bridging with VDE

If PCap doesn't work for you, here's a brief rundown on how to use VDE for bridging. Note that these instructions are for Linux; MacOS may be different.

Create a bridge device: ip link add br0 type bridge
Connect your physical interface to it: ip link set (interface) master br0
Create a TAP device: ip tuntap add tap0 mode tap
Connect the TAP device to your bridge: ip link set tap0 master br0
Start the VDE switch and connect it to the TAP device: vde_switch -s /tmp/vde.ctl -m 666 -M /tmp/vde.mgt -t tap0 -d

On my Debian Linux host, I did this using the /etc/network/interfaces file:

	# Prevent NetworkManager from auto-configuring physical interface
	iface eno2np1 inet manual

	# Create the tap device and start VDE
	auto tap0
	iface tap0 inet manual
	        pre-up ip tuntap add tap0 mode tap
	        up ip link set dev tap0 up
	        post-up /usr/bin/vde_switch -s /tmp/vde.ctl -m 666 -M /tmp/vde.mgt -t tap0 -d

	# Set up the bridge device
	auto br0
	iface br0 inet dhcp
		hwaddress 00:80:10:2e:37:eb # give it a stable MAC address
		bridge_ports eno2np1 tap0

That's it! Now, in 86Box, go to the network settings page (Tools > Settings > Network), choose "VDE" as your mode, and enter /tmp/vde.ctl in the VDE Socket field. Your VM will now be bridged to your physical LAN, and you'll be able to communicate with the host through the same interface.

You'll probably want to read the official 86Box networking docs as well.

Time synchronization

As I mentioned earlier, 86Box tends to be irregular with its running speed, and this will make your guest's clock inaccurate. Clock-slewing sync methods like ntpd are unlikely to be able to cope, so you'll probably have to take a more blunt approach. On *NIX-type guests, I set up a cron job to run ntpdate every few minutes:

	*/5 * * * * /usr/local/sbin/ntpdate pool.ntp.org

You can do the same thing on Windows guests with Task Scheduler and a native NTP client.

Headless operation

Using features of the Qt GUI toolkit 86Box is built with, it's possible to finagle it into running headless. Simply start 86Box with -platform offscreen and off it goes. Note that the only way to shut it down is to kill -9 it, which is safe to do as long as you properly shut the guest down first.

If your copy of Qt was built with it, you can also use the Qt VNC Server.

	86Box -platform vnc:port=5903 -P (vm directory)

This will start a VNC server on port 5903, from which you can access the 86Box GUI. Make sure to pick an unused port. Note that you won't see any guest video output, just the menus. If you need to be able to see and interact with the guest display, you could run a VNC server on the host and have 86Box use it.

	vncserver :3
	DISPLAY=:3 86Box -platform xcb -P (vm directory)

Specifying -platform xcb is needed if you are running Wayland on your host, to prevent 86Box from ignoring your VNC server and connecting to your Wayland display.

Automatic startup

You can have your 86Box VM start automatically when you boot your host. On Windows you could add it as a system service, or just drop a shortcut in the Startup folder in your Start Menu.

If you're running a Linux distro that uses systemd, you can create a service to launch your VM. Something like this:

	[Unit]
	Description=86Box Virtual Machine
	After=network-online.target

	[Service]
	Type=simple
	ExecStart=/usr/local/bin/86Box -platform offscreen -P (vm directory)

	[Install]
	WantedBy=multi-user.target

It is important to remember that you need to properly shut down your guest before rebooting your host machine to avoid data loss, especially on OSs without journaling filesystems! It might be possible to do this with a host-side script depending on what guest you're running (maybe with SNMP?), otherwise you'll have to remember to do it manually each time. On *NIX-likes, shell in and run halt or init 0.

Notes on Using 86Box for Server Virtualization