If you have a powerful primary machine (for instance a Dell notebook with an Intel Core i7 processor), it can easily run several Operating Systems and user sessions in / on them side by side – virtualisation is the magic of today’s computing.

The Raspberry Pi, whilst not having enough general purpose power to do really pleasant desktop computing, can very well serve as a “window” to Windows, Linux, MacOS and other more exotic systems running elsewhere. You could run several users off a powerful server machine – all you need is some networking gear, monitors, mice, keyboards, and of course Raspberry Pis.

Your users will enjoy an absolutely silent and energy-efficient client, while the noisy server is hidden away in the basement somewhere (or is in the admin’s room).

Access Windows from the Raspberry Pi

Today we will show you how to access a virtualised Windows desktop from the Raspberry Pi.

VirtualBox

On the host computer which will run the Operating Systems and user sessions for the Raspberry Pi terminals, you should install Oracle’s VirtualBox. (If you are not a fan of Oracle, remember that this was not developed by them but by SUN, and rebranded later on).

The host computer ideally should have hardware virtualisation extensions in the processor, which will allow the guest systems to run much more fluently.

We assume that you run Windows 7+ on the host. VirtualBox also works on Linux, though.

Run VirtualBox, and set up a Windows virtual machine (how to do this is outside the scope of this document).

Networking setup

Here’s the important part to know: initially the virtual network adapters for your virtual machine are set up as “NAT” devices. To be able to access RDP and all other parts freely on your network, the network adapter should be set up as “Bridged Adapter”.

This will connect it directly to your network – the machine will be seen outside of the host computer. If you have a DHCP server running, Windows by default will fetch it’s IP address from the DHCP server (e.g. your router).

To be able to access the virtual machine without looking up it’s address first, we recommend to assign a static IP for it ( outside of the area your DHCP server uses to assign IPs).

This is done by right-clicking on the network adapter in Windows, bringing up it’s properties, and editing the IPv4 properties. Whilst being mostly outside of the scope of this short how-to, I’ll share a screenshot with you, which should help you:

adjust your settings accordingly.

Note:

The current IP address of your windows computer can be determined by hitting the Windows key, writing “cmd”, pressing Enter (to bring up the command line), and the following command:

ipconfig

RDP Setup

This part can also be applied to physical machines running Windows.

To allow remote connections to your Windows machine, you have to enable RDP connections first. This is done by hitting the Windows menu, right-clicking on “Computer”, selecting the entry “Properties”.

In Windows 7, you have to click on “Remote settings” in the sidebar of the window which you will see. The dialogue which comes up, will allow you to configure RDP settings.

Select “allow connections from computers running any version of Remote Desktop (less secure)”. Click “OK”.

Creating new user

If you do not have a password protected user in your virtual Windows installation yet, you should set one up. You can either create an admin user or a regular Windows user. Using these credentials you will be able to connect to the machine later on. Of course you can also create a new password for the user you already have, if you have decided not to use a password initially.

Raspberry Pi

Start an X session:

startx

Launch the root shell (start menu > Other > X-Terminal as root (GKsu).

Update apt package cache (if you don’t have aptitude, use apt-get):

aptitude update

Install rdesktop package

aptitude install rdesktop

After rdesktop is installed, it is literally just one short command to connect to your virtual Windows desktop:

rdesktop 192.168.1.3

Just replace the IP address with the IP address of your Windows virtual box.

Rdesktop will start a window and allow you to log in to your Windows virtual box. You can click on “Other user” and insert your login credentials here. If another user is logged in at the main machine / via another terminal, Windows might request you to wait for 30 seconds so the other user might allow or disallow your connection.

If you want to launch a full-screen session, you can use the –f switch

rdesktop -f  192.168.1.3

Forwarding sound of the Windows machine to the Raspberry is also possible. Unfortunately it will sound horrible (choppy / barely understandable) – I am not sure what the reason is, as the Raspberry Pi processor is not maxed out (e.g. when streaming Web radio). The sound will sound the same over HDMI and analog output (tested today).

rdesktop -r sound=local 192.168.1.3

Some further options will improve your experience:

rdesktop -z -x lan -P 192.168.1.3

These switches have the following meaning:

-z: enable compression

-x lan: set experience to “LAN” (will show desktop wallpaper, windows while moving them etc.)

-P: enable caching to disk (i.e. the Raspberry Pi’s disk)

Some screenshots

Experience

YouTube

YouTube will run, but very choppy – it will max out the Raspberry Pi’s processor. (This is a software problem – rdesktop is probably not using the efficient GPU of the Pi for processing). Sound quality is horrible, actually you can’t really understand it – it’s all chopped up. Sound quality will improve if you minimize YouTube (thereby limiting screen updates which are required, and lowering the load on the Raspberry processor). Sound will still sound choppy, though. All in all not good enough right now.

Sound

As mentioned above, sound quality (if forwarding sound) will be nearly unbearable. Maybe there are some better solutions (i.e. combining a sound streaming server which captures the sound and plays it back on the Pi).

The sound unfortunately will not improve if setting the Group Policy, and forcing sound quality to “high” on Windows. (use gpedit.msc)

Update

The sound problems seem to occur from buffer underruns on the Raspberry Pi side. (see below, xfreerdp).

Desktop experience

Especially with the optimised parameters (-z –x lan –P) the experience is really smooth. For word processing, spreadsheets and web browsing, you will be pleasantly surprised by the reaction speed.

Drawing & photo manipulation will be doable, but in a test with Paint, there was some slugginess.

Actually I see a huge potential in classical desktop / web application workspaces – where you don’t need multimedia, i.e. in a call center where people use web forms and interfaces to access your account with the company.

xfreerdp

xfreerdp is an alternative RDP client. You can install it using

aptitude install freerdp

And use it

xfreerdp -u Wanda -x l -z --plugin rdpsnd --data alsa -- 192.168.1.3

Please note the “x” in front of freerdp here.

This will connect with the user “Wanda”, enable LAN experience, enable compression (-z), and activate sound forwarding through the rdpsnd plugin. The two double dashes after “alsa” and before the IP of the host virtual machine ARE necessary.

Sound will still sound horrible – it will spew out a lot of “underrun occurred” messages on the console. We have tested different options to decrease load, increase latency, use the tsmf option, etc – nothing changed the horrible quality. Right now, the verdict stays the same: great for desktop computing, but not at all for multimedia applications.

There may be some improvement with the current GIT version of freerdp. We have not tested it yet.