DEV Community

RepairAmigo Team
RepairAmigo Team

Posted on

Running small-business software on a LAN: a practical checklist for an always-on VirtualBox host

#linux #devops #sysadmin #tutorial

Plenty of small-business tools ship as a ready-made virtual machine: import the appliance, start it, and staff open the app in a browser from any device on the LAN. The data stays in the building and nothing gets installed on workstations.

The catch is that the VM is only as reliable as the box underneath it. A host that suspends, renumbers itself on the network, or loses power mid-write turns "the app is down" into a weekly conversation.

Here's the checklist I'd hand to anyone setting up that host. It's Linux first (any systemd distro), with short Windows notes where steps differ.

1. Firmware and hardware

  • [ ] Dedicated machine. Not someone's daily laptop. A plain desktop with an SSD and wired Ethernet is ideal.
  • [ ] Enough RAM for host plus guest. Check the vendor's sizing and add headroom for the host OS.
  • [ ] Hardware virtualization on. In UEFI setup, enable Intel VT-x / "Virtualization Technology" or AMD SVM / AMD-V.
  • [ ] Restore on AC power loss = Power On. Most boards have this under power management. It lets the host come back by itself after an outage.

Confirm virtualization from Linux:

lscpu | grep -i virtualization
# Expect "VT-x" or "AMD-V". No output usually means it is off in firmware.
Enter fullscreen mode Exit fullscreen mode

Windows note: Task Manager → Performance → CPU shows "Virtualization: Enabled/Disabled".

2. Install VirtualBox cleanly

  • [ ] Install VirtualBox from one source (distro repo or official packages) with kernel headers and DKMS. After kernel updates, systemctl status vboxdrv should be green.
  • [ ] Secure Boot: if it is enabled, unsigned modules will not load. Either enroll a signing key (many distros walk you through this during install) or decide deliberately to turn Secure Boot off.
  • [ ] KVM conflicts: depending on your kernel and VirtualBox versions, loaded kvm_intel/kvm_amd modules can stop a VM from starting. Check with lsmod | grep kvm and resolve it before go-live, not during.
  • [ ] Create a dedicated, unprivileged user to own the VM, and add it to the vboxusers group. 
sudo useradd -m -s /bin/bash vmhost
sudo usermod -aG vboxusers vmhost
Enter fullscreen mode Exit fullscreen mode

Import the appliance as that user so the VM files live in its home directory:

sudo -iu vmhost VBoxManage import /path/to/appliance.ova
sudo -iu vmhost VBoxManage list vms
Enter fullscreen mode Exit fullscreen mode

3. Never sleep

  • [ ] Mask the sleep targets so nothing (desktop environment, idle timer, power button) can suspend the box: 
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
Enter fullscreen mode Exit fullscreen mode
  • [ ] If the host is a laptop, set HandleLidSwitch=ignore in /etc/systemd/logind.conf and restart systemd-logind.
  • [ ] Letting the display blank is fine.

Windows note: set sleep to "Never" on AC power, disable hibernation with powercfg /h off, and set Active Hours so update restarts land outside business hours.

4. Network: bridged, with a stable address

NAT is VirtualBox's default, and it hides the guest behind the host. Other machines on the LAN can't reach it without port forwards. For a shared app you want the guest to look like its own device on the network.

  • [ ] Find the host's wired interface name (ip -br link), then bridge the VM's first adapter to it: 
sudo -iu vmhost VBoxManage modifyvm "Shop VM" --nic1 bridged --bridgeadapter1 enp3s0
Enter fullscreen mode Exit fullscreen mode
  • [ ] Avoid bridging over Wi-Fi; many wireless drivers handle it poorly.
  • [ ] Grab the guest's MAC address: 
sudo -iu vmhost VBoxManage showvminfo "Shop VM" --machinereadable | grep macaddress1
Enter fullscreen mode Exit fullscreen mode
  • [ ] In the router or DHCP server, create a DHCP reservation for that MAC. VirtualBox prints it without colons, so add them when you type it in.
  • [ ] Reserve an address for the host too, so you can always SSH or RDP into it.
  • [ ] Don't port-forward the app to the internet unless the vendor documents that setup.

