My Delusional Dream

Virtualization of desktop operating systems is pretty commonplace for users of Linux and Mac OS. Initial implementations of desktop virtualization, such as VMWare 1.0, had the guest operating system running in complete isolation. Interaction was done through a custom application or network applications. There was no support for sharing files, sharing a clipboard, or merging the windowing environments.

Since then, virtualization has come a very long way. With VMWare and a supported guest operating system, the clipboards are the same, the mouse isn't locked to a window, and files are easily shared between operating system. Sadly, merging of windowing environments still isn't quite there. Your guest desktop still runs completely in a window on the host. VMWare has a new technique available in Fusion, their Mac product, called Unity that allows this. Parallels supports a similar feature called Cohesion, and I've been told that VirtualBox supports this feature too. This is a fine feature, if you have one of the newer products that supports this. If you're like me and still using VMWare Player, an older version of VMWare workstation, or connecting to remote windows systems with remote desktop, this isn't a native feature. Luckily, it's a pretty easy hack to get seamless windows.

Enter SeamlessRDP from Cendio. This little program extends the standard RDP system a little bit to provide for complete desktop integration when using rdesktop. It works in conjunction with rdesktop, so other tools such as tsclient won't work. Unfortunately, the directions for this aren't always the most clear, and they didn't work with my instance of VMWare, so here's how I managed to do it. These instructions are specific to Windows XP Pro.

1. First, go and download seamlessrdp.zip and extract it to something like c:\windows. There should be three files in there, the one that we really care about is seamlessrdpshell.exe.
2. Make sure that that you allow remote connections, go to control panel->system->remote and check "Allow users to remotely connect to this computer". At this point, you'll be able to test a remote desktop connection to your virtual machine through the command rdesktop REMOTESERVERIP. You'll notice that you're still running everything in still running a single window because we haven't invoked seamlessrdpshell yet.
   

   Enable "Allow users to remotely connect to this computer"
3. Enable welcome screen and fast user switching -- this is something that you normally don't see in enterprise deployments, but apparently it is necessary for this. I can't figure out how to make it work without this. Go to control panel->user accounts and check both of the options.
   

   Make sure both options are checked
4. Tell Explorer to not draw the desktop -- the reason is pretty simple, if explorer drew the desktop the window would still be full screen. We can change this by creating a new registry in My Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer. Call it NoDesktop, and make it a DWORD with a value of 1. This will keep explorer from drawing the desktop.
   

   Create a new DWORD registry entry called NoDesktop with a value of 1
5. Here comes some of the stranger stuff, that you may not need to do, but I found necessary for my system and it wasn't properly documented anywhere. In most cases, you can specify an application to run with the -s option to rdesktop, unfortunately, this doesn't work on my system. Instead, we'll need to use a rarely used program that allows you to set system level policies. Go to start->run and enter gpedit.msc. Select User Configuration->Administrative Templates->Windows Components->Terminal Services.
   

   Run gpedit.msc and navigate down to User Configuration->Administrative Templates->Windows Components->Terminal Services.
   Now, the crutch that we'll use to select "Start a program on connection". Double click and check the Enabled box and enter in c:\windows\seamlessrdpshell.exe c:\windows\explorer.exe. Click apply and then exit.
   

   Enter c:\windows\seamlessrdpshell.exe c:\windows\explorer.exe for the command to run on connection.
6. At this point, if you log out, everything should work, but the graphics may be a bit funny. In my experience I've found that there are two more small changes necessary before everything works nicely. First, make sure you're using the Windows XP appearance and not the classic appearance. Second, uncheck the option to keep the task bar on top, as this will cause issues when maximizing windows applications. And finally, you can't have another panel on the bottom or the start bar will try to redraw itself poorly, over and over.
   

   Uncheck the option to keep the taskbar on top
