Blog

Automatically Starting VirtualBox VMs on Archlinux Using Systemd

On 17 Mar, 2013 By With 10 Comments

If you are looking to start your VirtualBox VMs automatically on boot using systemd look no further.

Create the Service File

This Arch Linux wiki page contains a sample service file that you can use to start VirtualBoxVMs in a headless mode. Add a file called ‘vboxvmservice@.service’ in /etc/systemd/system/.

Put this in the file:

[Unit]
Description=VBox Virtual Machine %i Service
Requires=systemd-modules-load.service
After=systemd-modules-load.service

[Service]
User=user
Group=vboxusers
ExecStart=/usr/bin/VBoxHeadless -s %i
ExecStop=/usr/bin/VBoxManage controlvm %i savestate

[Install]
WantedBy=multi-user.target

Replace the user after user= with the username you want to run the VMs. Make sure that the user is in the vboxusers group. If you need to delay the start of the VMs until after your network is started or a network share is mounted, locate the service you want to wait for using ‘systemctl’ and then substitute the service, mount, or network behind ‘After=’.

You can also replace ‘savestate’ in ‘ExecStop=’ with ‘poweroff’ or ‘acpipowerbutton’ to hard-stop the VM, or ask for a clean shut-down, respectively.

Enable the Service

To enable one or more VMs at boot, enter:

#systemctl enable vboxvmservice@vm_name.service

Use ‘systemctl start’ to immediately start the VM. After your computer starts up, you can use ‘systemctl –failed’ to make sure everything went smoothly. You may need to turn off 3D video features for your VM to run in headless mode.

You can continue to manage your VMs using the GUI interface if you choose. For more information on using systemd, see the general Arch Linux Wiki Page.

This Post Has 10 Comments

  1. rpyne says:
    March 3, 2016 at 14:48 - Reply

    I am trying to implement this method because it looks like the cleanest option I’ve seen. I can cleanly shutdown the vm using the /usr/bin/VBoxManage controlvm acpipowerbutton from the shell, or from the acpipowerbutton in phpvirtualbox, but when I run it using systemctl stop in the host machine, it appears to kill the vm immediately without a clean shutdown.

      • Rich McAllister says:
        August 13, 2016 at 10:04 - Reply

        KillMode=None/TimeoutStopSec does get the acpipowerbutton to the VM, and if it does shut down cleanly as a result, everything is fine. But if the VM doesn’t shut down in response to the acpipowerbutton, the VM service just stays up. I was afraid this would make system shutdown hang forever (though I didn’t try it.)

        What I tried instead was

        ExecStop=/usr/bin/VBoxManage controlvm %i acpipowerbutton
        KillMode=process
        KillSignal=SIGWINCH
        TimeoutStopSec=40

        At stop, this sends the acpipowerbutton and kills the process immediately with SIGWINCH, which doesn’t do anything (ignored by default.) Then, if the VM hasn’t shut down after the timeout, the process is killed with SIGKILL.

        The KillMode=process is because VBoxSVC and VBoxXPCOMIPCD might be running in this service’s cgroup and we wouldn’t want to kill them if they are servicing other VMs running.

        I haven’t yet grokked the fullness of systemd cgroup/slice stuff but it seems to me that since all VMs for a user share the VBox server processes, all the VBoxHeadless and VBox server processes for a user ought to be in the same cgroup.

  2. Rob says:
    September 1, 2016 at 14:01 - Reply

    Just a quick one for anyone who had the same issue as I did.

    I found that after a reboot of my Ubuntu 16.04.1 machine, my VMs would not start. running systemctl status vboxvm@ threw up an error like “WARNING: The vboxdrv kernel module is not loaded. …”

    This was odd as the services would start if started manually, with no complaints.

    I double-checked the Kernel modules were in fact loaded, and after a bit of trial-and-error, I realised that the vboxvm@ services were being started before the vboxdrv.service.

    Changing “After=systemd-modules-load.service” to After=systemd-modules-load.service vboxdrv.service” was all it took to get it up and running after every boot.

    Thanks Eric for the multi-VM script. It (now) works like a charm!

  3. Sinooko says:
    January 7, 2018 at 08:10 - Reply

    I keep hitting the same snag over and over again.
    It’s easy to believe something has changed since 2013, but all my googling and all my grokking has ended with failure thus far.
    Process: 2055 ExecStop=/usr/bin/VBoxManage controlvm win7 acpipowerbutton (code=exited, status=1/FAILURE)

    Does anyone know anything new with regard to this?

  4. Wiegando says:
    May 6, 2018 at 11:35 - Reply

    Thanks a lot!

    Up to Ubuntu 17.10 the solution with

    After=systemd-modules-load.service vboxdrv.service

    solved the problem.

    After the update to 18.04 I needed to modify the attribute to

    After=virtualbox.service

    to get it working again.

  5. ketarino says:
    September 20, 2018 at 00:56 - Reply

    Thank you very much!! As a Linux newbie, I spent almost an entire day trying to figure out how to run two VM’s in Fedora 28 LXDE. This saved my day. 🙂

Leave A Reply