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

(*) Talla (español chilensis): dícese de broma o humorada

Al intentar instalarla, recibí el mensaje de que requería que estuviera instalado “Microsoft .NET Framework 2.0 SP2″. ¿Qué? ¿Pero, no tengo instalado el 3.5, el cual me instaló el mismo Visual Studio 2008 Express?

El mensaje de error decía claramente que debía bajarlo desde www.microsoft.com/net.

Bueno… intenté buscar el dichoso paquete. Baje al menos 3, con el mismo resultado. Entonces se me ocurrió buscar literalmente el nombre de lo que me pedía. Obviamente el Live Search integrado en microsoft.com no me sirvió de nada. Le consulte a Google.

Y entre los resultados, encontré este post en los foros de msdn. En él encontré una respuesta al problema, pero con una de las excusas estúpidas, típicas de los ingenierillos de microsoft:

SQL Server Express Edition 2008 requires .NET 2.0 SP2, however you cannot download only .NET 2.0 SP2. It comes bundled with .NET 3.5 SP1. You can find .NET 3.5 SP1 here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en

Sorry for the confusion.

Regards.

Jeff Papiez

Test Lead, SQL Server Management Services Team

Microsoft Corp.

Simplemente vergonzoso.

Una de las cosas que me ha llevado a considerar a Windows como una basura, es que NO TIENE un sistema consistente para administrar el software instalado. Si alguien a tenido problemas de dependencias instalando un .rpm, en windows es muchísimo peor, debido a que al menos, el .rpm te dice de que otros paquetes depende, y por último, en ahora existen sistemas bastante buenos que administran los árboles de dependencias.

En cambio, en windows, cada aplicación “no sabe” o “no puede saber” de una manera centralizada, si otra aplicación o biblioteca ya esta instalada y a que versión corresponde, para calcular si las cosas son compatibles o no. Cada aplicación debe preocuparse de tener sus propios métodos de detección de aplicación o librerías preinstaladas.

Otro problema grave, es que también cada aplicación es responsable de mantenerse actualizada, por lo tanto, es un problema tremendo mantener todas las aplicaciones actualizadas a la vez, y además, que mantengan compatibilidad.

Y no me vengan con la excusa de que la mayoría del software que uno instala en windows es de terceros, porque en Kubuntu tengo un montón de repositorios de terceros (privativos y libres), siendo las aplicaciones perfectamente consistentes entre sí. Cuando no lo son, el mismo apt se encarga de decir cual es el problema y generalmente propone alguna solución alternativa (desinstalar un paquete, actualizar otro, reemplazarlo, etc.).

No he visto en ninguna noticia relacionada a Windows 7 (y en su tiempo tampoco a Windows Longhorn/Vista) respecto a este problema, lo cual me parece pésimo de parte de los responsables del sistema inoperativo más extendido del planeta. Por lo menos, leí algo sobre esfuerzos en modularizar lo más posible el sistema, pero de ahí a que tenga un sistema de instalación de paquetes decente (un .msi no cabe en esta categoría), tal vez sea el tiempo de un Windows 9, 12, que se yo…

Buscando encontré este hilo de discusión en sus propios foros.

Como mencionan, la última actualización corrompe la base de datos local de los marcadores.

La solución es bajar una versión anterior de la extensión (dicen que hasta la 2.0.72 funciona bien) o una versión testing que está disponible en un grupo de yahoo.

El problema con esto último es que es necesario tener una cuenta yahoo y entrar al grupo. Por suerte se puede dejar más tarde. Pero mientras tanto estuve dentro, copie el link directo al archivo la extensión.

Ojala les sea de ayuda a los usuarios de delicious toolbar .

Update, guarde la copia y la subi acá.