Windows 7: Choosing a Multiple Desktop Program

One advantage of using two computers was that I could get stuck at a certain point, for whatever reason due to the computer's imperfections or my own, and just switch right over to the other machine for a while.  I suspected that this advantage could be multiplied by effective use of multiple desktop software.  This post describes my early Windows 7 efforts along those lines.

I had used multiple desktops in Ubuntu, where that feature was part of the standard package.  I had previously looked into multiple desktop software for Windows as well, particularly VirtuaWin, as a portable solution.  (Portables, at their best, could be incorporated into my network-shared, customized Start Menu, all of which could be copied onto a USB drive.)  My question, at this point, was whether Windows 7 supported good software, preferably but not necessarily free, that would give me multiple desktops.

In Ubuntu-land, I had used virtual machines (VMs) to encapsulate a whole workspace.  In one VM, I might have several different kinds of documents and utilities open, all pertaining to the project underway there.  Projects could take a long time, and could entail many interruptions.  Being able to zip all of that up into one pod was helpful for keeping multiple projects organized and ready to resume.  This, especially, was what I would ideally get from Win7 workspaces, though admittedly this went beyond what I had experienced in the desktops of Ubuntu itself (as distinct from VMware, running on Ubuntu).

(By the way, if you're reading these posts, please feel free to add a note now and then.  A bit of encouragement, commentary, or even constructive criticism enhances the sense that some find this effort helpful.)

After some searching around, it seemed that the multiple desktop solutions I was hearing most about were Dexpot, VirtuaWin, and Microsoft's Sysinternals Desktops, probably in that order.  A search led to a site agreeing with Dexpot as No. 1, but suggesting that maybe Virtual Dimension belonged in the top three or four.  Another site nominated Micro Desk as one of the best.  CNET did not concur, however.  I liked that Dexpot would allow me to create up to 20 desktops.  I had previous positive experience with other Sysinternals software.  I found a decent video of Dexpot.  It seemed to show largely superficial features, but it did look good.

I went to Dexpot's webpage.  I saw that, in their support area, they did have a forum and an FAQs page.  On their download page, I noticed that they did have a portable version.  I downloaded the installable version and began to play with it, as described in a separate post.

Windows 7: Multiple Desktops: A Look at Dexpot and Sysinternals

As noted previously, I wanted to try using multiple or virtual desktops in Windows 7, so as to have different workspaces for different projects.  For this purpose, I decided to try Dexpot.  This post describes my first experiences with that program.

Setup and Orientation

When I ran Dexpot, it started minimized.  That is, there was an icon on the taskbar, at the bottom of the screen, but nothing appearing onscreen.  Mousing over the icon showed entries for four desktops.  Right-clicking on the icon gave me a number of configuration options.  First was "Window catalogue."  This displayed large thumbnails (apparently defaulting to a maximum of nine per screen), one for each program I had running on Desktop 1.  Clicking on a directional arrow at the top of the screen would take me to the next or previous desktop.  Clicking on any program icon, within any desktop, would take me to that program within that desktop.  In short, Windows Catalogue was a quick way to navigate to any program that was then running.  There were no tooltips, so I had to click on the red button at the top right corner of the screen to learn that this just took me back to the desktop.

Right-clicking on the taskbar icon again, the second option was "Full-screen preview."  This was a different way of representing what was going on, on my computer.  It divided the screen into quadrants.  Top left was for Desktop 1.  There, it showed a 1/4-size depiction of the actual look of desktop 1 at that point.  Desktops 2, 3, and 4 were blank.  Presumably the screen would have been divided into sixths if I'd set up six desktops.  This would be the more useful tool if I wanted to find a certain desktop and would know it by sight, and didn't necessarily need to go directly to a single window within that desktop.

Back on the taskbar, the third right-click option was for Settings.  In its General section, I saw that I could create up to 20 desktops, designate which one would open first, etc.  There were some options related to profiles.  If the machine had other users and didn't require them to sign in under their own accounts, that would presumably be where the person would go to choose his/her own set of desktops.  Also, I guessed that a one-user system might use this feature if, say, the person had different sets of desktops that s/he used in professional and personal roles.  If this was correct, there was not actually a limit of 20 desktops; there was no limit, since each of an indefinitely large number of profiles could have 20 desktops.

The primary sources of guidance on such matters seemed to be Dexpot's Quick Start Guide, FAQs page, and support forums.  The Quick Start Guide provided a big-picture orientation to Dexpot, starting as a tutorial for beginners in virtual desktops and then proceeding to customization.  The FAQs page featured maybe two dozen specific questions and answers.  The forums of interest (aside from the FAQs) were Support, Feature Requests, Plugins, and General Discussion.  The Quick Start Guide told me that Alt-2 would take me directly to desktop 2.  One of the FAQs discussed the Settings dialog that I was now viewing, but did not confirm or deny my speculation about the possibility of having many users, each with its own 20 desktops.

Continuing in the Settings dialog, I went to the Appearance section.  Here, I could customize a few items.  A bit of confusion or overlap here:  I would have expected to configure wallpaper and other layout items here, but instead, to do that, I had to go back to the taskbar, right-click, and choose the fourth item, "Configure Desktops."  That opened a different dialog, with global options applicable to all desktops and also with individual desktop overrides for name, resolution, password, and all kinds of other settings.  It seemed to me that Dexpot should combine these two main right-click menu options.  So, to complete the thought regarding that Configure Desktops menu pick, I went to the All Desktops option and browsed.  There really was not too much I wanted to change right now.  Later, I would go to the Background tab for each desktop and give it a unique look, so that it would be easy to tell at a glance which one I wanted.  One interesting feature here:  I could specify commands that I wanted each desktop to run upon starting.  So if I opened a certain desktop each Saturday, for purposes related to one specific folder on my computer, perhaps I could specify a Windows Explorer command that would open Explorer to that folder when I started this desktop (and likewise for opening a specific document in Word, etc.).

So, OK.  This -- the Appearance tab, plus the Configure Desktops menu pick, seemed to take care of the basic look of the thing.  Back in the Settings dialog, I went to the third tab:  Components.  There were four tabs.  The first component they were going to let me configure was the Desktop Manager; the other three tabs were for Desktop Preview, DexTab, and Windows Catalogue (above).  Here, again, I browsed through the options.  I didn't yet have any particular reason to change their default settings, so I just moved on.

The fourth section in the Settings dialog was for Controls.  This seemed to be the ultimate tweaker section.  There were tabs for Hotkeys, Mouse Switch, and Title Bars.  "Controls" apparently meant "how to handle user input related to Dexpot."  So if I wanted to create a hotkey to move a window to desktop 3, this was where I would do that.  On the second tab, it looked like I could configure various mouse actions.  For instance, if I moved the mouse to the left edge of the screen and held it there, possibly that would be interpreted as an indication that I wanted to go to the previous desktop.  There seemed to be a number of configurable possibilities like that here.  That was interesting, but I didn't set it up yet.

Next, the Switching Desktops section.  Again, some confusion:  they had appearance-related items here too, such as screen resolution and screensaver customization.

Finally, the Plugins and Extras section.  They listed five plugins:  Dexcube, SevenDex, Slideshow, Taskbar Pager, and Wallpaper Clock.  SevenDex was already installed with my version of Dexpot.  It seemed that SevenDex, for Windows 7, was responsible for what this post has been describing as items listed on a right-click menu from the taskbar icon.  Finally, there was an option, here in the Plugins and Extras section, that I didn't entirely understand.  It had to do with "Behaviour of windows on other desktops."  One possibility, "When activating a window on another desktop," was, "Copy window to current desktop."  I wasn't sure how this activation concept worked; it seemed I would probably have to see it in action to grasp it fully.

Those were the Settings and Configure Desktops items that jumped out at me, on my first pass.  Continuing down the menu that popped up when I right-clicked on the Dexpot (actually, SevenDex) taskbar button, I saw four more items:  Desktop Manager, Desktop Preview, Desktop Windows, and Desktop Rules.  Choosing Desktop Manager would give me a little always-on-top toolbar that I could use to switch among desktops.  I didn't want that onscreen, so I didn't use it.  Why should I?  Just left-clicking on the taskbar button would give me the same thing.  But possibly some of the right-click options available from that little toolbar (e.g., "Move other windows to this Desktop") would be useful.  Desktop Preview opened another little always-on-top toolbar, this one showing inaccurate thumbnails representing the four desktops.  Desktop Windows gave me a dialog (not always-on-top) that would list the windows I had open in any selected desktop, with right-click options to move, copy, close, create rules, etc.  I did not yet have much concept of the purpose that rules would serve in Dexpot.  I figured the purpose would seem more obvious once I had a bit of experience with the program.

Using Dexpot

With that brief tour of settings, I decided to start using Dexpot.  I went to the taskbar icon and chose desktop 1.  That was my preexisting desktop, running Windows Explorer, Adobe Acrobat, Firefox, and a couple of other programs.  Nothing new there.  Now desktop 2.  No programs running there.  Same Start Menu and everything else; it was just a new workspace.

So, alright, there in desktop 2, I started another session of Acrobat.  It allowed me to do this.  The one in desktop 1 was still running.  So that was different from having just one desktop.  With just one desktop, I could run only one session of Acrobat at a time.  I went into desktop 1 and opened a file called D:\Current\x.pdf in Acrobat.  I went into desktop 2.  Here, x.pdf was already opened.  So I wasn't actually running different sessions of Acrobat.  I was running one session, but I could see it on different desktops.  I tested this by closing x.pdf and opening some other PDF file in desktop 2.  Now that was the one displayed on desktop 1 as well.  Closing Acrobat in desktop 2 closed it in desktop 1 also.

So, OK, this was definitely not the same as using a virtual machine, where each desktop would function as its own little world, oblivious to whatever might be happening anywhere else.  Programs like Acrobat, that would run only one session at a time, would be like the hedgehog that knows one great thing.  But how about programs that would allow me to run multiple sessions at once?  In desktop 1, I navigated in Windows Explorer to D:\Miscellany.  This did not affect Windows Explorer in desktop 2.  There, it was still looking at D:\Current.  So for purposes of Windows Explorer, the two desktops were more or less like separate virtual machines.  I tried the same thing in Word.  I opened y.doc in desktop 1.  That did not open it in desktop 2.  I opened the same file, y.doc, in desktop 2.  I made a change to it.  This change was also visible in desktop 1.  So Word was functioning like Acrobat in that sense.  If I opened a file in Word in one desktop, the changes would be immediately visible if I opened that file in Word in other desktops.  I closed y.doc in desktop 2.  Here, again, that closed y.doc in desktop 1 as well.

This seemed to explain why the screenshots that I had been seeing, showing various multiple desktop programs, were often empty except for the customized desktops themselves.  As long as I had different programs running in the different desktops (e.g., two different PDF readers or editors), there would be no problem.  Basically, the desktops were a way to reduce clutter.  Programs would appear only in the desktops where they were being used.  I was pretty much used to having them all visible on the taskbar, though.  It didn't seem helpful to go hunting through other desktops to find them.  It probably would have been different if I had a large number of different programs running at once.

No doubt there were other uses.  One example was if the user needed to use different screen resolutions for different programs or projects.  With the use of hotkeys, I figured I could also use one desktop to retain a full-screen view of a video, for instance, or other layout customizations, while having a more traditional layout in another.  If I wasn't using the same video player, I could even have multiple videos running or paused in different desktops.  Maybe I could also use portable programs (copied to, and running from, distinct folders if necessary) to run multiple instances of the same program.  There were portable versions for programs that would do much of what I needed to do (e.g., OpenOffice instead of Microsoft Office).  So there were possibilities.  The overall purpose was evidently to manage appearances, not programs.  As long as Dexpot wasn't interfering with anything else, it seemed like something worth keeping around.

Virtual Desktops in Another Multiple Desktop Program:  Sysinternals

Dexpot seemd to be a multiple desktop administrator.  It did not actually give me distinct virtual desktops, each of which could have its own session of Word or Acrobat running in ways that were completely unrelated to what might be happening in other virtual desktops.  I wondered if other multiple desktop programs functioned the same way.  Wikipedia said that the XWindow system used in Linux did allow the same program to be doing different things on different desktops.  It also said, however, that on Windows systems, program conflicts were common in multiple desktop setups.  This seemed unavoidable.  If Acrobat was not built, at this point, to accommodate multiple sessions, and if Windows at this point was not designed to facilitate virtual desktopping, then it seemed that a search for complete workspace independence would require a virtual machine, not just a virtual desktop.

I recalled the impression, from a CNET review, that Sysinternals Desktops might provide more independence.  I killed Dexpot and then downloaded and installed Sysinternals.  They weren't kidding when they said it was lightweight:  it was a 60KB portable.  Options were almost nonexistent.  Within a minute after installing it, I had figured out that Alt-2 would take me to desktop 2.  And that was about it.  I opened a Word document in desktop 1, and another Word document in desktop 2.  The two did not seem to know that the other existed.  This was good.  Excel likewise was able to handle two distinct spreadsheets in two virtual desktops.  I tried to do the same with Acrobat, but that didn't work.  I had to kill Acrobat in desktop 1 before it would run in desktopt 2.  Apparently Acrobat was not going to be compatible with virtual desktops, no matter how independent; it would take a virtual machine to run multiple sessions of that.  But I could imagine using other PDF programs -- again, perhaps as mutiply copied portables -- to handle most Acrobat functions in those other desktops.

In Sysinternals, desktop 2 did not have all of the icons in the system tray that I had running on desktop 1, and it did not have my customized Start Menu.  Back in desktop 1, some of the system tray icons seemed not to be functioning properly.  For instance, Windows-C was no longer opening Copernic Desktop Search.  I decided to uninstall Dexpot, run Glary's registry checker on reboot, and try again.  Sysinternals was running, as I had set it to do on bootup, and Windows-C was bringing up Copernic.  I hit Alt-2 and went into desktop 2.  Here, Windows-C did not work to bring up Copernic.  I went back to desktop 1.  There, Windows-C still worked to bring up Copernic.  So, preliminarily, either Dexpot itself or some conflict between Dexpot and Sysinternals had affected the tray icons.  Back in desktop 2, Control Panel showed that Copernic was installed.  But when I went to Start and typed Copernic, it wouldn't run that way either.  So if I wanted to search for files using Copernic, apparently I would have to go to desktop 1.  The tray icon was also missing, in desktop 2, for Instant File Find (IFF); accordingly, Shift-Esc failed to bring up IFF.  Back in desktop 1, IFF was now also failing to come up from the tray icon.  It did come up from the Start Menu, but had some kind of apparently fixable problem with its index.  The general idea seemed to be that, in Sysinternals desktop 2, I could only run a program from the tray (using its hotkey) if the program's icon appeared in the tray; otherwise, I would have to start it from the Start Menu, or perhaps from a toolbar or as pinned to the taskbar.

Summary

Virtual desktop software seemed much lighter and faster than virtual machine software.  Some virtual desktop programs (e.g., Sysinternals) were able to provide desktops that were largely independent from one another.  Where a program (e.g., Acrobat) was uncooperative (i.e., where it insisted on being run in just one desktop), it could conceivably be supplemented by some more cooperative freeware alternative and/or by use of multiple distinct portable versions of the folder containing its program files.  The best of the available multiple desktop managers (e.g., Dexpot) seemed to provide interesting, configurable interfaces.  Sources and my own brief experience raised the prospect of program conflicts.  There did not appear to be a capability to save images of virtual desktops, as one would save virtual machines, so as to preserve everything in the desired or previous layout.  For that last reason especially, while I did decide to install Dexpot and use it on an introductory basis, I also felt that my next serious effort in this area would be to consider a return to virtual machines, although this time in Windows rather than Ubuntu.

Windows 7: Multiple Monitors, Multiple Computers: Possibilities

I planned to be using Windows 7 on two computers.  At the start, I had two monitors, each dedicated to its own computer.  I wondered if I could set up the system so that I could use both monitors for computer A, and could also use both monitors for computer B.  I also wondered if I could use monitor A to see what was happening on both computers A and B at the same instant.

My first search led to ads for KVM switches, but that wasn't what I wanted.  I did look into KVM switches at Newegg, just in case someone had invented a switch that would do everything.  But then realized I wasn't going to read through all those product descriptions to see if any of them had the possibilities I wanted.  A different search got closer to what I wanted.  Actually, it went well beyond it.  There were possibilities I hadn't even imagined.

One possibility was that of Synergy, which had originally been Synergy and then became Synergy-Plus and was now back to being Synergy.  It looked like the Synergy concept ws that I could have two or more computers, each having its own monitor, and I could have just one keyboard and one mouse, and would move among these computers simply by moving the mouse to the left or right, until it left one monitor and then appeared on the next.  No KVM switch; just move the mouse to switch computers.  The connection was by ethernet -- just get all computers on the same network.  They said you could also copy and paste between the computers.  But apparently Synergy wasn't entirely stable yet; that was their stated goal for 2012. For that reason, I decided I would prefer a KVM for now, if necessary.  Presumably a problem with the network would render all computers other than the server (i.e., the one to which the keyboard and mouse were connected) unavailable.  Bruce Tyson pointed out that there would also be a problem if the user wanted to access the BIOS of a slave or client computer during bootup.  It seemed like it might be a good idea to have a spare keyboard and mouse handy.  Another possibility:  Input Director.  This Windows-specific freeware application seemed to have the same concept as Synergy.  These sorts of programs seemed to have the same idea as a KVM switch that would allow one keyboard (e.g., that on a laptop) to take control of another computer even if it did have its own keyboard and mouse.

Bruce Tyson also pointed me toward web-based sharing services, Virtual Network Computing (VNC), and remote desktop software.  These apparently all were, or could be, variations of "headless" computing, where the keyboard, video, and mouse (KVM) are all connected to just one computer, which is then linked to others whose contents may display on that monitor.  He also noted that some monitors have dual inputs, which could be plugged into separate computers, but that the user would have to switch between them using buttons on the monitor.  That would prevent simultaneous viewing of two computers and would also be klunky in daily use.

It seemed that GoToMyPC.com was one of the leading web-based services.  But when I looked into it, these appeared to be simply ways of accessing the computer remotely.  At $10/month or more, it was pricey.  LogMeIn and others seemed to offer good free alternatives.  I decided I didn't want a web-based service, even if it did exactly what I wanted, because it would be relatively slow and it would be vulnerable to anything that might go wrong with the modem, the network connection, etc.

According to Wikipedia, VNC was both platform-independent and remote-capable, and some versions were "optimised for Microsoft Windows."  A list of versions indicated that UltraVNC (free) was the most advanced mainstream version and was the basis for several others.  Current alternatives for connecting a few Windows PCs included EchoVNC (free), RealVNC (free+), SmartCode VNC Manager ($129+), SupportAnyPC ($149), TeamViewer (free), and TightVNC (free).  Among these, a RealVNC feature comparison page indicated that its free version was not compatible with Windows 7.  Wikipedia pages for the free versions indicated that RealVNC was similar to UltraVNC, but the latter had more features; EchoVNC differed from UltraVNC in being more firewall-friendly; Teamviewer was mostly for remote control of computers; and TightVNC likewise had spun off a firewall-friendly variant, RemoteVNC ($25 per computer), among others.  A Wikipedia comparison page, only in it formative stages at this point, named Skype, TigerVNC, and xpra as other free Windows-compatible remote desktop programs.  The Wikipedia pages just linked for those additions indicated that TigerVNC was a fork of RealVNC; that Skype was (of course) primarily for VoIP; and that xpra (currently a beta product) used an approach that differed from that of VNC; but it later looked like xpra was not for Windows.  For my purposes, the survivors of this discussion were EchoVNC, TigerVNC, TightVNC, and UltraVNC.

I looked at a Wikipedia page showing a comparison of Java remote desktop projects. I was not sure what this was about. The project that seemed most feature-rich at this point was WallCooler VPN, so I looked into that. This actually led to a page for Vedivi, which seemed to be in the business of giving people access to remote computers at a low monthly price.

Eventually I figured out that there are many remote desktop protocols.  VNC was one; Remote Desktop Protocol (RDP) was a Windows-specific alternative.  There were others.  I eventually found a chart that, although officially for Mac, pulled together some of this.  Revisting the Synergy and Input Director webpages (above), I saw that Synergy was not a VNC project; I was not clear what type it was, and likewise for Input Director.  Supposedly Microsoft's own version of RDP was currently called Remote Desktop Services, previously Terminal Services; but when I went looking for it, I wound up in Remote Desktop Connection (RDC).  A search led me to a description that sounded like what I was looking for.  I wondered why someone would have bothered creating Input Director, with its Windows orientation, if this feature already existed in RDC.  I decided to start by trying to use RDC, to see what would happen.  That would be the subject of another post.

Windows 7 as Host: Choosing a Virtualization Program

I had previously used VMware Workstation to run Windows XP in a virtual machine (VM) on Ubuntu Linux.  Now I was switching from Ubuntu to Windows 7.  I had found that WinXP was actually more stable in a VM than when running natively.  I also didn't want to go cold-turkey from WinXP; that is, I wanted to continue to have access to my familiar programs and other arrangements until Win7 felt natural.

I couldn't use my Linux-based copy of Workstation on Win7, so I would have to come up with a new virtualization tool.  I didn't want to shell out for another copy of Workstation.  I wondered if there were good free alternatives that would let me run WinXP in a VM on Win7.  I did a search, viewed some random remarks, and came up with some comparisons of several leading virtualization products.  These comparisons confirmed my sense that the main free contenders were Microsoft Virtual PC, Sun Virtual Box, and VMware Player.

Looking first at comparisons against Virtual PC, one reviewer suggested that Virtual PC was easiest for a purely Windows setup like mine, Virtual Box was more oriented toward Linux hosts, and Player was the most popular.  Another reviewer said that VirtualBox and VMware Workstation (not necessarily Player) had more advanced customization options, such as unity mode, snapshots, USB drive support, the ability to move VMs, and the option of allocating two CPU cores.  Another reviewer, comparing VirtualBox and Virtual PC, found that Virtual PC had the advantage of presumably greater Microsoft compatibility, better disk technology, a free WinXP license, support for Win7 and Vista guests, lower resource consumption on host, and easier physical drive configuration.  He favored VirtualBox nonetheless, though, because he found that VirtualBox supported more operating systems (especially Linux and Mac), supported 64-bit guests and multiple processor cores (i.e., better performance) as well as multiple kinds of virtual disks, and offered snapshots, unity mode, remote display, and 3D support.  Another reviewer, offering a video demonstration, said Virtual PC was better in supporting Aero, automatic login, USB device sharing, and integration into Windows Explorer (which he actually disliked), but favored VirtualBox for running on multiple operating systems and for other reasons stated by some of the other reviewers.  In short, there seemed to be some consensus that Virtual PC was the worst of the three.  I did a quick search to see if perchance Microsoft had upgraded it recently.  It didn't seem to have done so.

At about this point, I realized that probably I could continue to use my copy of VMware Workstation for Linux to make virtual machines containing WinXP, and use those in Player on a Win7 host.  So I wasn't sure if I should be comparing VirtualBox against VMware Player or Workstation.  I found both sorts of comparisons.  In what were probably the most professional reviews I saw, PCMag rated Workstation 6.0 (I was now using 7.1) at 4.5 stars, versus 3.5 for Virtual Box.  (At this writing, Workstation was on sale for $142 (with a free copy of VMware ThinApp Starter Edition thrown in) instead of its usual $189.)  One of the reviewers cited above encountered freezes in VirtualBox, and found that Workstation was the best performer.  She reported large differences in size between Workstation (~500MB) and the other two (~40MB), presumably reflecting more sophistication but also more resource demands in the former.  Another reviewer also compared VirtualBox against VMware Player.  He found VirtualBox faster in the guest, less burdensome for the host, and better in snapshots; but inferior in networking, and in support for Windows Aero, USB, 64-bit CPUs, and hardware virtualization.  Another reviewer favored VirtualBox because (s/he claimed) it was free, open source, more frequently patched, used fewer resources, ran faster, resumed faster, and was able to use its competitor's VMs.  The remark (above) that VirtualBox was more oriented toward Linux hosts was echoed in my own previous look at VirtualBox, where I cited a source indicating that VIrtualBox did far better in Linux hosts.

It seemed that VMware was ahead of the game or at least a solid contender in most ways, but that it was not a clear and obvious winner, especially when price was considered.  Having already played with VirtualBox a bit, and having learned VMware's approach, it seemed that I should start with whatever I could pull together from Workstation and Player.  If I ran into performance issues with a Windows host as I had with an Ubuntu host, maybe then it would be time -- especially before investing another $140-190 in VMware -- to give VirtualBox a more extended look, and that might also be true if I reached the point of having to build another WinXP VM from scratch.  I could do that in VirtualBox, and in that event might find it a relatively problem-free alternative.

Before proceeding to try VMware Player in a Windows host with my existing VMware VMs that I had created using Workstation on a Linux host, I looked into the recollection that VMware Server was also free.  Posts in one thread said that Server could create VMs too, but was not as fast as Player and did not have as many capabilities for an already existing VM.  I found EasyVMX.com and gathered that there were other ways to make VMs as well, though there didn't seem to be a point in doing so unless if I had been short of system resources to run Server.

I discovered at this point that VMware offered another free virtualization product, called the VMware vSphere Hypervisor, or ESXi for short.  This one differed from the others in being a "bare metal" hypervisor -- that is, not requiring a host at all.  In other words, I would install this first, before installing the operating system, and then I could install one or more operating systems, each in its own VM, without devoting resources to non-virtualization services being provided by the host (though it began to sound like ESXi would only run one operating system at a time).  In the long run, this sort of thing could be the end of dual-booting, and I could have Ubuntu, Win7, WinXP, and any other operating systems ready to run as needed, including those already packaged in free VMware appliances.  ESXi was said to offer better performance than Server.  It wasn't clear that it could be made to work on a PC as distinct from a dedicated server, though.  VMware's Hardware Compatibility Guide was not going to provide information for my puny little AMD Athlon (as distinct from Opteron or Xeon) CPU.  Another source made it sound like a home PC could run it, though.  Managing ESXi seemed to be the sticking point; for example, VMware's ESXi Management Kit cost $995.  Veeam offered a free ESXi manager, but there appeared to be a network administrator type of learning curve involved here.  Some people seemed to be using a minimal Linux to manage it.  It also sounded like there might be an ESXi manager within ESXi itself.  Apparently part of the reason Server was slower was that it was more user-friendly.  The purpose of the free ESXi seemed to be to get new system administrators into the VMware world and ready to upgrade to more powerful VMware server products.  Apparently there were ways to run ESXi in Workstation in Windows 7, but this seemed like the opposite of a bare-metal approach.  Basically, I liked the idea of a bare-metal hypervisor, but the sparse results I was getting on my searches told me that I was looking into something that was not happening for end users, at least not yet.  It could be done, but servers remained something that other people used for other purposes.

I wasn't quite ready to give up on the idea of a bare-metal hypervisor for home use, so I did another search.  Brad Maltz gave me a nice chart to compare the options.  His bottom line:  "You can expect plenty of hurdles and years for perfecting this technology, but the client-side hypervisor is the catalyst to many greater things to come."  My goal for the coming months, it seemed, would be to continue to focus on the usual multi-layered host-virtualization-guest scenario.  For that purpose, I would start with VMware Player and my existing VMs.  If I needed to adjust them, I would try to do so in either Workstation for Linux or Server.  If I had to build a new VM, I would consider doing it in VirtualBox as an alternative to Workstation or Server.

Improving Performance in VMware Workstation 7.1

I reviewed the latest version of VMware's document, Performance Best Practices for VMware Workstation, to see what hardware purchases or sales it would suggest for my situation.  The document consisted of four main sections, pertaining to host system hardware, the host operating system (OS), VMware Workstation and virtual machines (VMs), and guest OSs.  I was particularly interested in information about running Windows XP on an Ubuntu host, since that was the setup I was using.  This post does not say much about Windows host systems.

Section 1:  Hardware

A.  CPUs

1.  Hyperthreading

VMware (p. 7) recommended using a CPU that would support hyperthreading (also called "logical processing").  (The OS and the BIOS would have to support it, and the user would have to make sure it was enabled in the BIOS.)  Patrick Schmid at Tom's Hardware said that the primary benefit of hyperthreading was to permit smoother responsiveness, but that it would not yield noticeable increases in performance otherwise, and certainly would not substitute for having multiple cores in the CPU.  Intel's own writeup of hyperthreading affirmed that responsiveness was a leading benefit.

AMD quoted VMware as saying, “Virtual machines are preferentially scheduled on two different cores rather than on two logical processors on the same core.”  That is, VMware tried to assign different VMs to different CPU cores, if available.  This seemed to imply that AMD CPUs would do better when the number of CPU cores matched or exceeded the number of VMs being run.  But AMD suggested that increasingly complex software (e.g., multithreading in Microsoft Excel 2007) could keep as many as 48 CPU cores busy, even if the number of VMs being run was much lower.

AMD's point in that particular article was that its Opteron CPU, with more cores, could significantly outperform Intel's Xeon, with hyperthreading and fewer cores.  Anandtech's comparison of state-of-the-art Intel and AMD CPUs in March 2010 found, however, that the Xeon did much better than the Opteron.  Recent observations suggested that AMD might be moving toward implementing hyperthreading after all.

A search on Newegg.com turned up 20 Intel CPUs with hyper-threading capabilities, starting at $115 and ranging above $1,000.  (The least expensive Intel CPU listed on Newegg at that point cost $41.)  Anandtech said that the AMD advantage was in terms of price, with good performance at much lower cost.  One Anantech commentator said, "The twelve-core AMD Opteron 6100 and six-core Xeon 5600 perform more or less the same," but suggested that Intel had two advantages at the enterprise level:  RAS (i.e., reliability, availability, and serviceability, including the ability of systems to heal themselves) and licensing.

2.  MMU Virtualization

VMware (pp. 7-8) also expressed a preference for second-generation hardware-assisted MMU virtualization, called rapid virtualization indexing (RVI) or nested page tables (NPT) in AMD processors or extended page tables (EPT) in Intel processors.  (Wikipedia indicated that NPT was used during development, but that RVI was the term currently used.)

VMware found that, in its ESX product, AMD's "RVI provides performance gains of up to 42% for MMU-intensive benchmarks and up to 500% for MMU-intensive microbenchmarks."  VMware found similarly dramatic performance improvements for Intel's EPT, provided the virtualization product made suitable adjustments -- which, VMware said, ESX did.  It was not clear that the same could be said for VMware Workstation.  Pending further research, this information made an AMD CPU with RVI the more certain performance boost for an ordinary user of Workstation.

At this writing, neither Newegg nor TigerDirect offered products featuring any of those CPU-related acronyms.  According to Wikipedia, MMU debuted in the third-generation AMD Opteron, and at Intel EPT debuted in the Nehalem architecture.  (That same Wikipedia page said that RVI was supported, at VMware, in ESX Server 3.5 and later -- and also, interestingly, in Oracle's VirtualBox 2.0 and later.)  At Newegg, at this writing, Opterons were available in the range of $190-1,300 (and would require motherboards in the $200-600 range).  The Nehalem appeared in the Core i7 line of CPUs, available at Newegg for $290-1,140.  (Newegg didn't list a canned search option for Nehalem or Westmere cores.)

I looked at some historical prices to get a rough idea of how processor pricing trends worked.  On the Intel side, the Core 2 Duo E6700, introduced in July 2006 for $530, was apparently available (in some form) for $316 in June 2007, around $212 in July 2008, $130 in September 2009, and $95 in July 2010.  These values suggested that prices dropped dramatically (perhaps 40%) in the first year, less dramatically (perhaps 20% of the original price) in the second year, and likewise (perhaps 10% of the original price per year) over the next couple of years.  (Intel apparently discontinued the E6700 (presumably meaning that manufacturing ceased) in February 2008.  At that time, the chip may have been selling for somewhat less than half the original price.)  On those data, the rate of discount from the original price was cut in half in each succeeding year, during the first several years of the product's life.

I took a particular interest in one of the Core i7 CPUs at the bottom of Newegg's list, pricewise.  The Core i7-870 that was available for $290 in July 2010 debuted at a list price of $562 in September 2009, representing a 49% drop in less than a year.  The data from the preceding paragraph suggest that the consumer might anticipate another 25% reduction from the original price (i.e., half of the previous year's price cut), for a price of around $145, by summer 2011.  On this basis, it seemed to me, personally, that I might thus save myself $150 (plus whatever price drop might apply to the corresponding motherboard) if I waited to implement these particular suggestions for VMware performance until summer 2011.