5. Autostart headless with systemd

The VM should come up after every boot with nobody logged in. First, a stop helper that asks the guest to shut down gracefully and waits:

sudo tee /usr/local/bin/shop-vm-stop >/dev/null <<'SH'
#!/bin/sh
VM="Shop VM"
VBoxManage controlvm "$VM" acpipowerbutton 2>/dev/null || exit 0
for i in $(seq 1 90); do
  VBoxManage list runningvms | grep -q "\"$VM\"" || exit 0
  sleep 2
done
# Guest ignored the request: save state rather than hard power-off
VBoxManage controlvm "$VM" savestate
SH
sudo chmod +x /usr/local/bin/shop-vm-stop
Enter fullscreen mode Exit fullscreen mode

Then the unit, /etc/systemd/system/shop-vm.service:

[Unit]
Description=Shop VM (VirtualBox, headless)
After=network-online.target vboxdrv.service
Wants=network-online.target

[Service]
User=vmhost
ExecStart=/usr/bin/VBoxHeadless --startvm "Shop VM"
ExecStop=/usr/local/bin/shop-vm-stop
TimeoutStopSec=300
Restart=on-failure

[Install]
WantedBy=multi-user.target
Enter fullscreen mode Exit fullscreen mode 
sudo systemctl daemon-reload
sudo systemctl enable --now shop-vm.service
Enter fullscreen mode Exit fullscreen mode
  • [ ] Reboot the host and confirm the app loads from another device without logging in to the host.

Windows note: a Task Scheduler task triggered "At startup", set to run whether or not a user is logged on, calling VBoxManage startvm "Shop VM" --type headless.

6. Clean shutdown, every time

With the unit above, sudo systemctl stop shop-vm or a normal host shutdown triggers an ACPI shutdown inside the guest, then waits for it. That is the only shutdown path anyone should use.

  • [ ] Put a note on the host: "Shut down from the OS, never the power button."

7. UPS that actually triggers shutdown

A battery that only buys time until it's flat just moves the hard power-off a little later.

  • [ ] Plug the host and the network switch/router into the UPS.
  • [ ] Connect the UPS's USB data cable to the host.
  • [ ] Install NUT (nut) or apcupsd, and configure it to shut the host down on low battery. Because the VM is a systemd service, the host shutdown stops the guest cleanly first.
  • [ ] Test it: NUT can simulate a forced shutdown with upsmon -c fsd. Do it after hours.

Windows note: use the UPS vendor's agent, and make sure your shutdown path stops the VM gracefully before Windows powers off.

8. Backups you have actually restored

Snapshots are rollback points stored right next to the disk they protect. They don't count as backups.

  • [ ] Prefer the application's own backup/export if it has one, and schedule it.
  • [ ] Also take periodic full-VM copies while the guest is stopped: 
sudo systemctl stop shop-vm
sudo -iu vmhost VBoxManage export "Shop VM" -o /mnt/backup/shop-vm-$(date +%F).ova
sudo systemctl start shop-vm
Enter fullscreen mode Exit fullscreen mode
  • [ ] Keep at least one copy off-site (a rotated USB drive works).
  • [ ] Restore test: import a backup on a spare machine with networking disconnected and check the data is there. A backup you have never restored is still a guess.

9. Go-live verification

  • [ ] Cold boot: power off at the wall, power on, and wait. The app comes back with no keyboard touched.
  • [ ] Address check: the app is on the reserved IP after a reboot.
  • [ ] Every staff device has a bookmark to that address.
  • [ ] journalctl -u shop-vm shows clean starts and stops.
  • [ ] The UPS test passed, and a restore test passed.

Wrapping up

None of this is exotic, but together it turns "the VM" into infrastructure the business can lean on.

We put this list together while building RepairAmigo, free software for repair shops that runs as one VirtualBox VM on the shop network and is used from any browser. We recommend a host PC with 16 GB of RAM, since the VM is allocated 8 cores and 8 GB. Release is coming soon; details are at repairamigo.com. Questions go to support@repairamigo.com.

The RepairAmigo Team

Top comments (0)