7. Now, all you need to do is make sure you're logged out of the virtual machine, and execute the following command: rdesktop -r sound:local -A REMOTESERVERIP:3389 -u "WINDOWSUSER" -p "WINDOWSPASSWORD". If everything goes well you should get a nice little windows start menu at the bottom of the screen and your windows apps will run seamlessly. It's not 100% perfect, but any sort of virtualization, especially a hack like this, never is. In particular, sloppy focus causes windows programs to jump to the front. But other things work great, like a shared clipboard and sound. It makes working in both worlds lots easier.

The final product

One of the major issues with utilizing a virtual machine for a server is that of time synchronization. VMWare normally has access to a real time clock handler that helps to synchronize time, but even that causes time to skew. This issue becomes more prominent with modern processors that support CPU frequency scaling. However, there are many cases where even the VMWare custom kernel module can't manage the time skew properly. Such was the case with my updated VMWare virtual machine -- to put it simply, time had stopped.

Looking around, it appears that some of the problem may be to the new tickless features in the linux kernel. Basically, this feature allows the system to stop waking up periodically if there is nothing to do. On desktop and laptop machines this saves a lot of power and is a key feature that has helped the OLPC be such a power miser. However, it also really screws with the clocks in virtual machines, and may be cause of other issues. I've also read that there are issues with heavy disk I/O and Gutsy in VMWare Server -- which is my virtualization platform of choice.

Previously, with the time issue, I would fix problems by adding in a cron job to periodically synchronize the date with a remote system. It's important to note, that ntp won't work because it tries to gradually synchronize the time -- so it will never catch up. However, using a cron job on the virtualized system relies on the virtualized system eventually hitting even minute marks. Last night in the course of 12 hours, my time advanced 32 seconds; cron is not an option. The solution is to have the host operating system, which can keep time, periodically SSH into the virtualized machine and synchronize the time. Getting started, you'll need to activate the time service in xinetd on the host operating system. Open up /etc/xinetd.d/time and change the lines that say

disable = yes

to say "no". Restart xinetd by running /etc/init.d/xinetd restart and you'll now be able to rdate to your host machine.

The next step is to create the ssh key and setup the cron job to connect to guest operating system. These commands should do it for you. Hit enter to leave it without a passphrase. Then, copy the key to the guest operating system.

root@host:~# ssh-keygen -t dsa -C "automated RDATE ssh key" -f id_dsa.rdate
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_dsa.rdate.
Your public key has been saved in id_dsa.rdate.pub.
The key fingerprint is:
d4:5f:01:83:ee:df:e0:e4:ea:ff:0a:6e:50:d1:e2:d3 automated RDATE ssh key
root@host:~# scp id_dsa.rdate.pub USERACCOUNT@GUEST:

Now that the key is on the guest, it's time to enable a passwordless login. First, login to the guest machine, and open up a root shell using sudo -s. Then run the following command to add the new key to your ~/root/.ssh/authorized_keys.

echo 'command="rdate -s HOST"' $(cat id_dsa.rdate.pub) >> ~root/.ssh/authorized_keys

The final step is to edit your /etc/crontab on your host system, and make the time synchronization happen every five minutes or so.

*/5 * * * * root ssh -i ~root/.ssh/id_dsa.rdate root@GUEST "rdate -s HOST"

Now, you should have a nice infrastructure set up where your VMWare virtual machine will never be more than five minutes away from the actual time. It's important to note that there are a few alternative ways of doing this. For example, one could bypass the usage of rdate entirely through some clever shell scripting that passes the time on the host system to the time command on the remote system. In my experience, this works in a homogeneous environment, but not every system can interpret times in the same way, so sticking with rdate seems like a good compromise.

To my loyal reader (or perhaps readers, who knows) -- you probably noticed some issued with the accessibility of this site over the past few days. It seems like two different things were conspiring to take down my site. The first is that my uplink connection has been a little flunky -- I've got a WRT54Gv1 that I use for my net access and that's been acting really strange. The second is that my server, scissors has been acting a bit flunky. Before I go too far, a little description of the box is necessary.