Intel described the Core i7-870 as having both hyper-threading and VT-x virtualization technology.  But VMware (p. 8) indicates that VT-x is the first-, not the second-, generation of virtualization technology.  Its potentially outdated status is reflected in a VirtualBox recommendation that VirtualBox has been designed to perform better without enabling this sort of hardware-assisted CPU virtualization at all.  As of late 2008, someone in a VMware Community post considered VT-x a major step forward, but noted that hardware-assisted virtualization in Workstation 7 was supported only on 64-bit hardware.  I did have 64-bit hardware, so that was not a concern for me.

But which Intel CPU would I have to be tracking, if I wished to get into the second-generation Intel EPT (or AMD RVI) MMU virtualization technology?  Intel characterized EPT as an "extension" of VT-x and, to revert to the (Wikipedia) observation offered above, that extension was apparently to be found on the Nehalem (45nm) or Westmere (32nm) architectures.  Evidently not all Core i7 CPUs employed that architecture, then, else the i7-870 would have it.  (I was not alone in being confused about this.)  It seemed that what I was looking for might be, in Intel-speak, VT-x2.  Further searches for insight led to a simple request for a list of VT-x2 features implemented in various Core i7 CPUs -- to which Intel provided the bizarre response that, no, actually, it was hard to provide any such list, and a pointer to lengthy software developer's manuals.  Indeed, it seemed that VMware was somewhat behind the curve:  while it was talking about EPT (as implemented in VT-x2), Intel was meanwhile moving on to VT-d and other technologies.  Then again, another Intel source seemed to say that VT-d was an older technology.

