Since I first encountered VirtualBox, I tried to figure out a way to make my virtual machines start at boot-time *without* a user having to log on to the host-system and - furthermore - to *safely* shut them down again, in the event of a system-shutdown or a reboot.

Browsing the forums for quite a while, I found that many other users were asking for a solution to do the exact same thing.

So here it is now. It's still dirty. It's heavily patched. But it does the trick! Introducing:

VBoxVmService(Release: 20080223, initial)

This is the current list of features:

* start your virtual machines from a native windows service at boot time

* safely shut down your serviced VMs when the host system is shut down or rebooted

* no need for a user to be logged on to the host system at any time

* configuration through a simple ".INI" file

* control up to 127 virtual machines with a single service instance

* parallel installation of multiple service instances makes it possible to run one VM per service or to group VMs within service instances

* register additional VMs with a service instance even during runtime

* supporting console tools to control (startup / shutdown) single VMs that have been (bulk-) started or stopped by the service

VBoxVmService can be downloaded from rapidshare (until I get a project page online).

It is written in C++ and supplies a set of supporting tools and scripts. It comes bundled with installation and operation instructions and a sample configuration file.

Any help on its improvement by C++ Developers, Batch-File-Gurus, or just about anyone would be deeply appreciated.

Cheers, Matt

[Edit] Since there is no project page (yet), I will frequently check this thread for any questions, problems, suggestions or other support issues. So this thread could be considered the project's homepage until further notice.[/url][/b]

The way I see VirtualBox auto-start on boot working:
1. After you start Windows, your normal user starts...
2. (XP host) Start->Accessories->System tools->Scheduled tasks
3. You make a new user: "VBoxUser" with admin privileges.
4. You write a script (*.bat) that starts VirtualBox and your VMs.
5. "Scheduled tasks" should auto-start VBox with different user "VBoxUser", with admin privileges.
--NOTE: This is possible, if you supply "VBoxUser"'s password to Scheduled Tasks.

But my solution is not professional, and it's hacky, unlike yours.

Anyway - I would like to see your solution integrated better with official VirtualBox package, rather being a third-party, separate install add-on.

Technologov wrote:Two ideas:1. Why do you use softlinks ? This is problematic, because it is a dependency on M$ add-on stuff.

Windows OS - NTFS has hardlinks, that are built-in into the OS.See Windows Help: "Fsutil: hardlink"Maybe "junctions" are nice, but it should be kept optional.

I know about hardlinks. Truth is, I am working on a hardlinker myself at the moment but my tool ("linx") is just not yet ready for deployment (since it installs the hardlinks correctly, but crashes trying to remove them again). I didn't want the users to be stuck with a hardlink and not having an included solution to remove it again. So I chose to go for linkd in the first release. I will definitely rid the two M$ components (sleep/linkd) as soon as I have time to finish my replacement apps.

Technologov wrote:2. Why use VRDP ?This is problematic, because it is a dependency on Proprietary VirtualBox stuff, and cannot be used with VirtualBox Open-Source Edition (OSE).

Ok, I didn't know that, since I never tried the OSE. What does the OSE use instead of VRDP then? It should be no problem to install a config option on which technology to use for the startup and shutdown, but I will need some input here.

Technologov wrote:I believe, that after the guest OS has been installed and configured, it can be accessed via virtual Serial COM/virtual Ethernet network. VRDP is nice but it should be kept optional.

You are definitely correct on the possibilities of accessing pproperly configured VMs with e.g. SSH or some similar technology. The reason I chose VRDP was, that is has a lower memory footprint (since it is a headless server, with no output on the server machine whatsoever).

Good suggestions. I will put some thinking into that (and already have , as you can see in my answers). As soon as I got all the infos on OSE's alternatives to the proprietaries of VirtualBox, I will implement a config-option in the .INI file, enabling the user to set up the desired technology used to run the VMs...

It can only draw GUI locally via SDL library. And VMs can be controlled from command-line.

This means, that Guest VMs need to be pre-installed "normally", having network and/or Serial connection configured, so people can enter VMs using those measures, and if something goes wrong, people will need to use command-line to restart the VMs.

It can only draw GUI locally via SDL library. And VMs can be controlled from command-line.

This means, that Guest VMs need to be pre-installed "normally", having network and/or Serial connection configured, so people can enter VMs using those measures, and if something goes wrong, people will need to use command-line to restart the VMs.

Ok, so the option would be, whether to use SDL or VRDP and - in the case of SDL - to redirect the visual output to a windows desktop that is not accessable by the user... Ok, should be no problem. I will see to implement the corresponding switch maybe later this afternoon or tomorrow to regain independency of the proprietary distribution...

I have been doing some tryouts yesterday. it seems that VBoxSDL is somehow directly accessing the Graphicscard. I always ended up having at least the outline of the SDL window visible on my user's desktop and experiencing some graphical errors, even though I redirected the output to another (invisible) desktop. It seems, I will have to put some more effort into that. It would be great to get in touch with the actual developers of SDL, to think about implementing a true headless mode within the application and maybe instead sending out the textual boot messages via some virtual guest to host "pseudo-serial" or whatever socket connection to get at least a little feedback, what is going on with guest-os...

next steps: integrate VBoxVmService with the runserv features into one comprehensive service with a more efficient process handling and to avoid software fragmentation into so many parts. i already adjusted the docs to rid rlink (M$) from the distro and wrote my own "sleep.exe", not to be dependant on the second M$-component any longer.

so there is more things to come along. and there should be at least a minor update released by the end of next week. for now, i will give the community a little time to check out the software as it is ,to gather some more ideas and suggestions and maybe to gain some interest from the virtualbox development team to discuss a tighter integration.