VBoxTool: VirtualBox management framework

[markba]

VBoxTool: easy control of VirtualBox sessions on a headless server

I would like to present my latest Open Source project: VBoxTool

It provides easy control of virtual machines of VirtualBox on a Linux headless server, published as free and open source software.

Currently VirtualBox lacks a decent management environment for controlling virtual sessions on a headless server environment. VBoxTool mimics partly Virtual Machine Manager which controls sessions for other virtualization solutions like Qemu, KVM, etc. Unfortunately, VirtualBox is not in the list of supported engines (nor will be in the near future).

Features

Heart of the framework is a script which can do several actions (start, save, backup, etc.) on all registered VirtualBox sessions in batch mode. It is a wrapper around VBoxManage (the commandline interface of VirtualBox), so execution is also by command line.

• Show info of all registered sessions. Name, status (running, saved, etc.) and other info like the configured VRDP port are shown with the command 'vbox show'. When a session is running, also CPU load and memory usage are shown. As an alternative, 'vbox showrun' shows info only of running sessions.
• Mass operation: save, start, stop. Save all running sessions with one command: 'vbox save'. Start all saved sessions with 'vbox start'. Stop all running sessions with 'vbox stop'.
• Mass backup. Backup all sessions using rsync with one command: 'vbox backup'. When a session is running, it is saved and restarted after the backup. The next level of backup, could mean that online backup (thus without bringing the session offline) is possible*.
• Batch start. Controlled start of several sessions, defined in a configuration file, /etc/vboxtool/machines.conf. Only sessions named in that file will be started by 'vboxtool autostart'.
• Mass configuration of VRDP port and port forwarding. Configure VRDP port and port forwarding for all sessions, all at once in one command: 'vboxtool autostart'. Configuration takes place in /etc/vboxtool/machines.conf. When using port forwarding, there's no need for host interfacing anymore (in Linux, a tedious, complex task).
• Autostart at host boot. When the host boots, all sessions registered in /etc/vboxtool/machines.conf will be started in the background, issuing a 'vboxtool autostart' command under the named vbox_user in /etc/vboxtool/vboxtool.conf.
• Autosave at host halt. When the host has a controlled down, i.e. halted, all running sessions are automatically saved.
• *System monitoring. Monitor server status, session cpu load and memory in a graphical image. This will be done by developing and implementing a Munin plugin. Munin is a system monitoring platform with a plugin structure.
• *Webserver. Next to develop is a webserver which points to the automation script. With this you can activate all functions from the script, all by a web page, so without requiring shell access.

* Not (yet) implemented.
** Partly implemented.

Command: vbox autostart

Through autostart, sessions can be started in a controlled way: only the sessions in the configuration file will be started. As a bonus, the VRDP port and portforwarding pairs (also configurable) can be set at startup time. Option autostart depends on a configuration file, /etc/vbox/machines.conf. Each line in this file is a separate machine.

Structure of each line: <session-name>,<vrdp-port>,<hostport-guestport>|<...>.

The given VRDP port is set statically to the session, prior to starting; state is discarded when session is in savestate. You can issue as many portwarding pairs as you like.

Example for /etc/vbox/machines.conf:

Code: Select all

Ubuntu Desktop,3391,2022-22
Ubuntu JeOS,3392,2022-22|80-80

Resources

• VBoxTool website: http://vboxtool.sourceforge.net
• Sourceforge project: http://sourceforge.net/projects/vboxtool
• Download; http://sourceforge.net/project/showfile ... _id=239993

I'm looking forward for any feedback from anyone who thinks this software is usefull.
Links:
- thread where the script was 'born': http://forums.virtualbox.org/viewtopic. ... 7624#37624
- direct view of the vbox-script: http://vboxtool.svn.sourceforge.net/vie ... iew=markup

[frank]

Please can you explain the difference to VBoxManage?

[markba]

Please can you explain the difference to VBoxManage?

It's a actually a wrapper around VBoxManage but it's doing much more...

With the script, using several functions of VBoxManage, one can iterate over all registered sessions to mass start, save, stop, backup, configure, all in one command. Some runtime data like cpu load and memory usage are recorded and shown.

Keywords are: mass operation and configuration.

[markba]

I've added some examples in the thread start to give an idea what VboxTool currently can do and what it's value is above VBoxManage.

[sej7278]

whats the problem with virt-manager then, are the dev's being anal about licensing or something?

seems a shame to have a standard package for this sort of thing and not add virtualbox to the list. that said i never liked virt-manager when i tried it with kvm/xen.

i wonder if your tool could be merged back into virtualbox - maybe as a new version of vboxmanage.....

[markba]

I do not know what's exactly the problem with virt-manager. I created a feature request to include vbox in to virt-manager.

This is what came back:

We might consider that in the future. However, my experience with virt-manager isn't exactly positive (crashes 50 times per day in OpenSuse? 10.3).

http://www.virtualbox.org/ticket/1019