The message seemed to be that I, as a consumer, didn't need to know about this yet.  I decided to try a different approach.  I went back to Newegg's list of Core i7 processors and tried working my way up the list until I found one that did have VT-x2.  After the i7 860 and 870, next on Newegg's list was the 930.  My search regarding the 930 and VT-x2 led to an Intel Virtualization Technology List indicating, that, well, yes, a number of Intel CPUs did support VT-x.  I looked at them individually to see if perchance they supported VT-x2, that information unfortunately not being included in the alleged virtualization technology list.  Bottom man on this list was, again, the 860, and they confirmed that it did support both VT-x and VT-d.  At the top end of the set, we had the 970.  The 970's spec sheet didn't say anything about VT-d, so maybe it was indeed being phased out.  No mention of VT-x2 either; just VT-x.  Following some leads, I came around to the discovery that there was also something known as VT-i, referring to the Itanium processor.  It wasn't helpful information, but at least it was information.

Looking back at that page on the i7-970, I noticed that Intel said, in greyed-out letters, "No Datasheet Available."  But, hmm, did that mean there were datasheets for others on that virtualization technology list?  I tried the 920.  There, they had a "Download Datasheet" link that led to about a dozen Technical Documents.  I started with the 96-page Intel® Core™ i7-900 Desktop Processor Extreme Edition Series and Intel® Core™ i7-900 Desktop Processor Series Datasheet, Volume 1.  But no, according to Acrobat, there were no references to VT-x2 there.  How about VT-x?  Nope.  Alright, then, volume 2?  None!  Well, how about just plain old "virtual"?  Still nothing on what virtualization technology any particular CPU might have.  This was a contrast against another set of technical documents provided on that same page, for the i7-800 series.  Here, I found references to both VT-x and VT-d.  Volume 1 of that datasheet said, on page 29, that the i7-800 series did support EPT.  So that was pretty confusing.

