Why? Again, we hit this point again. Oracle has chosen to keep at least the core functionality available via GPLv2. A few other things that they don't have the right to license that way are available as a free (as in beer) download, including USB, RDP, and PXE booting.
When you first install VirtualBox, it appears to pretty much duplicate the functionality of VMware Workstation. Which would be cool enough, being open source, and given VMware's decisions about Server. Yes, I am aware that ESXi is also free beer. It also demands server class hardware. Which negates the cost savings, at least within the SOHO type of environment in which we work, consult, and write.
But there is So Much More. Along with the nice Qt (we'd have preferred gtk, but small potatoes) GUI for setting up clients and running them `application style,´ VirtualBox for Linux comes with command line controls to manipulate and run the VM clients from the console and in the background. Along with some trivial sysvinit hacking, we can run the clients at boot time, and shutdown or savestate them at shutdown and reboot.
Using the binaries VBoxHeadless and VBoxManage, along with a simple startup/shutdown script, here is how we accomplished this. As an aside, the script is based on the excellent tutorial at debian-administration.org.
Here's the script, as we're running it to launch our PBX in the background, in the rare occasion that the debian host has to go down.
! /bin/sh # /etc/init.d/telco # # Some things that run always touch /var/lock/telco # Carry out specific functions when asked to by the system case "$1" in start) echo "Loading telco in background. . . " sudo -u waldo /usr/bin/VBoxHeadless -s Asterisk\ Appliance &; ;; stop) echo "Saving telco machine state before stopping host. . ." sudo -u waldo VBoxManage controlvm Asterisk\ Appliance savestate ;; *) echo "Usage: /etc/init.d/telco {start|stop}" exit 1 ;; esac
In this example, 'telco' is the name of the script, taken from the hostname. 'Asterisk Appliance' is the name of the VM, as it's known to VBox. Run both VBoxHeadless and VBoxManage '-h' for more information about the various command line options available. They do a lot more than this. The man pages are comprehensive for both, as well.
After the script is created, and you've made sure you haven't left off the all important ampersand described in the notes below, run this to install the script.
update-rc.d telco defaults
Under current debian-testing (wheezy), the output of that command isn't the reassuring list of actions described at debian-administration.org, but rather, an dominous warning about LSB tags. But it works just the same. Check to see your new telco symlinks in rc2.d and rc0.d (it's in the other runlevels too, but these are the ones that count.) Reboot the machine to see your new automagic.
You can duplicate this script as many times as you need with new names for the script and the client OSs, to launch multiple VMs.
A couple of *important notes* are due. You can really scramble things by leaving off the job control character at the end of the loading command.
sudo -u waldo /usr/bin/VBoxHeadless -s Asterisk\ Appliance &;
is just not the same without the ampersand (&). With it, it loads in the background. Without, and the following scripts will never load. Which means you'll never get to getty, and never get a login prompt. Hope you have ssh or gdm, and that they were set to load before, not after. Otherwise, you've got a bit of fun on your hands trying to get logged into a console to fix this. Probably, you'll be glad you have an ubuntu live cd handy. The other is, virtual machines are stored in the home folder of the user that creates them. The savvy and perfectionist hacker copies them and the relevant files from ~/.VirtualBox and ~/VirtualBox VMs to a special unprivileged user created just for this service. sudo -u drops the superuser permissions, and runs the commands as the specified user. The lazy hacker creates them and runs them as his day-to-day unprivileged user. One final note. This script is quick and dirty, and works. But it could and should be much better. The smarter script would check for the existence of the VM, check it's state, perform specific actions depending on whether it was last stopped, saved, or crashed out violently. It would check to see that the relevant vbox kernel modules are loaded. We just haven't gotten that far, and for the purposes of a novice level tutorial, it would be a long script, the core functionality of which would be obscured by the much longer sections of propriety.
Also, by default, update-rc.d installs the link in rc0.d in such a way that the script to unload vbox kernel modules runs before the machine is saved. Move K01virtualbox to K02virtualbox, or later, to give machines time to savestate before unloading modules. Otherwise module unloading fails. But it works just the same, except for the nasty red error flag. Not unloading them before reboot doesn't actually seem to affect functionality.
No comments:
Post a Comment