Speed Up Browsing by Disabling Internet Explorer

I had installed Internet Explorer 9.  Now I was getting these completely dumb-assed messages at the bottom of the screen:  "Speed up browsing by disabling add-ons."  The first time, I thought this was a good idea, and I went ahead with that.  When it kept happening, though, I realized I needed to find a way to shut it off.  This post describes how I did that.

One suggestion that came up in my search was to click Disable Addons, on that reminder, and set the reminder time to as high as possible.  It seemed the best one could do was to choose the "Don't Disable" option to be left alone for 30 days.

But I wanted to eliminate this stupid reminder permanently.  A different approach involved making a change in Group Policy settings.  I wasn't sure how to do that, or even to see if I had the option in question, so I ran a search and found a tweaks article that reminded me that I could get into the Local Group Policy Editor via Start > Run > gpedit.msc.

In the policy editor, I didn't see exactly the option described.  The message said to start with the Windows Components area, but there were at least two of those:  one under Computer Configuration > Administrative Templates, and one under User Configuration > Administrative Templates.  I did find Internet Explorer subheadings in both, but neither had a "Disable add-on performance notifications" option.  The advisor told me that I might need to copy updated inetres.admx and inetres.adml files from a machine with IE9 installed, but this machine had IE9 installed already, so that did not seem to apply.

That pretty much exhausted my focused search.  At this time, then, there was no good solution to this problem.  I hoped that the Don't Disable option did indeed give me 30 days of peace.  At the end of that time, it was possible but doubtful (since I rarely used IE, and had just discovered one more reason for that) that I would actually appreciate the reminder.

Windows 7: RAID or Mirror Across Computers?

Where to put the data ... hmm.  I had a home network with two computers running Windows 7.  If the data I needed to work with was on one computer and it went down or had one of those frequent Microsoft maintenance or service interruption needs, I couldn't get to it from the other computer.  But if I put the data on a server, then (a) I had to buy and maintain the server, cables, routers, etc., (b) I had slower access times, (c) the data would then be unavailable to *both* machines (unless I wanted to swap out one or more hard drives) if the server went down, and (d) I had found that, if I accidentally corrupted or deleted the wrong file, a server might not be willing to undelete it.  Not a big deal, assuming you had good backup, but there were painful exceptions.

So it occurred to me:  can you put the data on one computer, so that it can function as a standalone, and also put the data on the other computer, so that it is a standalone too, but then have a constant RAID or mirror arrangement between the computers, so that whatever you do with the data on one computer is immediately duplicated on the other computer?  That way, you've got local speed, no server, and redundancy during downtime on either machine.  Basically, two-way mirroring:  when a file is modified, it checks the other computer, and the two of them figure out which version is newer, and it overwrites the older version on the other machine as well.  All you need is a router, if that.

I figured possibly everybody else already knew the answer to this.  But since I didn't, I started with a search.  Only six hits.  It looked like the concept of "RAID between computers" was a nonstarter.  Alright, a different search.  Wow, "mirror between computers" produced 13 hits.  But, OK, not to complain, it seemed most of those hits were for TreeNetCopy.  Take it out of the equation, and the search produced only five hits.  So TreeNetCopy seemed to provide the path forward.  But it didn't look like CNET, PCMag, or other big-name sites had reviewed it.  I went to the product's home website and found out why:  it was for systems using Windows NT or Windows 2000.

Apparently mirror and RAID were not the concepts I wanted.  How about incremental backup?  You couldn't have it running constantly; it would have to finish one scan of the system's files before it could start on the next one.  So maybe you'd set it to run every 15 or 30 minutes, or however a scan would take to finish, across the network connection.  This wouldn't be nearly as good as software that would detect and propagate changes as soon as they were made, but I wasn't seeing how to find anything like that.  With a 15- or 30-minute delay, you couldn't have someone being able to open the file on computer B as soon as someone else updated it on computer A, unless possibly if you had a script that would somehow be able to run the incremental backup manually for a given folder by just maybe choosing a right-click context menu option.