I decided to try the Developer's Manuals.  The description mentioned virtualization only in connection with the Intel® Virtualization Technology FlexMigration (Intel® VT FlexMigration) Application Note and the Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide.  The Application Note contained several references to VT-x, but did not distinguish it from VT-x2 or VT-d.  Volume 3B of the Software Developer's Manual contained no references to VT- of any type.  Both documents did refer to Virtual Machine Extensions (VMX), and the Manual contained lots of information on how virtualization works.  But I was not able to figure out, from this information, which CPU I should buy.  This was pretty strange, given the conclusion that Intel's whole reason for offering virtualization in only some CPUs was driven by marketing.

It occured to me that perhaps the people at VirtualBox would provide some insight into what they would recommend, if I opted for a VirtualBox-compatible CPU.  A search produced very meager results along these lines.  I went to the VirtualBox website and looked at their documentation.  They said that "the vast majority of today's 64-bit and multicore CPUs ship with hardware virtualization."  No distinction there between VT-x and VT-x2.  They also said, "The biggest difference between VT-x and AMD-V is that AMD-V provides a more complete virtualization environment."  The use of what they called "nested paging" (i.e., more advanced virtualization, apparently what others meant when they referred to VT-x2) could bring a "significant" performance improvement -- of up to 5%.  Five percent!  I was thinking we were talking about the difference between success and failure, and now it appeared this might be just one more incremental improvement.  Nested paging, they said, was standard on Intel's Core i7 (Nehalem) CPUs, and also on AMD's Barcelona CPUs.

