Remote Virtual Windows
Update: this information relates to the use of the virtualisation software KVM as it stood in around 2007. Currently, the VirtualBox virtualisation software (at version 4.x) provides support for access to this kind of configuration almost entirely via mouse-click, so you are probably better off trying to use VirtualBox for this task, instead.
Here is some information on setting up Windows XP as a virtual operating system on your Ubuntu system at 'work' so that it can be accessed remotely via VNC from 'home'.
Why would you want to do that? (1) you only have one licensed copy of Windows and (2) you normally run Linux for whatever reason, you only have one work machine, and you don't want to have to shutdown your work machine just so that you can access Windows from home via VNC or RDP. It might also be that you want to run a Buildbot for Windows, but you don't have spare machine available, as was my case.
What do you need? Your 'work' system needs to be a fairly recent and fairly fast machine with probably at least 1GB but more likely 2GB+ of RAM. In order to run KVM on it, you will need a recent 'Core Duo 2' or 'Xeon' processor or the AMD equivalent.
How well does it work? With Core Duo 2 2.1 GHz 2 GB RAM system at 'work' and a tired old P4 2.4 GHz running Fedora 7 via a fairly slow ADSL connection at 'home', it worked very well, provided you can make use of TightVNC to provide compression of the transmitted Windows session. This method doesn't tie up the machine at work, either: it doesn't need to be booted into windows, and it can be used by other users for other things, serving up files or a website, etc. The virtual Windows system can be started and stopped remotely, and can stay running even if your home connection is a flakey.
If you do try this stuff out, please let me know with an email or some edits on this page!
Set up virtual Windows on your server
At work (or whereever your server is) we assume you are running Ubuntu. Follow the instructions there for setting up Windows XP as a Kernel Virtual Machine (KVM). Instructions for this part are here. This step takes a while, and will whirr your CD drive for a while, but is fairly straight forward provided you note the thing about pressing 'F5' at the appropriate moment.
While Windows is installing, make sure your Ubuntu machine has got sshd installed and make sure that port 22 is open on your firewall (eg Firestarter) if you are using one. Make sure you can access your machine from outside the office. You may need to set up a Dynamic DNS name if you don't have a static IP address on your work machine (information here)
Once Windows is installed via KVM, launch it localling using the 'kvm' command as outlined in the above instructions. Install TightVNC and set it up as a service (you will be asked for a password). Set TightVNC to accept connections to port 5900. You can turn off the HTTP feature.
In your virtual Windows system, open up the Windows firewall on port 5900 to allow VNC connections.
Starting up your virtual Windows system
You need to run your virtual Windows system from within the utility program called 'screen'. This allows you to start it remotely, and for it to keep running, even if you connection goes down.
From your home system, open an SSH connection to your work system and type 'screen'.
Once screen has loaded (it will show you some basic information before giving you a new shell prompt), type kvm -redir tcp:5909::5900 -smp 2 -vnc :8 -k en-us -usbdevice tablet -no-acpi -m 512 -cdrom /dev/cdrom .kvm/winxp0.img.
This will start your virtual Windows system, although you won't see anything yet, and the command won't complete. You have now got an (invisible) windows session running on your server. To access it, we are not going to use the VNC server provided by KVM/QEMU but instead we are going to connect to the *virtual* TightVNC server that we installed on the virtual machine.
Close the SSH connection you your work system by closing the terminal window. Because you ran 'kvm' from inside 'screen' it will continue running even after your SSH session has been closed.
Connect to your server with correct port forwarding
We'll assume your home system is Fedora 7. If it's Ubuntu or Windows or something else, you'll need to work out your own approach.
First, install TightVNC on your home system. On Fedora, you can just use the .rpm package from .
Next, set up TightVNC on your home system so that it uses the right compression methods by default, and set it so that it uses full-screen display. Assuming you are on Linux, you can set up your TightVNC settings for fullscreen use by editing/creating the file ~/.Xresources so that it contains:
! vncviewer Vncviewer*encodings: copyrect tight hextile zlib corre rre raw Vncviewer*fullScreen: True Vncviewer*grabKeyboard: True Vncviewer*compressLevel: 7 Vncviewer*qualityLevel: 3
You may need to load these settings explicitly by typing 'xrdb ~/.Xresources'.
Next, optionally, check that your home system has an SSH Private Key, and add you SSH Public Key to your office server:
- On your home system, type 'cat ~/.ssh/id_rsa.pub'.
- Then, copy that text to the end of the file '~/.ssh/authorized keys' on your office server.
Next, add a 'custom launcher' to your GNOME panel on your home system. Set the command to 'vncviewer -via email@example.com :9'. This will use an SSH tunnel to connect to your office machine on port 5909, which is the port that forwards through to your virtual Windows system.
TightVNC should now ask you for your VNC password. This is the password you set when installing TightVNC on your virtual Windows system.
After you have entered the password, Windows should show up in a full-screen view of your remote virtual Windows system. To exit from viewing the remote session, enter 'F8' then click 'Quit viewer'. You can re-launch vncviewer to get your virtual Windows system back again, as long as your SSH tunnel connection to the server is still open.
Shutting down virtual Windows
To shut down your virtual Windows system, just connect to it as above and shut it down as you would a 'real' Windows system. Then, open an SSH connection to your office system and type 'screen -r'. This should show up either (a) the still-running 'kvm' process or (b) some output, possibly saying 'Aborted (core dumped), along with a new command prompt. If KVM is still running, press ctrl-C. Virtual Windows is no longer running
Restarting your virtual Windows system
As for shutting down Virtual windows, open up your 'screen' session by typing 'screen -r' then re-run 'kvm' using the same command as last type (kvm -redir ...). As before, you can close the SSH session once you have started kvm.
The only security issue here is that you have opened up your 'work' machine to SSH connections. SSH connections are always encrypted and are secure providing your passwords are secure. If you want to improve security, consider setting your firewall to only accept SSH connection from certain IP addresses or a range of IP addresses.