Alright, a different approach.  I had been using Beyond Compare, a file comparison tool.  It still looked like one of the more capable file comparison tools, so how about using it?  As I was thinking about that possibility, I realized that I didn't like the idea of having to do a right-click or other manual update.  The computer could crash before I got around to that, and then I wouldn't have the current data in the parallel folder on the other computer, and therefore really couldn't just keep right on working where I left off.  I had only used Beyond Compare as a manual comparison tool, where I would start it up and it would run for a while and compare directories and then show me what needed to be mirrored to my backup drive, and then I would click the buttons necessary to do that.  I knew it was possible to write scripts to automate some of this, but it seemed unlikely that scripts would help Beyond Compare remain up-to-the-minute on all of the file changes made on the system.  Most likely, I could set up scripts to run in some frequently used folders, and maybe even to automate the mirroring of those folders, but other folders would be left out in the cold.  Possibly I could have multiple scripts doing comparisons of more- and less-frequently used folders on different schedules, so as to increase the likelihood that most folders would be mirrored relatively often.  But with enough scripts running simultaneous file comparisons, I'd start to take a performance hit.

Lacking a better option, I did a search to learn more about Beyond Compare scripts.  The search came up with a number of interesting concepts, right there among the top ten hits.  One was the concept of automated synchronization.  Duh!  Of course.  Synchronization was the Windows term for what I wanted.  So I did a search for that, dropping Beyond Compare for the moment.  But the only thing that came of it was the discovery of Super Flexible File Synchronizer, which cost $60 for a two-year license (unless, for some bizarre reason, I would think that I could do without the pro version's ability to copy ZIP files!).  It did look like it might have some advantages over Beyond Compare, such as the ability to detect that I had moved a folder, so that it could just repeat the move rather than delete the folder from one location and create it in another (which might involve a lot of copying, if it was a large folder).  It had very good ratings on CNET.  I could download and try it out free for 30 days.  But it was ultimately still a backup program, running on a schedule, not a mirroring program, so I was still basically working with the same scenario:  design a set of backup scripts, profiles, or whatever, and set them to run at different frequencies, backing up what I would consider the most heavily used folders most frequently.

TopTenReviews ranked Super Flexible File Synchronizer eighth in its list of sync programs.  Their comparison page had a number of relevant criteria, including the ability to do bidirectional sync, to mirror files, and to operate across a network.  It actually looked like their number two program, GoodSync ($19.95), had better features for my purposes than their number one choice, Syncables 360 ($39.95).  Their review of GoodSync made it sound good indeed.  They said it couldn't sync or merge Microsoft Outlook files, which was OK because I was using Thunderbird.  (Later, I encountered a review by a user who said s/he was using it for this purpose, so I assumed they had updated the program.)  They said that working over networks could be complicated.  I wasn't sure if they meant that as a generic remark that would be relevant to all kinds of work over networks.  They seemed to rank it number two rather than one because it "lacks some of the advanced features professional users expect."  CNET's review likewise ranked it number two, but in the category of "file management."  I wasn't sure what they considered the number one program; their webpage didn't indicate which criterion they used for that ranking.  But GoodSync was the most frequently downloaded program during the prior week.  GoodSync's awards webpage mostly listed awards and positive reviews that were at least a couple of years old.  So apparently it had been created and was now coasting.  I did a search among its many reviews on CNET, looking for more info about using it on a network.  Unfortunately, CNET's links to specific reviews weren't working for me at that point, so I wasn't able to get details, but what I was able to read from the summary results was positive with the exception of one person for whom GoodSync did not work well.

There were hardware options.  SyncSharp offered a device that would synchronize via USB.  It sounded similar to The Tornado and to the Windows 7 Easy Transfer option.  I didn't want an additional device, and since ethernet was faster and was already in place, I didn't want to use USB.  For purposes of speed and also capacity, not to mention reducing dependency on external data sources, I was obviously not going to be interested in a cloud (i.e., web-based) solution, even if I had found one that offered constant, continuous, real-time synchronization.

It turned out that CNET had another category, for "data transfer & sync software."  As with some other CNET searches, I looked at the top 30 both in terms of downloads last week and user ratings.  Setting aside those that were for special purposes (e.g., Blackberry, Outlook), and focusing on those that were for Windows 7, I found that only two were free:  CopyTo Synchronizer, which had only two votes and which I therefore deemed insufficiently tested, and Microsoft Live Mesh, which had only one vote but which I was willing to assume was better developed.  The nonfree alternatives that came up in this search included BeyondSync, ViceVersa Pro, Easy Computer Sync, and Syncables 360 Premium.  I reduced this set to Live Mesh, Beyond Sync, and ViceVersa.  A search for further information on Live Mesh suggested it was web-based, more like DropBox, leaving me to focus on the other two.  A search led back to a TopTenReviews comparison -- it may have been the same one as before, but a couple of weeks had passed by thie time -- naming GoodSync (above) as No. 2, ViceVersa as No. 5, and BeyondSync as No. 10.  Of the ten, the ones offering bidirectional sync, network synchronizing, and Windows 7 support were these three plus Syncables 360, SugarSync, Laplink, and Super Flexible.  Most of the same names also appeared in a CEOWorld review.  I eliminated SugarSync as another cloud solution.  The TopTen review for Beyond Sync made it sound unappealing.  A dotTech review echoed that. 

I ran a search looking for comparisons of Syncables against the others that also sounded good for bidirectional synchronization.  A couple of reviews alerted me to the feature, evidently present in GoodSync but not all others, of being able to see which changes would overwrite.  I began to get a sense that Syncables was more of a glossy product, designed for people who wanted simple and trouble-free synchronization without necessarily having an option to scrutinize every step of what was happening.  Having been burned by the occasional backup program that would not save (and would also not tell me that it was not saving) files of a certain kind, or nested too deep, or had an umlauted character in their filenames, or were otherwise secretly exempt from what I thought was happening, I had become more inclined to use transparent software.  At least until I gained a lot of trust and experience with a program, I wanted to see what it was doing.  So this feature of GoodSync appealed to me.  I noticed, also, that a review described Liuxz Sync as being "of most use to users that need to carryout real time synchronizations over a network or between hard drives."  As I continued to look at other opinions, ViceVersa still sounded relatively good too.

On this basis, I decided to start with GoodSync, as described in a separate post.  After some days of using it, and comparing its results against an external backup drive via manual comparisons using Beyond Compare (as described in more detail in that other post), I concluded that GoodSync was a good product for this purpose.  I set its sync rules so as to check most frequently those partitions in which I was most likely to make changes.  For practical purposes, I could change files on one computer and I would see those changes on the other computer when I went looking for them.

In short, I wound up using GoodSync to synchronize files on two computers on a home network.  The files were generally available on the other computer within minutes.  I did this without using a server.  That is, the files were available locally on each computer, so that I could keep right on working if the other one went down.  I arranged backup via external drive, and I occasionally checked that external drive against the internal drive manually using Beyond Compare.  I had better performance than on a network, and was not very vulnerable to network problems; presumably I could have set up the same arrangement via crossover cable, without even having a router.  This really felt like a solution that I had been seeking for years.

Windows 7: Scaling Back the Ambitions

I was installing Windows 7.  I had spent nearly two weeks learning about it and tinkering with some of its possibilities.  I had learned quite a bit, and was impressed with much of what I saw.

At the same time, I was sobered by the prospect of spending additional weeks in this exploration.  It did appear that a commitment of that kind would be required to follow through with the Windows 7 projects I was looking into at that point.  Although this period of almost two weeks of tinkering and exploring had been brief compared to some periods of computer-related investigation that I had experienced in the past, it was still a large chunk of time, some of which I would rather have spent focusing on other things.

I had pulled back from my ongoing Ubuntu exploration, near the start of this project, because of its time requirements and the drawbacks I had experienced with it.  During these past two weeks, I had found that Windows 7, while being a sophisticated operating system, was still not entirely stable.  The plan of building a whole structure of RAID arrays and bootable virtual hard disks (VHDs) on Windows 7 was beginning to look like another indulgence that would continue to demand large amounts of time, not only to learn more about it, but also to maintain and repair it.

Certainly I could work toward setting up a RAID5 array eventually, as need and conditions dictated.  I could stay attuned to developments in the area of VHDs.  No doubt I would continue to refine my system in various ways.  But for purposes of my primary scholarly work, as distinct from various other projects of secondary interest, it was not essential to have RAID0 performance for my data partition or, with the aid of a bootable VHD, for my Win 7 boot partition.

As I pondered these thoughts, it seemed that my pullback from Ubuntu, a few weeks earlier, had been a sign of a change of direction with the arrival of the new year.  I liked improving my system and learning about these things.  Indeed, I believed I would like those sorts of activities more, if I approached them less ambitiously, with more patience to learn about and explain an occasional system development.

I still had some issues to work through, to achieve the more ordinary functionality that I did need.  Even those issues had the potential to consume another week or more.  But in the big picture, I felt that the time had probably come to scale back my system plans.  Accordingly, I decided to focus, perhaps for the coming year, on improving aspects of my system that seemed most crucial, particularly in the areas of reliability and trouble-free functionality.

Installing RAID 0 in Ubuntu 10.04 (Lucid Lynx)

In a previous post, I was working toward having a dual-boot Windows XP and Ubuntu 10.04 system, with a RAID 0 array for at least the Ubuntu installation.  Here, I describe the process I went through to set up that array.  I had previously had a WinXP/Ubuntu dual-boot system on a single Western Digital Velociraptor drive; the main change here is adapting that to the RAID scenario, and seeing whether this would be faster.

I started with a very helpful video by amzertech.  (Actually, two videos.)  I have provided a detailed description of the process (below).  To summarize, I had to boot the alternate Ubuntu CD and use it to install root ("/") and swap partitions on each drive in a RAID format, along with a /boot partition on one drive.

Troubleshooting

It all seemed to go pretty smoothly, and certainly other people seemed to have had good luck with that video.  But when I was done and I tried to boot the system without the CD, I got "error:  no such disk" and then a "grub rescue" prompt.  And in the FastBuild Utility discussed in the previous post, I was no longer seeing two drives configured into one logical disk set; they were back to being two separate JBOD ("just a bunch (or a box) of disks") drives.  So it seemed that what I had done previously was not necessary.

After digging around in a search, I found a post where they said the problem got solved for them by undoing the BIOS edits I described in the previous post.  So I rebooted, hit Del, went into the BIOS > Integrated Peripherals and set the OnChip SATA Controller to Disabled.  This greyed out the other two items that I had changed and put them back into their previous settings.  I saved and rebooted.

This time, I got "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER."  A search led to a Tom's Hardware thread where they advised, among other things, adjusting the boot order in the BIOS.  So I tried setting the hard drive to boot first, instead of the CDROM drive.  But I got the same error again on reboot.  That thread contained many other suggestions:  update your motherboard's BIOS, make sure all cables are firmly connected, disconnect all other drives, use other software (e.g., Disk Boot Manager), check that the jumpers on your hard drives are set correctly (at least if you're using PATA drives, which I wasn't), fiddle with BIOS settings, etc.

The BIOS update was a possible solution, but I began instead by rearranging cables a couple of times.  My goal there was to match up the hard drive on which I had installed the /boot sector (I didn't know which of the two it was) with the lowest-numbered SATA connector on my motherboard (i.e., SATAII0 as distinct from SATAII1, SATAII2, etc.).  But that didn't do it either; still the DISK BOOT FAILURE message.  I also tried going back into the BIOS and setting Hard Drive as the first, second, and third boot options.

Following some other suggestions, I went back into BIOS and enabled the OnChip SATA Controller as Native IDE type (even though they were SATA drives).  This gave me a new error:  "MBR Error 1.  Press any key to boot from floppy."  I tried reversing the cables, in case I had the drives in the wrong order.  And that did it.  Success!  Ubuntu booted.  I restarted the computer, set the BIOS back to boot first from USB, second from CDROM, and third from hard drive (as it had been previously), and thus verified that the solution seemed to be as follows:  set BIOS to Native IDE type, and make sure the drive with the /boot partition is connected to the first SATA connector on the motherboard.

Assessment

In Ubuntu, I went into Synaptic and installed GParted.  I took a look at what had happened.  I had used two 640GB drives for my RAID 0 array.  In an earlier time, this would have been extravagant.  By now, however, prices on such drives were in the basement.  But I did still wonder if I could use the rest of these drives for some other purpose.  I had allocated an absurdly large 100GB space (50GB per drive) for my root partition -- leaving a total of more than 1TB unused!

So now, in GParted, I saw three drives:  md0, sda, and sdb.  md0 was a net 93GB, with no further information.  sda essentially had the partitions I had set up in the RAID setup process:  the root partition, the /boot partition, the swap partition, and about 540GB left over.  sdb had its own matching root and swap partitions, though they were labeled as having an "unknown" file system, and a matching 540GB unallocated.

More RAID Partitions

Could I use that 1TB of unused space?  I wouldn't have put my data there -- RAID 0 had twice the risk of data loss, in the sense that either drive's failure would take down the array -- but there were some other possibilities.  In particular, I could store my VMware virtual machines (VMs) there, as long as I kept backup copies elsewhere; they would run faster on the RAID array.  And I also wanted to set up a separate /home partition.  But should I have created these partitions while I was going through the initial RAID setup?  And could I store anything on just one hard drive or the other, or did everything on these two drives have to be set up in a RAID format now?

I decided not to research the option of storing things on just one drive or the other at this point.  Apparently it was possible, and could even be done after the fact from within Windows XP.  Since there would be a lot of completely unneeded empty room left over after this RAID installation, I would just let it sit on the drives as unformatted space for the time being.  But for the VMs and anything else (video editing files?) that might call for the performance of RAID 0, I decided that I did want to make use of some of that space.  And I wanted it to be in separate partitions, for backup purposes, not part of the Ubuntu RAID installation mentioned above.  I figured the contents of these partitions would change more frequently and would require a different backup schedule than what the root program installation would need.

RAID 0 Setup:  Detailed Description

So now that I had my BIOS and my drives and everything else in order (above), I restarted the process of setting up the RAID 0 array, and this time I took notes.  I booted the alternate CD and went into Install Ubuntu.  I went through the initial setup options (language, keyboard, etc.).  When it got to the partitioning screen, I chose Manual.  Now I saw that, actually, I didn't have to undo what I had already done.  The 100GB RAID 0 device I had already set up would be just fine.  I could just arrow down to the FREE SPACE items and add stuff there.

So I did that.  For each of the two drives (sda and sdb, on my system), I selected FREE SPACE and hit Enter > Create a new partition > 50 GB (giving me 100GB total) > Continue > Logical > Beginning > "Use as" > "physical volume for RAID."  Then I chose "Done setting up the partition."  Then, back in the Partition Disks screen, arrow up and hit Enter at "Configure software RAID" > Yes.  Next, Create MD device > select the two items shown as 49999MB (i.e., about 50GB) > Continue > Finish.  This put me back at the Partition Disks screen again, but this time I had a new RAID 0 device of 100GB.  I selected that device, hit Enter > Use as > Ext3 (more reliable than Ext4) > Enter.  I set the mount point to /home and the mount options to relatime and labeled it UHOME.  Then I selected and hit Enter on "Done setting up the partition."  I repeated this process, starting by selecting FREE SPACE, and created another pair of 200GB logical partitions that I labeled as RAIDSPACE and set it to mount as /media/RAIDSPACE.  My VMs would go on a folder in this partition.  I still had 700GB left over, but at least I had made a stab at converting some of that unallocated space to a useful form.

I noticed, in this process, that my previous root partition was no longer set as root.  I configured it again.  Now, when I went to Configure software RAID, it seemed that Ubuntu was going to be reinstalled there.  I went ahead with that.  With those changes made in the Partition Disks screen, I arrowed down and selected "Finish partitioning and write changes to disk" and hit Enter.  It gave me an option of formatting the root partition, but since I had already installed Ubuntu there, I didn't want to do that.  This put me into an empty blue screen for a while, but then it began installing the base system.  So maybe I should have let it format the root partition after all.  It went through the installation process and then told me that this seemed to be the only operating system on this computer and asked if it was OK to install the GRUB boot loader to the master boot record.  I said yes.

When it was done, it went into Ubuntu.  I reinstalled GParted and took another look.  It looked like I might have done something wrong.  The only md device was md0, the 93GB partition from before.  It did show the UHOME and RAIDSPACE partitions on sda, with matching Unknown partitions on sdb, all with RAID flags next to them.  Nautilus showed RAIDSPACE as a legitimate partition with 348GB free (19 GB used already!).  But no, everything seemed OK.

Bringing Stuff Over to the New Installation

I shut down the machine, connected a disk containing files from my previous system drive, booted with a live CD, and copied some things over. Specifically, I installed a third hard drive and, while booted with the live CD, used GParted and Nautilus to prepare a partition on it and then copy over all of the files from my previous machine's Windows XP installation.  I tried to copy the /home partition from my previous installation, to replace the contents of the /home partition in the RAID array, but the array was not accessible from a live CD boot.  So I copied the previous /home folder to that newly installed third hard drive.  (I knew that the previous system drive was bootable, so I would not start the system from a hard drive (i.e., without a live CD) while that one was connected, lest it screw up my new installation.)  I got an error message for just one file, a Google Earth file:  "Can't copy special file."  A "special file," according to Andreas Henriksson, was something like a pipe, device node, or socket.  I would be reinstalling Google Earth anyway, so this was no problem.

When those copy operations were done, I disconnected the previous drive and rebooted from the hard drive, this time with an external USB drive connected.  The external drive contained my previous fstab and some other materials that I needed now, as I began to work through the Ubuntu post-installation adjustment process described in another post.

The first step of that process required some adjustment for the RAID situation.  The /home partition in the RAID array wasn't available via live CD.  So I tried the technique of commenting out the regular fstab line for /home and replacing it with a reference to /dev/md2 (where the home partition was to be) and /home_tmp (instead of home).  I typed "sudo mkdir /home_tmp" and then rebooted.  Now, if all went well, the system would think its /home folder was in /home_tmp.  On reboot, I typed "sudo Nautilus," went into /home (not /home_tmp), deleted its "ray" folder (my username), and replaced it with a copy of the "ray" folder from my previous installation.  Then I typed "sudo gedit /etc/fstab," deleted the line referring to /home_tmp, and rebooted.  Then, in sudo Nautilus I deleted /home_tmp and rebooted once more.  All was good:  my settings from the previous setup were back.

I proceeded through the remaining steps to configure my new Ubuntu installation, as described in that other post.  The RAIDSPACE partition was not available to me as a normal user, but I wanted it to be, so I typed "sudo nautilus," right-clicked on RAIDSPACE, and changed its permissions.  Then I copied my VMS from the external drive to a VMS folder in RAIDSPACE.  I was getting an error message on reboot, "Ubuntu is running in low-graphics mode," when it did not seem to be.  Also, I noticed that the GRUB menu was no longer remembering the operating system that it had last used; it was defaulting to Ubuntu in every case.  I was not the only one who had this problem in RAID.  But otherwise, the previous post pretty much covered the adjustments required to get my system back to normal.

As mentioned above, I had copied over the Windows XP files from what used to be my system drive to the third hard drive now installed in this computer.  When I ran "sudo update-grub" to consolidate the changes I had made to the GRUB2 menu while making those adjustments, it said, "Found Microsoft Windows XP Professional on /dev/sdc1."  GParted said that sdc1 was the right place -- it was the NTFS partition to which I had copied those files.  I wondered if just copying WinXP files from one drive to another in Ubuntu was sufficient to create a working WinXP installation in the new location.  So now I rebooted and, in the GRUB2 menu, I chose Windows XP.  And, what do you know, it worked!  Just like that.  No GRUB errors or anything.  I had to adjust a few settings in WinXP, but for the most part things were in good shape.

The Acid Test

So that seemed to pretty much wrap up the process of converting my dual-boot WinXP/Ubuntu system from a single hard drive to a RAID 0 array.  I was sure there would be other changes to come, but it was time for the acid test:  I wanted to see how VMware Workstation performed in the RAID 0 environment.  It had been dragging, functioning very slowly for a long time, in the computer that this one was going to replace.  It had run more quickly on this replacement computer in the single hard drive setup.  No doubt the Velociraptor helped.  But how did it do in the dual drive array?

Let me say, first of all, that the general startup process in Ubuntu was darn snappy.  I noticed it right away.  Boom! my startup programs all came to life pretty smartly.  Inside VMware Workstation, likewise, performance seemed faster than it had been in native WinXP on the Velociraptor.  I was sure there would be much additional learning, but this had been a real step forward.

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.