I did finally find, at Tom's Hardware, a list of CPUs that would support "XP Mode" Virtualization.  XP Mode was the capability of running a near-perfect emulation of Windows XP within Windows 7 (which would enable people to use older applications on the newer operating system).  In March 2010, Microsoft altered Windows 7 so that it would no longer require hardware virtualization in order to provide XP Mode.  But the Tom's Hardware list dated from a year earlier, so it gave an idea of what Intel CPUs I would need to consider if I wanted hardware virtualization for purposes of improved performance in VMware.  The Tom's Hardware list actually drew from a list posted by Ed Bott on ZDNet.  Ed provided a list of Intel desktop and mobile CPUs.  His desktop list boiled down to the following, which I provide here, in ascending order according to their current prices according to Pricewatch.com (or, failing that, on Newegg or Amazon):

So, bearing in mind that these were approximate prices, a person dead-set on obtaining a virtualization-supporting Intel CPU for less than $100 would have more than a half-dozen to choose from.

It appeared, in other words, that we were no longer dealing in the rarified world of enterprise-level Xeon processors; we humble consumers were treating virtualization as a simple commodity.  Paying more would bring, not necessarily any improvements in virtualization per se, but rather in those other characteristics that people like in their CPUs, including hyperthreading.

In that case, I thought that perhaps I should take a look at AMD, just to be sure that I wasn't blowing off an already affordable option.  If we were forced to accept the simplistic conclusion that you should just be happy knowing you could get some kind of hardware virtualization with any Core i7 CPU, why not price any AMD CPU with AMD-V virtualization?  According to a simple statement from AMD, that meant almost any CPU that I would be looking at.  Here, comparable to the situation with Intel, a Newegg search for any desktop CPU with virtualization technology support gave me AMD Semprons for as low as $37.

