Okay, I figured out how to run a vmware virtual machine on Linux without a physical display. Why would you want to do such a thing you ask? For instance, you might want to run a machine for remote access, with PCAnywhere.

To run an X program without a physical screen, you need a virtual frame buffer driver. Fortunately, XFree-86 comes with one: Xvfb. You also need to make sure that vmware doesn't complain about a variety of things that it usually complains about when you connect to a "remote" machine. For this reason, start vmware first over a remote session (I did so from my Windows workstation, on which I have X-Win32 installed) and click all the clickables to get it to no longer display those warnings. While you are at it, you might also want to make sure that devices like the floppy, CD-ROM, or sound card start disconnected. Oh, and make sure your virtual disk is non-persistent or undoable; since there's no way to "nicely" shut down a virtual machine that you cannot interact with, this is essential!

With all these preliminaries done, you can start the virtual frame buffer and the virtual machine as follows:

Xvfb :1 -screen 0 1280x1024x16 &
vmware -x vms/W98_PCAW/win98.cfg -- -display &

The name of the configuration file may differ of course.

If you did this right, you should now be able to connect to your virtual system over the network, e.g., with a PCAnywhere session. (You did test that PCAnywhere is properly installed in the virtual machine, right?)

A few weeks after I figured out this part, I managed to also figure out how to remote control the virtual framebuffer desktop. As it turned out, I already had all the tools at my disposal: krfb and krdc, the KDE remote desktop management suite.

The program krfb lets you remote control the desktop on which it runs. So, if I want to remote control the virtual desktop that runs on, say,, I'd start it with the following command line:

krfb --display &

But wait, that's not enough! If you run krfb interactively, you'll see that it's rather paranoid (and rightfully so!) about deciding what connections to permit. Indeed, I found no interactive means to change it to permit incoming connections while requiring no intervention from the desktop user. Fortunately, all this can be set in its configuration file, which is located in ~/.kde/share/config/krfbrc:


Careful: If you enable these settings on a computer that's on the Internet, the entire world will be able to control your desktop, so long as they have your password. Selective control via a firewall is essential. (You could also use uninvitedPasswordCrypted instead of uninvitedPassword for slightly better security, but I have not yet figured out how to set uninvitedPasswordCrypted to a meaningful value.)

With these configuration settings, you can start krfb and you can then connect to it using krdc running either on the same computer or on another machine:

krdc -h

It may not be obvious that the :0 part in this case is not the identifier of the X desktop that you are trying to connect to, but rather, the identifier of the VNC session. In other words, the :1 in the krfb command line and the :0 here are not a typo.

My last problem was that krfb plopped up a window in the middle of the screen and since I had no window manager running in my virtual frame buffer, there was no way to remove it. Fortunately, the solution was easier than I thought: killing the krfb window is possible without losing your krfb session! Indeed, the krfb window conveniently provides a Close button. It so happened that due to geometry problems, the Close button was not in fact visible in the krfb window in my virtual frame buffer, but it being the default button, simply hitting Enter did the trick.