We suppose this situation: we have a virtualized server (it doesn’t matter if it’s linux, Windows, Solaris,…), must run every time you start the system and must also consume less resources as possible.

The solution seems simple. VirtualBox brings commands: vboxsdl and vboxheadless. Both allow to run a virtual machine without open virtual machines manager.

vboxsdl run the virtualized system in a window graphical interface, in fact is the same as running the system from the virtual machines manager, but if we call it directly, we avoid having to resort to this.

vboxsdl -startvm "VM_NAME"

vboxheadless run virtualised system, but without raising any graphical interface, making it possible to boot only with the console. This is especially useful for servers that dispenses with the Xserver.

vboxheadless -startvm "VM_NAME"

If we can not see the virtual machine, how would you control?

Here I have a couple of tips used in Windows XP as host, Windows 2000 Server as guest, but the same should be applied in a Linux and other systems.

Setting up a virtual machine with remote desktop

If someone has occupied the guest additions, using a remote desktop is something similar. First, we must enable the remote desktop to the VM, the manager of VirtualBox virtual machines:

Tip: change the default port, especially on windows, because the Remote Desktop Service reserves the use of the port by default. If we have more than one virtual machine, then you should also have each their own port. In my case, leave it to port 1000.

Then with the same client for Windows Remote Desktop (Start -> All Programs -> Accessories-> Remote Desktop Connection), we can connect to the VirtualBox server, using as host localhost: 1000.

Kubuntu brings krdc client, who should do the same thing (I have not tested yet).

Tweak for Windows as host: start the VM without showing the cmd console

There is only a small great discomfort. Just wanted to avoid any window on the taskbar, running the VM in the background, but the cmd console shown anyway.

There are several ways to execute a command “in the background” in Windows, but the more complex is to use parameters of the WinAPI in source code. It is therefore not a viable solution.

The only solution I’ve found up to the minute, is to use a combination of a batch file (.bat) with a vbscript (.vbs) that can be run from the desktop.

vboxsart.bat:

"C:\Archivos de programa\Sun\xVM VirtualBox\VBoxHeadless.exe" -startvm "NOMBRE_DE_MAQUINA_VIRTUAL"

(modify the path to vboxheadless if necessary)

In the same directory, create vboxstart.vbs:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & "vboxstart.bat" & Chr(34), 0
Set WshShell = Nothing

Finally, create a shortcut and move it to Start-> All Programs -> Start, or any other form of boot commands to boot windows, would be ready.

Fortunately on Linux is much easier to start these commands, especially because we can create scripts as a service, or when we start a command from a launcher on the desktop, will not open any console window (default).

Another tip

Windows 2000 Server has a skill. To log on is to press CTRL + ALT + DELETE. If we do, respond the keyboard shortcut of host Guest system. To avoid this, you can configure automatic logon to the guest system. It is generally advisable to avoid the use of keyboard shortcuts in virtual machines.

Just missing …

Well, something I have not researched yet, is how to create and configure the virtual machine console, without requiring the VirtualBox manager wizard. Surely it is very simple, so it is left as an exercise for the reader. Hint: RTFM.

Another detail that I needed, and could be serious, it’s like to send a signal off the virtual machine, in order to shutdown it safely. For now, I can only kill the process of the virtual machine (unsafe) or turning off the system through the guest remote desktop.

Just send me a link to a service script to start and stop a virtual machine on Archlinux.

Finally, I owe some tests on Kubuntu, until further notice.

First, I was informed late about the version that ran the server: SQL Server 7. Moreover, it is difficult to go any time to make room for any evidence, even worse to sit quiet coding. The first thing we tried long ago, was to make a backup of the entire database. Assuming Microsoft Management Studio would be enough to connect to the database and create new tables, has been the first thing I thought to do that day.

But as Murphy’s law is always, I found an uncomfortable message, saying Unable to connect to an earlier version of SQL Server lower to 2000 (ie, version 8). Because Management Studio is based on. NET, I doubted that my .NET application could connect. Later, I discovered that I was wrong, but at the time I had no alternative other than to evaluate more solutions.

So, during this phase of the evaluation of new solutions, we feel completely replicate the server to find out how to run everything. To do this, we get a copy of SQL Server 7. Unfortunately, I was unable to install over XP. Therefore, in addition we get a copy of Windows 2000 Server.

Saving my digital dark age

The first thing I thought, was to install Windows 2000 server on the machine we had for testing. But even if successful, would not work when I take the notebook out of the lab. ” also could not install the system at the notebook, because my partition is already in use for 2 operating systems.

Connecting to my digital dark age

The second test was to determine whether the application. NET was able to connect to SQL Server 7. Again thanks to @janitux who taught me this trick, I was able to make a connection from my Host Operating System (Windows XP and/or Kubuntu) to my Guest Operating System (Windows 2000 server) which runs SQL Server 7. To got it, you must create a port forwarding (same concept applies to a router). When I connect to a X port on my host machine, the request will go to the guest machine. Configuration is done in a console like this:

cd C:\"Archivos de Programa"\"Sun\"xVM VirtualBox"\
VBoxManage.exe setextradata "vmName" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/PORT_FORDWARD_NAME/HostPort" HOST_PORT
VBoxManage.exe setextradata "vmName" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/PORT_FORDWARD_NAME/GuestPort" VM_PORT
VBoxManage.exe setextradata "vmName" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/PORT_FORDWARD_NAME/Protocol" TCP
::
:::: done!

• vmName = My vitual Machine name
• PORT_FORDWARD_NAME = a name for redirect fordward (ie: http, ftp, myHttp, sql, …)
• HOST_PORT = port number to connect from host machine
• VM_PORT = port number to send request in guest machine

(When I have time, try the same on Linux)

After that, I connect to localhost: 1433 (default port for SQL Server) and go! It runs perfect .

Success!

Despite working with a proprietary platform, the solutions to various problems, went through the application of free software. No doubt a great success. : D