The machine is a circa 1997 AMD K6-200 with 96MB of RAM and Quantum Fireball 4.3GB hard disk -- this was pretty hot stuff when I went to college in 1997. Yes, that's right, it's my first computer from undergraduate. The machine first started to have problems in the fall of 1999. At the time I thought it was disk issues, so I bought a new disk. That didn't fix the problems, in fact, I think I threw out at perfectly good 8GB disk at the time because of the issues. Really, it was just problem with the IDE cables in the machine, but I digress. That year I was working more or less full time and going to school, so I had money to burn. I plunked down some cash for an Athlon 700 machine, and that machine became my backup server machine (replacting a Pentium 60). This is also where the machine got the name scissors, for scissors.dtd.iit.edu. I used some of the original parts in my newer machines, this left scissors with a black and with text only video card, and a couple of ISA ethernet cards (at least they're 3com). Yup, 10mbps is the max ethernet rate on the machine.

This point was also the first time that I installed OpenBSD on it. I believe it was OpenBSD version 2.5 or thereabouts - I actually paid for the CDs and have them laying around. Since then, the machine has been upgraded to newer operating systems twice, first to OpenBSD 2.9, then again to OpenBSD 3.3. It's served as a mail server, online game server, and most importantly my personal web server for the last few years. At some point, probably in early 2003 the fan on the CPU died, but it didn't seem to affect performance, so I didn't care. At some point later the fan on the power supply died -- once again it didn't seem to affect performance so I didn't care. I now had a basically entirely silent machine. Cool. As an added bonus, according to my Kill-a-watt device, it sips power at a consumption of 33 watts. This makes it nice and affordable to run.

However, the machine is now approaching it's ninth birthday. It's had a good run -- but all good things must come to an end. I've been getting rid of my old stuff and well scissors, it's time for you to go. You've been replaced by the forward marching tide of technology. However, it's a real pain to reinstall web servers all the time. My solution? Virtualization.

Thanks to VMWare Server and my copy of VMWare Workstation, I've created a very nice little OpenBSD virtual machine. Best of all, I've got all the services that previously were running between a couple of different servers consolidated onto this single box. That means this virtual machine now acts as my trac, subversion, dav, and person web server.

Virtualization has quite a few benefits. One of the biggest ones is that I can just copy the virtual machine from one physical computer to another. This makes upgrades a breeze. (As an aside, it also makes me wonder why I don't just install VMWare Server on my MythTV box in the living room and drop down to a single computer that is on 24/7. Probably has something to do with the printer we never use I guess.) Also, being virtualized, it let's me test other configuration changes easier. I can take a snapshot of the server in workstation and try an upgrade or change in software with no risk to the live machine. The VMWare Server console lets me manage everything from my laptop too. Wow.

I know that someone out there will believe that I'm a sellout because VMWare is closed source. Which is probably partially true. However, I've been using VMWare since it first came out. Back at LEC Ltd, we used VMWare on the developer workstations to see how the web pages would look on different platforms. Of course, we never thought about using it for server use -- but now it seems that's what the cool kids are doing. An astute reader might wonder why I didn't choose Xen or QEMU. With regards to Xen, I've heard that Theo considers Xen to be more of a toy, however he might be coming around to it (this was a year or more ago now). I did notice that there is a Summer of Code request to make OpenBSD a native Guest OS. That might be really interesting, but it's not here yet. For QEMU, the big issue is that if you want native performance you need to the unfree accelerator program. That, and it's not as feature rich as VMWare. Given that I have extensive VMWare experience too, it seemed like this was the fastest way to get running again.

So what is all this saying? Basically, if you're reading this weblog entry you're connected to my VMWare server instance, now called "donkey" running OpenBSD 3.9. Well, if this post is recent that's what happening. In the future I should be able to upgrade pretty easy. For now, the host machine for Donkey is a Pentium 3/900 with 640MB of RAM. So far, so good. I took extensive notes about the whole process and will be putting together a nice writeup soon. If you've got questions about the process, feel free to email me in the mean time.