I reflected on my current situation.  To improve VMware's performance, I was looking to replace an AMD Athlon 64 X2 5000+ CPU.  But that dual-core CPU, which was hot stuff four years earlier, did support virtualization already.  The question seemed to be, what kind of virtualization?  What they were offering now was AMD-V.  Seeing the amount of time I had already invested in this general line of questioning, I decided I should just assume that it was better than the virtualization of yesteryear, and that having it on a faster CPU would be better still.  It seemed, in short, that I might just upgrade to a somewhat more up-to-date CPU, without worrying much about understanding VMware's hardware suggestions.  VMware (p. 17) said that, if I did have hardware-assisted virtualization in my CPU, Workstation would typically set it up automatically, but there was the option of changing the default in VM > Settings > Hardware tab > Processors > Virtualization engine > Preferred mode.  They also said (p. 26) that, if the system was using MMU, performance would be best if VMI (i.e., software virtualization:  "virtual machine interface") was disabled (VM > Settings > Hardware tab > Processors > VMware kernel paravirtualization).  Mine was grayed out.  I assumed it was something I would have to set when the machine was powered down, or perhaps in root mode ("sudo vmware").  They also said, "No Microsoft operating systems support VMI," but I wasn't sure what the situation would be in the case of an Ubuntu host.

B.  Memory

