Autostarting Virtualbox VMs on Mac host

[jelockwood]

I recently finished building a number of Linux guest VMs on a Mac host and wanted them to autostart at boot without needing a user login or interaction. There are a number of articles on how to do this on the web but I found a couple of issues (and solutions) which I felt would be helpful to share here.

Firstly a general overview on how one does auto starting of VMs on a Mac.

• Write a launchdaemon plist file
  Write a config file to list which user accounts are allowed to run VMs
  Enable the desired VMs in those account(s)
  Enable the launchdaemon
  Reboot
  Test

Now the first problem is that at least on a Mac server there are a number of hidden system user accounts and some of these don't have user shells and therefore instead of a value for UserShell of e.g. /bin/sh they have a value of /usr/bin/false the script included with VirtualBox at /Applications/Virtualbox.app/Contents/MacOS/VBoxAutostartDarwin.sh includes a check for this. Unfortunately I have discovered some system accounts actually have a value of /bin/false and the script does not check for this. This results in it trying to start VMs for a large number of accounts that are not valid.

This is easily fixed by changing the line

Code: Select all

             || "${USERSHELL}" == "/usr/bin/false" || "${USERSHELL}" == "/dev/null" || "${USERSHELL}" == "/usr/sbin/uucico" ]]

to

Code: Select all

             || "${USERSHELL}" == "/bin/false" || "${USERSHELL}" == "/usr/bin/false" || "${USERSHELL}" == "/dev/null" || "${USERSHELL}" == "/usr/sbin/uucico" ]]

The second problem I found and probably the more serious one, is that all the example launchdaemon plist files I saw assume that the /Applications/Virtualbox.app/Contents/MacOS/VBoxAutostartDarwin.sh script needs two parameters, these being 'start' and the file path to a configuration file. This is wrong at least in VirtualBox 4.3.12 r93733 and I suspect several previous versions as well.

If you look at the bottom of the /Applications/Virtualbox.app/Contents/MacOS/VBoxAutostartDarwin.sh script, then you will see the following lines

Code: Select all

CONFIG=${1}
vboxStartStopAllUserVms "start"
trap vboxStopAllUserVms HUP KILL TERM

The CONFIG=${1} line means that the first parameter is the file path to the configuration file, the second line vboxStartStopAllUserVms "start" means it is hard-coded to start and does not need start passing to it as a parameter. Unfortunately all the example launchdaemon files have been written to pass it two parameters like so

script start /file/path/configfile.cfg

With these example launchdaemons having the start command as the first parameter it means the script is not getting a valid file path (because the file path is then in the second parameter) and this means it fails, launchd then keeps trying to run it again and you will get respawn messages in your system.log

So the solution to this is not to pass start as a parameter in your launchdaemon file, this will mean the command just becomes

script /file/path/configfile.cfg

A corrected launchdaemon file is listed below

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Disabled</key>
	<false/>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>org.virtualbox.vboxautostart</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Applications/VirtualBox.app/Contents/MacOS/VBoxAutostartDarwin.sh</string>
		<string>/etc/vbox/autostart.cfg</string>
	</array>
</dict>
</plist>

[ChipMcK]

Curious. Did you read 9.23. Starting virtual machines during system boot in the User Manual?

[jelockwood]

Curious. Did you read 9.23. Starting virtual machines during system boot in the User Manual?

Ah!
No.

I Googled and read several articles. Looks like the example launchdaemon included is correct, in this case Google is not your friend!

However my first issue still applies as this was using the included script.

[ChipMcK]

That would seem appropriate for BugTracker, yes?
This is an access Community

Do note that most users do not run Server.