As I have right now a problem with effective controlling sessions in a headless environment, I'm actually solving my (own) problem by creating VBoxTool. By releasing it as open source, maybe others can benefit from this.

[markba]

For those who are interested: version 0.2 of VBoxTool is released.

Changes:
- configurable port forwarding: no host interfacing needed!
- comment out lines in /etc/vbox/machines.conf with '#'

For port forwarding, here some background-info why this is usefull: http://vboxtool.sourceforge.net/portforwarding.html

Website: http://vboxtool.sourceforge.net/
Download: http://sourceforge.net/project/showfile ... _id=239993
Sourceforge: http://sourceforge.net/projects/vboxtool

[JshWright]

Wouldn't this be cleaner of an implementation of the COM API, rather than a wrapper for VBoxManage?

[markba]

Cleaner, yes; easy to implement, no. The wrapper method, provides fast results (solving my problem immediately) and it's very agnostic for kernel and other libs.

Another method could be through the new python API (introduced in vbox 2.x); right now, it is lacking documentation. But once it's documented, maybe it's a good idea to port the script to python, making it cross-platform (running on Windows also) as well.

[markba]

For those who are interested: version 0.3 of VBoxTool is released.

Changes:

- Autostart at host boot, autosave at host halt
- Compatibility break with 0.2: renamed main script 'vbox' to 'vboxtool', moved config folder from '/etc/vbox' to '/etc/vboxtool'

Benefits of autostart at boot, autosave at halt:

- Servers become self proficient. A server, hosting VirtualBox and running sessions in a production environment, can be rebooted without knowing all the intricate details of bringing down the individual sessions. Even when an unexpected down happened e.g. by a power surge, sessions come up when the machine is booted, even when it is done by unqualified personnel: pushing a power button is not that complicated I presume.
- Save time to access sessions on a desktop machine. When a session is automatically opened in the background at boot, it can be easily accessed by rdesktop or similar rdp-viewer, without any delay because the session is already up-and-running, waiting for anyone to access it.
- Be sure sessions are always saved at halt. When sessions are running, be it headless or with GUI, be it on a server or a desktop, it is sure all sessions will be saved when the machine is downed. Normally, sessions become in 'aborted' state when nothing is done as the machine is going down. Bringing sessions automatically into savestate saves time when these sessions are started again after the next boot because the sessions don't have to boot, but also prevents data loss.
http://vboxtool.sourceforge.net/autosta ... -halt.html

Website: http://vboxtool.sourceforge.net/
Download: http://sourceforge.net/project/showfile ... _id=239993
Sourceforge: http://sourceforge.net/projects/vboxtool

I'm looking forward for any feedback from anyone who thinks this software is usefull.

[piedoggie]

I'm having trouble getting vboxtool to work. I set up the machines.conf file to look like:

ceres,3400
pallas.3401
tpblue,3402
tpblue-dev.2008.05,3403

when I run show:

root@vesta:/etc/init.d# vboxtool show
tpblue-dev-2008-05 (vrdp=): aborted

any ideas? Also, is there any magic I need to do to get the shutdown sequence to cleanly take down a virtual machine?

[markba]

Have you created /etc/vboxtool/vboxtool.conf?

This should look like this:

Code: Select all

vbox_user='<user name>'

Replace <user name> with the name of the user under the which the sessions are created/running, in your case 'root'. Surround the name by quotes as indicated above.

You can first test your setup manually:

Code: Select all

# Starts all sessions in machines.conf with preconfiguration of VRDP-port
vboxtool autostart

# Show info of all registered vbox-sessions
vboxtool show

Note. To access vboxtool, it is not necessary to change directory to /etc/init.d. If installed following the installation guidelines, vboxtool should be placed in /usr/local/bin. This folder is in the search path, so vboxtool is accessible from anywhere.

[piedoggie]

Have you created /etc/vboxtool/vboxtool.conf?

This should look like this:

Code: Select all

vbox_user='<user name>'

Replace <user name> with the name of the user under the which the sessions are created/running, in your case 'root'. Surround the name by quotes as indicated above.

why should it be root? I currently start all of these virtual machines as 'esj'

[markba]

why should it be root? I currently start all of these virtual machines as 'esj'

Correct. It *should* not be root, but in his case, as he was logged in as root, the assumption is that he also runs the sessions as root. For VboxTool it is essential that the user who has installed the sessions (they are saved in the user's home folder), is also the user in /etc/vboxtool/vboxtool.conf.

It is not recommended though nor necessary to run sessions as root. It may be better for piedoggie to change this, but as VboxTool concerns, it doesn't really matter.

[piedoggie]

why should it be root? I currently start all of these virtual machines as 'esj'

Correct. It *should* not be root, but in his case, as he was logged in as
...
It is not recommended though nor necessary to run sessions as root. It may be better for piedoggie to change this, but as VboxTool concerns, it doesn't really matter.

now I understand the root confusion. In the example I gave yes, I was running as root because I was trying to discern whether or not it made a difference. As you point out, it doesn't so I don't (run virtual machines as root)