[VBoxVmService] -> Discussion & Support

[mattz]

This is the thread for VBoxVmService related discussion and support requests.
Any announcements and infos will be made public here: http://forums.virtualbox.org/viewtopic.php?t=8595


-----------------------------------------------------------------------------------
[EDIT]

A detailed step-by-step walkthrough that explains the installation and setup process can be found here:

http://forums.virtualbox.org/viewtopic.php?t=4762&postdays=0&postorder=asc&start=56

-----------------------------------------------------------------------------------

Hello everyone!

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).

DOWNLOAD (5.7 MB): http://rapidshare.com/files/94156546/vms_rel20080223.zip

[UPDATE] Rapidshare downloading has been taken down.
Please check this posting for current download details:
http://forums.virtualbox.org/viewtopic.php?p=17262#17262


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]

[swish]

5.7MB???
Include what ?

[Technologov]

Very nice effort indeed !

Actually I wrote few possible ideas:
http://www.virtualbox.org/ticket/767

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

[Technologov]

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.

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).

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.

In short: Please do not introduce unnecessary dependencies.

-Technologov

[mattz]

5.7MB???
Include what ?

read the 1st post carefully. all you get is mentioned there.
the sources of the service (c++) and the tools (batch) are included the package.

[mattz]

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.

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.

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).

In short: Please do not introduce unnecessary dependencies.

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...


matt

[mattz]

btw: anyone caring for a system tray application to interact with the vms that are controlled by the service? i have been thinking, this might be a nice feature to have...

matt

[mattz]

Very nice effort indeed !
...

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.

well, i guess this is up to the projectmanagers to decide. i am open for any approach from this side. until then, i will set up a sourceforge project for VBoxVmService to have a proper home.

[Technologov]

VirtualBox OSE doesn't have any remote GUI capabilities.

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.

-Technologov

[mattz]

VirtualBox OSE doesn't have any remote GUI capabilities.

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...

[Technologov]

There were discussions about "Headless VirtualBox", i.e. that doesn't render GUI at all, like Qemu's "-nographic" option. But AFAIK there is no implementation.

[mattz]

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.

so please everybody, test the package and post your feedback here!

cheers, matt

[Technologov]

mattz: I suggest you to announce it on vbox-devel - development mailing-list.

-and-

Open a features request to integrate your solution into VirtualBox package.

[mattz]

good point. i will see to it, as soon as i find the time.

stay tuned...

matt

[Eagle Creek]

Very very nice!!
Although I'm not going to use it right now I see a lot of possibilities.