virtualbox.org

As tilte shown.

Create a batch file (CMD for NT and up) with the following in the same directory that the rest of the virtualbox files are in, then add it as a shortcut to the desktop. Substitute the (Ubuntu-Karmic) with the actual name of the VM. If it contains spaces then use "" Example:("Ubuntu Karmic")

Hi,
I use the following script: Note: "Ubuntu 9.10 Desktop" is my virtual machine name.
Regards

if you are looking for a solution in Windows environment, try the steps in this site http://virtualization.sysprobs.com/crea ... virtualbox

Thank you all very much!

Two notes:

- VirtualBox.exe --startvm "<VMName>" is the preferred way to start a VM, rather than use the VBoxManage command.

- If the VM name contains embedded space characters, then put double-quotes around it.

Tell me what VirtualBox version you are using and what OS your VM uses and I'll build a free shortcut icon for you!

MarkCranness wrote:- VirtualBox.exe --startvm "<VMName>" is the preferred way to start a VM, rather than use the VBoxManage command.

I have never had any problems and I always use VBoxManage. Why is virtualbox command prefered way?

VBoxManage --type GUI just calls VirtualBox.exe --startvm anyway, so you are cutting out some processing.

VBoxManage is a command line program, and so opens a command window for a short period while VirtualBox.exe runs and starts. That window is the reason for the '@echo off; cls; @exit' rhubarb whenever anyone suggests a BAT/CMD file to run a VM, which is not needed if calling VirtualBox.exe directly.

MarkCranness wrote:VBoxManage --type GUI just calls VirtualBox.exe --startvm anyway, so you are cutting out some processing.

That doesn't sound right to me. VirtualBox.exe is just a GUI front end for VBoxSVC, as VBoxManage is a CLI front end for it. I can't imagine why VBoxManage would call on the services of VirtualBox.exe - unless of course the "requested service" is a GUI.

VBoxManage gets VBoxSVC to open a new 'session' for the VM, and VBoxSVC runs VirtualBox.exe --startvm in response.

Too much detail!:
VBoxManage handles the startvm command using internal function handleStartVM:
http://www.virtualbox.org/browser/trunk ... 25275#L365

handleStartVM calls VirtualBox::OpenRemoteSession with the required session --type (default=gui):
http://www.virtualbox.org/browser/trunk ... 25275#L378

VirtualBox::OpenRemoteSession calls Machine::openRemoteSession (I think this is now running in VBoxSvc?):
http://www.virtualbox.org/browser/trunk ... 5275#L1843

Machine::openRemoteSession creates a command line with VirtualBox.exe and parameter --startvm:
http://www.virtualbox.org/browser/trunk ... 5275#L4669

Machine::openRemoteSession creates a new process with the given command line:
http://www.virtualbox.org/browser/trunk ... 5275#L4681

It still looks odd to me: have you enabled the remote display feature for this VM? I'm wondering what else a "remote session" might mean.

Bear in mind that the VirtualBox.exe process on the host can be closed once a VM is running, so it simply cannot be responsible for controlling any important service required by a running VM, at most it only starts those services, which are presumably controlled by VBoxSVC. VBoxManage could presumably start those services too, which is why I find it odd that VBoxManage needs the GUI for anything.

In Windows only.
VirtualBox.exe is the GUI frontend and VBoxManage.exe is the CLI frontend.
Either one can start the VM. The problem is if you call the startvm from a command window and want the command window to go away without killing the VM you had to use VirtualBox.exe and run it as a batch statement. Now this may have changed which could be causing this confusion, but that is the way it used to be.

Perryg wrote:VirtualBox.exe is the GUI frontend and VBoxManage.exe is the CLI frontend.
Either one can start the VM. The problem is if you call the startvm from a command window and want the command window to go away without killing the VM you had to use VirtualBox.exe and run it as a batch statement.

Since both VirtualBox.exe and VBoxManage.exe are just front ends for VBoxSVC, and since VBoxSVC runs independantly of the command prompt, I would expect to be able to kick off a VM using "VBoxManage startvm x", and be able to close the command prompt window after the VM starts...

...and in fact I just tried it, and it did exactly what I expected it to (the command window closed when I typed "exit", the VM continued running). This experiment was done at work, where I'm still running VBox 3.0.8.


And for my next trick I tried doing exactly the same thing again, but this time I renamed "VirtualBox.exe" to prevent VBoxManage.exe from being able to find it. This time, and contrary to my expectations, the VM failed to start: I got an error message relating to the OpenRemoteSession() API that Mark mentioned a few messages back.

That is what I expected to happen. I do not know when the actual condition changed but back in the V2.x days the command window had to stay open if you started it from CLI using VBoxManage.exe and if you closed it (the command window) the vm would also shutdown and show as aborted. I am sure things have changed drastically since then but since the old structure still works I use what I have been using.

VirtualBox::OpenRemoteSession is what is always called: it's not dependent upon startup type or anything, I suppose that's just what Innotech decided to name the function.

If you look in Task Manager (or better yet Sysinternals Process Explorer) you will see one VirtualBox.exe for the GUI (if it is still open) and one for each running VM. Process Explorer even shows them running as child processes of VBoxSVC (because they were launched from VBoxSVC).

So I'm sure that VirtualBox.exe has two functions / does double duty:
1) The GUI we see,
2) A host window for a running VM.