Windows 7 64 bit on PPC OS XIf this picture doesn’t make sense, it’s my 32-bit PPC Mac running near-native speeds on an Intel virtual machine of Windows 7 Professional 64-bit through the Internet. If the reason or the methodology isn’t apparent, read on.

Here’s your problem (or maybe you have something similar): you’re a committed Linux/UNIX/Mac user that doesn’t do Windows. You decide to get a computer science degree online, only to discover that not only is their curriculum Windows-centric, but so are their learning resources. Maybe you can figure out some resources so that you can get around this, but when it comes to being away from home and you want to use your non-Intel laptop to do some studying, no luck, right?

Wrong.

I originally believed that there was no hope for my PPC-based PowerBook. Especially for running Windows 7 (the core of Western Governors University‘s so-called Operating Systems class) in its 64-bit version.

Debian x86 running on PPC OS XI tried to do some hardware virtualization (Intel x86) via Bochs which worked to install a Debian Linux with Fluxbox (a very lightweight window manager) but it was slow as all get out. Check out top (running on the PowerBook, not the virtual Debian machine) in the picture and you’ll see a good lot of the resources are being sucked up by the virtualization process. Running XP would have been ridiculous. Running Windows 7 would have been pretty much beyond all reason.

To make matters worse, LabSim, the major learning resource for the class, required Microsoft’s SilverLight— and the most recent version of it, which is not available for any non-Intel processor.

In the meanwhile, we got an Intel iMac which made running LabSim easy. It also made running any version of Windows cake via VirtualBox (without the need for resource-intensive hardware virtualization). It was also nice to have it sandboxed. If something went wrong with the machine, it wasn’t something wrong with my actual machine. I could delete the virtual machine file and make a new one. Or I could take snapshots of the virtual machine state and restore to an earlier one. Back to the subject at hand, I was able to connect to the machine remotely (tunneling Virtual Network Computing through Secure SHell) and do what I needed that way. It was still darn slow, though.

The other day I was reading the VirtualBox manual and discovered VBoxHeadless which can be used to start a virtual machine and then essentially forward it through a Remote Desktop Protocol connection. And if we use some smarts we can do it securely with SSH. Here’s how:

  1. Load up your favorite command line interface and run ssh <username>@<IP address> -C -L3389:127.0.0.1:3389 which will tunnel your RDP connection through SSH with compression on. Username will need to be the user that created the virtual machines. IP address can be local (in which case the rest isn’t even necessary since you won’t be going through your router) or external. In the case of the latter option, you can find it out via checkip.dyndns.org. I would recommend their free dynamic DNS service to set up an easy to remember address if you’re going to do this often and you have a dynamic IP address (if you don’t know, you probably do) as you can configure your machine and even your router to keep track of it and update it accordingly.
  2. Start your virtual machine with VBoxHeadless –startvm “<virtual machine name>” (if you don’t know your virtual machine name, run VBoxManage list vms)
  3. Run rdesktop or your favorite wrapper for it (I like CoRD on OS X), pointing it at 127.0.0.1. This will try to connect to port 3389 on your machine which will tunnel it through SSH to port 3389 on your remote connection. Note that if you’re using a local address and you didn’t use the “-C -L3389:127.0.0.1:3389” stuff, you should just specify the local address and not 127.0.0.1.
  4. Enjoy!

There are many more options and settings by the way. Read the manual here.

The only drawback to this is that you don’t have access to all the usual features of the virtual machine (like loading new “CDs,” taking snapshots, etc.). That being said, it would probably be in your best interest to shut down the machine when you’re done rather than saving the state, which you can’t do. Killing the rdesktop process won’t do anything to the state of the machine.

However, when you go back to your SSH connection, VBoxHeadless will still be running. If you kill the process (Control-C) then it’s effectively the same as pulling the plug on your virtual machine. Windows won’t be liking that.

Advertisements