VMware's recommentation on memory (p. 8) was just to make sure you had enough.

C.  Storage

VMware recommended (pp. 8-9) having enough disk storage space, but also emphasized making sure it was configured correctly.  They mentioned the potential for improved performance from RAID.  Browsing among various sources suggested, generally, that there could be significant performance improvements (and possibly greater performance smoothness) in a RAID 0 setup, where the program files were installed on two (or more) hard drives.  By contrast, it seemed to be generally agreed that a RAID array would make less of a performance difference in the handling of data files.

D.  Other Hardware

VMware offered suggestions about networking and hardware BIOS settings.  These recommendations were worth reviewing for some purposes, but did not seem to require any purchase decisions for my purposes.

E.  Summary

The Hardware section of Performance Best Practices for VMware Workstation left me with the impression that, all other things being equal, VMs will perform better on multiprocessor CPUs, and that hyperthreading is a plus.  I was not entirely able to penetrate the jargon about MMU virtualization; the general conclusion there seemed to be that I should shop for a CPU that supported a relatively recent generation of virtualization technology.  Assuming no bottlenecks due to inadequate RAM or disk storage space, the other main performance recommendation for my purposes was to use a striping RAID arrangement.

Section 2:  Host Operating System

This section contained virtually no relevant suggestions for Linux-based systems.

Section 3:  VMware Workstation and Virtual Machines

VMware said (p. 16) that most applications running in Workstation would perform nearly as well as in native Windows.  For the "small percentage of workloads" that would experience noticeable performance degradation, they had several CPU-related suggestions:

• Don't assign more of a load to the CPU than it can handle.
• Don't assign more CPU cores to a VM than it can use.
• Monitor CPU usage with the Linux "top" program.
• When using a single virtual CPU (vCPU), as I was likely to do, I would get better performance on an UP rather than SMP kernel or hardware abstraction layer (HAL).
• The guest operating system may not switch to the appropriate HAL if the CPU settings change later (p. 27).

They said that Windows operating systems (OSs) newer than XP would use the same HAL/kernel for both UP and SMP installations.  It sounded like that was not the case for WinXP, however.  Microsoft seemed to say that XP would detect the type of system and would install the correct HAL automatically.  They said this:

Microsoft does not support running a HAL other than the HAL that Windows Setup would typically install on the computer. For example, running a PIC HAL on an APIC computer is not supported. Although this configuration may appear to work, Microsoft does not test this configuration and you may have performance and interrupt issues. . . . Microsoft recommends that you switch HALs for troubleshooting purposes only or to workaround a hardware problem.

So the HAL issue seemed to be something to be aware of, in some situations, but not something of practical relevance for a user of Windows XP, Vista, or Windows 7.  I was curious which HAL was installed on my system, though.  As advised by Kelly's Korner, I went to Control Panel > System > Hardware > Device Manager > Computer.  On my native WinXP installation, it said ACPI Multiprocessor PC.  In a newly installed WinXP VM in Workstation set to use just one processor and one core, it said ACPI Uniprocessor PC.

VMware (p. 17) said that, if there were other VMs or programs running in the background, performance of a VM in the foreground would be noticeably better if the settings were changed in Workstation (i.e., not in any particular VM).  The advice was to go to Edit > Preferences > Priority, and set "Input grabbed" to High, and "Input ungrabbed" to Normal.  But Workstation gave me no such options.

According to VMware (p. 18), memory-related performance could be affected in several ways.  First, there needed to be enough RAM available to the host system for its own purposes.  My system had 6GB of RAM. Normally, some of that might have gone unrecognized by a 32-bit OS, but I was running a PAE-enabled kernel in 32-bit Ubuntu 10.04.  Ubuntu's Sysinfo reported that my system's total RAM was 6050 mebibytes (MiB) (i.e., about 6.3 billion bytes).  Running Workstation as root (i.e., "sudo vmware"), I had set RAM to 5000MB (by which Workstation presumably meant 5000 x 1 million), leaving more than 1GB of RAM for Ubuntu system operations and whatever programs I might be running in native Ubuntu.  I did not typically run many programs in Ubuntu.  So it seemed that I had allowed enough RAM for the system.  It did occur to me, though, that if I was going to run two distinct sessions of Workstation (as opposed to running two VMs within a single Workstation session), I might want to cut that 5000MB figure in half for each Workstation session.

VMware (p. 18) also advised that the best possible performance would come from requiring Workstation to "Fit all virtual machine memory into reserved host RAM" (Edit > Preferences > Memory tab > Additiaonal memory).  But they provided this caveat:

NOTE:  The setting described in this section affects only whether or not a virtual machine is allowed to start, not what happens after it starts . . . . After a virtual machine starts, other factors . . . [e.g., change of applications running in the host OS] can change.  In such situations, even if you selected the Fit all virtual machine memory into reserved host RAM option, virtual machine memory swapping might still occur.

Since I did most of my work in WinXP, the message to me seemed to be to make sure that there was enough RAM available to the Ubuntu host so that it would not need to be raiding the WinXP guests.  This was consistent with the advice of VMware (p. 19).  They warned particularly about host applications that lock memory.  While it did not apply to my configuration, it was also interesting that they recommended providing no more than 896MB to 32-bit Linux VMs.  To monitor what might be happening, they suggested checking for swap activity in the host and virtual machines.  Doing in this Linux, they said (p. 29), involved running "stat" to dispay the "swap counters," and verifying that both the si and so counters were near zero.  I wasn't sure that their remarks applied to the Ubuntu version of stat, though.  A search turned up a manual page that didn't say anything about swap.  That page said made me think that a different search, focusing on the bash shell, might be more illuminating.  But that turned up nothing.  This really did not seem to be something that the world was blogging about.  Eventually, it appeared that what we were really looking for was vmstat, for which a search produced a couple hundred hits.  Brian Tanaka recommended running "vmstat 5 10" to get an average impression of what was happening on the system.  That didn't work on my system, but the vmstat manpage led me to try "vmstat -a -n 5 10" and that gave me ten indications that si and so were at zero.  So I seemed to be OK there.

VMware (p. 29) also pointed toward a knowledgebase page about "excessive page faults generated by Windows applications."  To see if this was a problem, they suggested using Start > Run > perfmon. I tried that, inside a WinXP VM.  At the top center of the System Monitor graph, I clicked the + (Add Counters) button.  I got an error message:

System Monitor Control
At least one data sample is missing.  Data collection is taking longer than expected.  You might avoid this message by increasing the sample interval.
This message will not be shown again during this session.

I took that to be a statement that my VM was running very slowly, which was not surprising, because I had some very intensive processes going on elsewhere on the computer.  I okayed out of that message and, following the advice on that page fault webpage, proceeded to choose Memory as my performance object, selected Page Faults/sec as my counter, clicked Add.  To get an accurate sample, I considered the advice from their error message:  I clicked on the Properties icon along the top and thought about changing it to "Sample automatically every 2 [or 3] seconds."  But then I decided the one-second sample was ticking along OK, and left it at that.  I was seeing occasional spikes in page faults.  The webpage advised that I could trace this to a particular application by going back to the Add Counters button, making Process my performance object, and then choosing a process of particular interest.  I named one of the very intensive processes I had underway.  Sure enough, I got a line across the top of the graph, indicating that that process was accounting for 90-100 (percent?) of something related to page faults.  Very interesting.  So basically this seemed to be telling me that a process that I knew was soaking up a lot of system resources was, in fact, soaking up a lot of system resources.

VMware (pp. 20-21) discussed ways in which page sharing and memory trimming, intended to promote efficiency, could degrade performance in some instances.  My situation did not seem to fall into those kinds of situations, so I made no adjustments there.  They said that, of course, a local disk drive would be a faster home for a VM than would a network drive.  They provided other tips that they had also indicated somewhere during the VM setup process:  for best performance, use IDE rather than SCSI virtual disks, and preallocated rather than growable, and independent and persistent rather than nonpersistent, and don't use snapshots.  They also (p. 22) offered some suggestions that I hadn't encountered previously:  with the machine powered off, turn off debug mode (VM > Settings > Options tab > Advanced > Settings > Gather debugging information > None).  Other performance tips (p. 23):  run a general availability (GA) version of Workstation, not a debug or beta version.  Make sure you have designated the right operating system (VM > Settings > Options tab > General > Version).  Disconnect your optical drives from your VM until you need them (VM > Settings > Hardware > CD/DVD > uncheck Connect at Power On).

To sum up, section 3 of Performance Best Practices for VMware Workstation did provide a number of practical tips on how to adjust Workstation to run more efficiently.  I was not able to understand and apply all of them, and some (e.g., make sure you have enough RAM) were rather commonsense if not simply redundant.  What I derived from the discussion of cores was that, if I did get a new multicore processor, I should probably experiment, as I had done with my present CPU, to see how it performed with various numbers of cores assigned in Workstation.

Section 3:  Guest Operating System

In this section, VMware led off (p. 25) with suggestions:  make sure you're using a guest operating system that Workstation supports; keep VMware Tools updated; disable screen savers and animations; run backup and antivirus scans in off-peak hours; use a timekeeping utility suitable for the guest rather than the VMware Tools time-synchronization option.  VMware (p. 28) also referred to impacts on efficiency wrought by guest OS "idle loops."  It appeared that tweaking this would be painstaking and would likely yield minor effects.

VMware (p. 30) confusingly said, "It is best to use virtual SCSI hard disks in the virtual machine."  This differed from the installation process, which said (at least at one point) that IDE drives were recommended.  Bizarrely, VMware directed me to a Windows webpage dated December 4, 2001.  More promisingly, VMware also pointed toward their KB9645697 webpage regarding the splitting of large I/O requests into 64KB units.  The gist of their suggestion here was, "Changing the guest registry settings to issue larger block sizes can eliminate this splitting, thus enhancing performance" (p. 30).  The way to do that was sketched out on page 30 (section 2.2.6.1) of a PDF document entitled User's Guide: Fusion-MPT Device Management.  But in any case, this called for an edit of the registry setting HKLM\SYSTEM\CurrentControlSet\Services\Symmpi\Parameters\Device\MaximumSGList, and there was no such setting in my VM.

VMware (p. 30) also recommended that, if I did use IDE rather than SCSI virtual disks, I should make sure DMA access was enabled.  To do this, I went into Start > Run > devmgmt.msc > IDE ATA/ATAPI controllers > right-click on each channel > Advanced Settings tab > look at Current Transfer Mode.  If it says PIO, toggle the other box, Transfer Mode, between PIO and DMA to get Transfer Mode = DMA and Current Transfer Mode = DMA.

Another performance suggestion (pp. 30-31):  defragmentation.  Start by defragmenting the guest, then use VM > Settings > Hardware tab > Hard Disk > Utilities > Defragment, then defragment the host (not applicable in Linux hosts).  Defragment before creating linked clones or snapshots; afterwards is too late.  I was only creating independent clones, so this did not seem to apply.  Nonetheless, I did have a defrag utility in the WinXP guest.  Defragmentation in VMware itself had always been almost instant, when I had done it.

For network performance, VMware (p. 31) recommended using the VMXNET driver.  They noted, however, that that driver was installed automatically with VMware Tools.  There were a few other network performance suggestions in the document.  Since I was not having networking performance issues, I did not investigate these.  VMware (p. 32) also offered some other concluding, sensible suggestions (e.g., use general-availability software, not beta versions; make sure the latest version of VMware Tools is installed.  Here, again, the advice did not seem to apply.

Summary (for My Purposes) 

A single problem with hardware or software could seriously impair performance.  I did not attempt to scour the Performance Best Practices for VMware Workstation document for every possible thing that might be improved.  Rather, at least in this first pass through it, I was focused on big-picture items that sounded like they might have a great impact on the performance of my system.  The Hardware section led me to think especially about upgrading to a faster multiprocessor CPU, perhaps with hyperthreading, but in any event with a recent generation of virtualization technology, and also to switch to a striping RAID arrangement for my program files (presumably including both the Ubuntu host program partition and the partition on which I kept my VMs.  Other than that, improved performance in VMware Workstation appeared to be a matter of tuning a variety of settings, some of which were becoming obvious as I gained more experience, and some of which would come to mind only as I reviewed the pages of the document and/or of this post.