Saturday, July 31, 2010

VMware Workstation, Ubuntu Host, Windows XP Guest: Automated Way to Map Network Drives

I was using Windows XP virtual machines (VMs) in VMware Workstation 7 on Ubuntu Linux.  I wanted to automate the process of mapping network drives.  I typically used the Map Network Drive technique in Windows Explorer for this purpose.  It appeared possible to automate this with a registry edit, but apparently a  more typical and robust approach was to use the "net use" command.

The net use command could be entered from the command line.  I was more interested in saving it in a batch file that I could apply to multiple network drives and could re-run anytime without having to remember or research the proper syntax.  Microsoft seemed to say that, for my purposes, the command to map a network drive would look something like this:

net use d: "\\vmware-host\Shared Folders\DATA" /persistent:yes
where DATA was the name that I had given to the drive in Ubuntu.  This resulted in an entry in Windows Explorer that read, "Data on 'vmware-host\Shared Folders' (D:)."  I was not able, at this point, to automate the process of right-clicking and renaming that to be simply "DATA."

I combined several of those commands in a batch file.  A batch file was just a file created in Notepad, with one command on each line.  I also included a comment, in case I wanted to write an "undo" batch file.  The line just shown, made permanent and accompanied by that comment, looked like this:
net use d: "\\vmware-host\Shared Folders\DATA" /persistent:yes
; to disconnect, use this (I think):  net use d: "\\vmware-host\Shared Folders\DATA" /delete
I saved that batch file in the folder containing my various WinXP installation materials.  So then, for future installations, all I had to do was to double-click on that batch file in Windows Explorer, or start it from the command line or from another batch file, and my drive mapping would proceed automatically.

Thursday, July 29, 2010

WinXP: You Must Be Logged in as an Administrator When Installing This Program

In a new Windows XP installation, I ran into a situation where my system was running really slowly.  To fix that, I tried to install a program called Advanced Windows Care (AWC).  That program had been superseded by Advanced SystemCare, but for some reason (price or performance, I dimly recalled, but I wasn't sure which), I had decided not to take the upgrade.  I was trying to install AWC as part of a new Windows XP installation.  When I tried to install it, I got an error message:

You must be logged in as an administrator when installing this program.
But I was!  I went into Start > Run > control userpasswords2 and observed that my username, Ray Woodcock, was a member of the Administrators group, just like the Administrator itself.  But according to Philip's SpeedGuide, writing on another issue, being in the Administrators group was not the same as being an (or should I say The) Administrator.

I didn't have the option of logging in as Administrator.  When I booted up, my startup screen showed only the Ray Woodcock username.  To add the Administrator on that opening page, Astrahost advised a registry edit at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList to add a DWORD named Administrator with a value of 1, followed by a restart.  That worked -- I did have an Administrator account to log into now -- but I still got the same error message.  I checked -- I was definitely logged in as Administrator -- but Advanced Windows Care didn't think so. 

I verified that this was not just an AWC issue.  I tried installing another basic utility, known as Bulk Rename Utility, and got the same message:  "You must be logged in as an administrator when installing this program."

I got a clue from Marcin, who said this:
If the [computer] is a member of a domain, then settings applied via Active Directory GPOs will take effect even when [it] is not connected to the network. Is this the case? If so, you would need to make the computer account a member of a workgroup (i.e. remove it from the domain) in order to be able to modify the local password policy.
Pursuing a search along these lines, I heard Dave suggest that I try Control Panel > System > Computer Name > Change > Member of Workgroup.  But that was already how it was set.  While switching between accounts, though, I noticed that the slowness existed only in the Ray Woodcock account, not in the Administrator account.  So I went into the Administrator account, hit Start > Run > control userpasswords2, selected the Ray Woodcock account, and clicked Remove > OK.  The dialog closed.  I went back into it and the Ray Woodcock account was still there.  I did it again.  This time, I got a message saying, "Ray Woodcock will no longer be allowed to use this computer."  Taking that as proof that computers are not yet smart enough to control the world, I clicked Yes.  That didn't solve the problem of not being able to install AWC, but it did solve the problem of having a slow Ray Woodcock account.  I decided to just use the Administrator account for now.  It was still somewhat slow, but at least it was functional.

To install a program that requires the installer to be logged in as Administrator, Richard Harper suggested (for Vista) that you right-click on the program to be installed and click "Run as Administrator."  There was no option in XP, and anyway, I was already running as administrator.  Carpetfresh indicated that the problem also arose in Windows 7, and the suggestions offered in that case seemed to have been things that s/he had already tried.  After reviewing some other discussions that did not seem to be drawing much attention or producing clear solutions, I decided to take the advice of Buckdog05:  it was unsettling to have a new Windows installation be already showing difficult problems, so I decided to start over.

I tried a repair installation (insert the Windows installation CD, proceed toward installation, but then choose repair rather than a fresh installation).  This seemed to make little practical difference, though; the system went through a more or less complete new installation process, complete with the requirement of entering the Product ID during installation and then of activating the installation.  But then I saw that Comodo Fireway and Avast antivirus were still installed, so plainly it was different from a new installation in some ways.  Unfortunately, the repair installation did not fix the "You must be logged in as an administrator" error -- even though there was now only one Administrator account, and that's what I was logged in as.  So I tried again, this time doing a complete reinstallation from scratch (i.e., not a repair installation).

After doing the complete reinstallation, including (this time) a decision to delete the Ray Woodcock account and make sure that everything was being installed in the Administrator account, I tried again to install AWC.  This time it installed with no problems.

Wednesday, July 28, 2010

Resizing Virtual Disks in VMware Workstation 7.1 for Linux

I was running Windows XP guest machines in VMware Workstation 7.1 on an Ubuntu Linux 10.04 host.  I had created a new WinXP guest, called Master, and I wanted to tinker with it.  I ran into some problems.  This blog records the situation.

Taking VMware's advice, I created the new WinXP guest with a size of 40GB.  This turned out to be too large for present purposes.  I wasn't sure I would ever install that much software in it.  Meanwhile, it consumed a lot of disk space and took a long time to load.  I could have just deleted it and started over, but I had already installed a bunch of software in it before coming to this insight.  So I wanted to shrink it.

In case something went wrong, I cloned it inside Workstation.  The name of the clone was Reference--Master.  Then I proceeded to figure out how to shrink the clone.  On my first try, I used Workstation's VM > Settings > Hardware tab > select the Hard Disk > Utilities button > Compact option.  But then I read somewhere -- probably in the VMware Workstation 7.1 User's Manual -- that this only worked if you had not preallocated the space for the virtual drive.  I thought I had done so, but then I got an indication that I had not.  But apparently I had, after all; the disk seemed to have been shrunk.  The problem there was that they shrunk it all the way down.  I had actually hoped to specify a size somewhat larger than its present size, so as to allow space for additional programs.  But I didn't know how to do that, and I also didn't know how to grow the clone to a somewhat larger size.  So I deleted that clone and started over.

On my second try, I looked into what the User's Manual (p. 254) called the VMware Virtual Disk Manager (VDM).  They said it was a Workstation utility.  They directed me to the Virtual Disk Manager User's Guide for more information.  It said (p. 12) that, in a Linux host, I should execute commands that would mount the VM, wipe its free space, unmount it and then shrink it.  I went through this process; but as far as I could tell, this was just a more complicated way of doing what I had already done with the Compact option (above) in Workstation's built-in utilities.  Having shrunk the VM down to around 11GB (as distinct from the 17GB I wanted), I tried the Expand utility; but again, it wouldn't let me specify anything smaller than 40GB, the original excessive size I had assigned to the VM.

Luis Rocha said that the solution was to go into the Hardware tab, select the hard disk, click the Add button, specify a new hard disk of the desired size (in my case, 17GB) there within the same folder as the existing hard drive, use GParted (or some other tool) to resize the logical partition of the previous hard drive, so that it would fit onto the new disk.  This step was actually a bit more complex than Luis let on.  To run GParted (or any other bootable CD) within VMware Workstation, you had to boot the CD before Workstation was able to fire up the installed virtual machine.  I decided to try this with an Ubuntu 10.04 live CD, which contained GParted.  I inserted the CD into the CD drive.  Then, in Workstation, with the VM powered off, I made sure that the Hardware tab indicated that the CD/DVD drive was set to "Connect at power on" and "Use a physical device" (though I was intrigued by the "Use ISO image" option).  With my finger on the Pause key (top right corner of most keyboards), I powered on the VM; clicked on the screen as soon as it went black (so as to switch from Workstation's fist-like cursor to Windows's arrow cursor); pressed the Pause key as soon as the vmware logo appeared; and then read the options.  Per the advice of Peter_vm, in Ubuntu's Terminal I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

bios.bootDelay = "10000"
and that bought me ten seconds instead of one or two, when that vmware logo came up.  So now, when I restarted, I saw this at the bottom of the screen:  "Press F2 to enter SETUP, F12 for Network Boot, ESC for Boot Menu."  I decided to set my virtual BIOS so that it would always check for a bootable CD first.  So I hit F2 and then, in the virtual BIOS, I went to Boot, went down to CD-ROM drive, and hit the + key until it moved to the top of the list.  Then F10 to save, exit, and restart.  The system went into WinXP anyway.  I went to Start > Turn Off Computer > Restart.  It still came back up in WinXP.  I tried again, this time turning it completely off instead of choosing Restart.  It came back up in XP again, so I did the bootus interruptus procedure again, this time choosing the Boot Menu.  No problem there -- it was still set to boot from the CD first -- but still no actual boot from the CD.  I swapped out the Ubuntu CD in favor of an actual GParted CD and did another complete shutdown and restart.  And that worked.  Not sure why the Ubuntu CD didn't, but whatever. The GParted CD took a long time to boot -- maybe 15-20 minutes.  At a couple of points, I thought it was hung up, but no, it was just incredibly slow.  But then, when I did get a GParted screen, it was basically unresponsive.  It would show me the different partitions, but it would not accept any commands to do anything with any of them.  Maybe it was still just being slow, but this was slowness to the point of nonfunctionality.

Ultimately, I powered it off and deleted Reference--Master.  Taking a different approach, I recalled seeing indications that VMware Converter might provide an easier way to do some things related to the kind of process I was undertaking.  So I powered up Master, the original VM, and installed VMware Converter 4.0 (freeware) on it.  In Converter, I clicked on "Convert Machine" and specified the "Powered-on machine" > "This local machine."  The selected destination was "VMware Workstation or other VMware virtual machine."  I was able to specify a target size of 17GB.  Before I could proceed, though, I saw a banner message across the top:
Warning: Unable to locate the required Sysprep files.  Please upload them under 'C:\Documents and Settings\All Users\Application Data\VMare\Vmware vCenter Converter Standalone\sysprep\xp' on the Converter server machine. See 'Help' for more details.
Help didn't actually give me much additional information, beyond a repeat of that indication of the Sysprep file location.  I clicked Back, so that maybe Converter would search again after I located and installed those files.  It turned out that I had worked through some sysprep issues a year earlier, so I just went through that procedure again.  The only real difference was that, instead of copying setupcl.exe and sysprep.exe to C:\Sysprep, I copied them to the location specified in the foregoing quote.  I went through the rest of the Sysprep process and I guess I must have completed the Converter process, because the system did something or other and then shut down.  When it restarted, for some reason I was looking at a "Welcome to Microsoft Windows" screen, as though this were a new installation.  I played along with it.  I accepted the license agreement and entered the product key.  It defaulted to MASTERVM as the name of the computer, just as I had entered it into VMware Converter.  I wasn't sure how to answer some of the questions.  A search led me to a tutorial video and other sources, including one in VMware's Knowledgebase, regarding the step-by-step conversion process.  When the Windows setup process asked, "Will this computer connect directly to the Internet?" I ran a search but got surprisingly few hits and no clear answer, so I chose No. 
And then I was in Windows XP, and the first thing I got was this:
setup50.exe - No Disk
There is no disk in the drive. Please insert a disk into drive D:.
I clicked Cancel, but it came back.  I tried several times.  I tried Continue; same thing, and likewise for the remaining option, Try Again.  I noticed that the box in the upper right corner of the screen said this:
Personalized Settings
Setting up personalized settings for:
Outlook Express
and I noticed that the name of the program kept changing, and so did the error -- it had started out as set50.exe, but went on to shmgrate.exe and others.  So evidently we were stepping through dysfunctional installation of standard WinXP programs.  At some point, with one of those error messages still on the screen, I ran a search and got the idea to start Computer Management (Start > Run > compmgmt.msc).  There, I clicked on Storage > Disk Management.  This opened the Initialize and Convert Disk Wizard.  But that only initialized a 4GB drive that I had previously added to hold my VM's paging file.  Worse, Computer Management showed that drive C in this VM was still at 40GB.  It also appeared -- horrors -- that the name of this VM was Master.  Had we just screwed up my original VM?  It seemed so.  I shut down the VM and consulted reality.  What I found, on the disk, was no new VM and no converted VM.  Very confusing!  I restarted the Master VM.  No weird errors this time.  But the system was still as I just said:  no sign of any new VM.  So, OK, so much for that.  But I had no idea what had just happened.

Back to the drawing board.  How could I get that 40GB drive down to 17GB?  GParted was really the sensible solution, but why wasn't it working for me?  I thought about trying to boot from UBCD4Win or some other such tool, but then decided to try the approach of booting from an ISO.  I didn't have one on my hard drive, so I began downloading another Ubuntu live CD.  Or at least I tried to.  My Master installation was not interested in downloading anything in Firefox, and it wouldn't even start Internet Explorer.  It seemed I had a preliminary answer to the question of whether the Converter process had screwed up my system.  I say "preliminary" because there had been some less-than-snappy performance previously -- the new installation had not seemed perfect -- but now it was responding *very* slowly.  It also seemed not to want to recognize my data partition anymore.  I was afraid it might have wiped it out entirely, and dropped out to Ubuntu to make sure it was still there.

Well.  There were lots of problems here.  I was not confident that this Master installation was going to be a solid start for a new system.  What made more sense, I decided, was to start a new VM of the desired size, and give up on this concept of resizing the virtual disk in VMware Workstation.  Not to say it couldn't be done; it just wasn't working well -- and since the resulting machine wasn't too impressive anyway, it was OK to just start over.  A drag, I mean, but the best choice in a bad situation.

Monday, July 26, 2010

Windows XP: Administrator Lacks Administrative Rights?

I had been using a Windows XP SP3 installation for months.  Suddenly, on booting up, I got this message from Kodak EasyShare:

You are running EasyShare software from a user account that does not have administrative privileges.  As a result, you may not have access to some of the pictures on your computer and some of the features of the software may not be available.  For more information please go to the EasyShare support web site at
They lost me at the first sentence.  According to Start > Run > control userpasswords2, the Ray Woodcock account was a member of the Administrators group, and no other, and that was the same for the Administrator.  That is, I should have had the same privileges, when logged in as Ray Woodcock, that I had if I would log in as Administrator.  But it was not simple an EasyShare problem.  Suddenly I was also unable to move or delete files in the My Documents folder.  Attempting to do so would give me this error message:
Error Deleting File or Folder
Cannot delete [filename]: Access is denied.
Make sure the disk is not full or write-protected and that the file is not currently in use.
So it seemed to be a situation in which Ray Woodcock had administrative privileges, and yet did not have administrative privileges.  If it had been just a matter of deleting unwanted files that WinXP did not want to let me delete, I would have used one of the several methods for working around that.  (My own favorite was to run Windows XP within a virtual machine, running on Ubuntu, and just drop out of WinXP and use Ubuntu to delete or move the files in question.)  But the simultaneous arrival of the Kodak EasyShare message, which I had not seen before, suggested that I had a bigger problem.

I used Notepad to create a plain text file in a different folder, and then tried to delete it.  That worked.  I tried the same thing in the problematic folder, and that worked too.  So I could delete .txt files in that folder, but not .exe files.

I noticed that Windows Explorer was not automatically updating or refreshing itself when I created or deleted those files; I had to hit F5 to refresh manually.  In Start > Run > regedit, I went to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update and saw that, sure enough, the UpdateMode value was set to zero.  I changed that to 1 and rebooted.  That problem seemed to be fixed; but then it wasn't.  One or two reboots later, it was back.  More generally, Windows Explorer was not responsive when I tried to highlight something.

Something else had changed, too:  my system was now defaulting to log into the Administrator account as well as the Ray Woodcock account (and, weirdly, even the Administrator login produced that EasyShare message about not having administrative privileges).  I logged off the Administrator account and, in the Ray Woodcock account, I went into regedit again, to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and saw that the default user name was Administrator.  I changed that (and also AltDefaultUserName) to Ray Woodcock and rebooted.  Now at least the login part was fixed.  But I was still getting that EasyShare message.

I decided to experiment with creating and deleting different file types in that folder.  It seemed odd that I could create and delete .txt files but not the .exe file that I had tried to delete, in that same folder.  I created a new .txt file and renamed it to be a .pdf file, and then I deleted it.  No problem.  I did the same as an .exe.  I could create the .exe, but I got the "Cannot delete" error when I tried to delete it.  Same thing in another folder.

I tried exploring one of the routes mentioned in that list of deletion methods (above).  This had to do with making sure that I had access rights to a particular folder.  But I did have access rights to the folder; I just didn't have access rights to .exe files.  And anyway, what about that other problem, involving the EasyShare message?

I had just been tinkering with several antivirus and firewall programs, and also with PortableApps.  Since the system seemed to be somewhat screwed up, I decided to restore an Acronis image from several weeks earlier and then reinstall programs and see if I could narrow down the culprit.  As expected, the problem was not there after restoration.  I did not try to replicate the problem, and it did not crop up on its own in the near term.

Windows XP: Some Updates Were Not Installed

I had experienced occasional problems when trying to install updates to Windows XP SP3.  At some point, those problems stopped being resolved and started accumulating.  At the time of writing this post, I faced a situation in which the Microsoft Update webpage told me that I had 47 "High Priority" updates to install, along with seven optional hardware and software updates; and yet, each time I tried to install those updates, I got the messages "Some updates were not installed" and "The following updates were not installed."  I was concerned that these updates might be important for system security and stability.

On this particular day, I had once again sought out advice.  The summary of the steps I took, all of which failed, is as follows:

*   *   *   *   *

*** FIRST TRY ***

6. Make a folder "C:\WUAGENT" (any location/name can be used). Download into it:
   - better yet, read "" and get the proper file there.
7. Start -> Run "C:\WUAGENT\WindowsUpdateAgent30-x86.exe /wuforce".
   - note: this failed for me if the "Automatic Updates" service was stopped.
   - I (RW) had to run it twice to get it to work.
8. In IE run "Tools -> Windows Updates" - perhaps a few times as it rebuilds update stuff.

*** SECOND TRY ***

First, do this:

1. Start -> Run "services.msc" (in Vista, it's Start->All Programs->Accessories->Run)
2. Right "Automatic Updates" and select "stop".
3. Start -> Run "%systemroot%"
4. Delete "SoftwareDistribution" folder and "WindowsUpdate.log"
5. Back in services, right-click "Automatic Updates" and select "start".

Then run steps 6-8, above.

*** THIRD TRY ***

Start > Run > regsvr32 wups2.dll
Then try running Windows Updates.

*** FOURTH TRY ***


*** FIFTH TRY ***

net stop wuauserv
regsvr32 %windir%\system32\wups2.dll
net start wuauserv

*** SIXTH TRY ***

Look at the log file for one of the updates.  Example:
Security Update for Windows XP (KB979309)

Then put that number into the following command:


In my case, the end of this log file gave me this information:
1,297: [PatchFilesFromResponseBlob] returning STATUS_READY_TO_INSTALL
1,313: KB979309 installation did not complete.
1,313: Update.exe extended error code = 0xf201

For guidance on whether the update was installed or not, see: 

Following the advice on that webpage, look up that error code.  See:

That didn't work for me, possibly because I had already obliterated the evidence in previous steps.

Sunday, July 25, 2010

Using XQDC X-Setup Pro in Windows XP

According to Tex and Eric, the bankruptcy of WUG has ended that organization's sponsorship of X-Setup Pro, a Windows tweaking utility.  Their message ends as follows:

You can still download the last version from MajorGeeks or BetaNews. The portable edition and the U3 version are available from MajorGeeks as well.

In case you lost your serial number use this one instead: XSA092-11TA9R-8K12YT
I had used this program years earlier.  I now installed and tried to run it in a Windows XP virtual machine (VM) in VMware Workstation 7.1 on an Ubuntu 10.04 host.  When I clicked on the "Classic" button, it immediately presented me with this error message:
C:\Program Files\X-Setup Pro\bin\xqdcXSPUI.exe (/START): Access is denied. (Win32 Error Code 5)
A search for precisely that error turned up nothing.  In a modified search, I saw an indication that "Access is denied" and "Win32 Error Code 5" mean the same thing.  Before researching that further with a refined search, it occurred to me to see whether it would happen again.  This time, clicking on Classic raised a Comodo Defense+ (firewall) dialog asking me if it was OK to proceed.  Allowing that, and another two or three after it, solved the problem:  the X-Setup windows opened.

I wondered whether X-Setup superseded Tweak UI.  Laptop (magazine?) rated X-Setup more highly than Tweak UI; but they observed that novices can get lost in X-Setup and may find Tweak UI more suitable for their needs.  My recollection, circa 2001, was that I had hosed my system with X-Setup once or twice.  I decided to use both for a while.  Following the tip from Tex and Eric, and consistent with a current effort to make Windows XP perform better in VMware Workstation, I decided to try using the portable versions of X-Setup and Tweak UI.

The most interesting feature of X-Setup, for me, was its Record function.  This feature made it possible to create distinct .reg files for each registry tweak.  So I could pick and choose the registry edits I wanted to use this time, and could run their "undo" counterparts if I didn't like the effects.

The explanations of various options in X-Setup were surprisingly articulate and lucid.  Those explanations did not conceal some degree of confusion in the structure of X-Setup tweaks, however.  There was redundancy; there were instances when I thought I had changed something and then came across something that looked very similar but yet had not been changed.

While there was no denying that X-Setup had a large number of tweaks, I found that they did not cover some registry edits I would have liked to see.  The authors readily acknowledged, as well, that some of the tweaks performed by some X-Setup plug-ins would not be captured in .reg files.  I found, in addition, that many of the tweaks I generated from within X-Setup were already set out on the Kellys-Korner and Elder Geek websites, among others.

After running X-Setup and making system adjustments, I found that the new Windows XP installation I had used it on was performing very slowly -- even though I had made sure not to make any changes that X-Setup had flagged as potentially dangerous.  Ultimately, this slowness and other problems led me to wipe my new Windows installation and start over.  I was not sure whether X-Setup was directly to blame for such problems, but I did make sure, the second time around, to proceed with caution.

Despite those caveats, X-Setup Pro did generate a number of useful scripts for me, and when used with suitable caution, it provided very helpful ways of improving my Windows XP installation.

PortableApps in Windows XP

As of summer 2010, a portable application -- what I had been calling a "standalone" program -- was a program that did not have to be "registered" with Windows.  It might not exist on your computer at all until the moment when you would plug in a USB drive containing it, and then you could run it immediately from that drive without having to go through an installation process.  You would also thereby avoid the risk that this would be the straw that broke the camel's back -- the program that would cause Windows to crash.  Moreover, you could thus carry your toolbox around with you, and always have that particular program that you might need for some purpose.  You would also tend to be running lighter software, meaning that a netbook computer might find it easier to run.

Within the world of portable applications for Windows XP (or other operating systems), there was an actual PortableApps (PA) website.  The concept of this enterprise appeared to be that you begin by downloading and installing the PA platform, optionally with a suite of basic programs (e.g., Firefox, OpenOffice), and then you add other portable applications from their directory or elsewhere.

At about the time when I first started paying serious attention to PA, I was in the process of configuring a minimal WinXP virtual machine (VM), and wondered if this way of loading programs would help me to set up a faster and better-functioning VM.  To that end, I decided to err on the heavy side, by installing as many apps as possible on my USB drive.  I had a 4GB Kingston drive available, and if it looked promising I could always buy a larger one.  So, for now, it was a question of what I could get onto that 4GB drive.

I didn't want all of the programs that came with the suites, so I just downloaded the basic platform, along with a bunch of individual apps.  I installed the basic platform in the root of the 4GB Kingston, following instructions.  It took about a minute.  Then, at the end of that installation process, I launched PA.  It seemed to disappear whenever I used the mouse or keyboard, and after each app installation was completed.  So I kept having to go back to re-run StartPortableApps.exe, there in the root of the USB drive.

To install the individual apps, I went into PA's Options > Install a New App and browsed to each of the .paf.exe (PortableApps format) applications that I had decided to install.  There wasn't a batch process option, so I had to sit there and wait through each of these installations, one by one.  I ran into a problem when I decided to delete one of them.  The problem had to do with administrative rights in Windows XP.  It took a couple of hours to sort out.

Some of these apps had multiple features.  I wasn't familiar with all of them.  It appeared likely that, as I did get to know them, others would become superfluous.  Also, many of these apps had their own additional instructions or informational webpages.  I combined them into a PDF and put a copy on the jump drive itself, for future reference.

The user could right-click on a particular app in PA to pull up a menu of options:  Run, Run as Administrator, Rename, Refresh, Hide, Show Hidden Icons, Favorite, Start Automatically, and Uninstall.  I used the last of those with Sumatra PDF, when I decided in favor of Foxit; but when I said to uninstall, I got an error message:  "Unable to uninstall %APPNAME%."  PA's instructions  said I could just use Windows Explorer to delete the item, followed by the Options > Refresh App Icons menu option in PA.

These difficulties were overshadowed by a much larger problem.  At one point, I took the jump drive out of my computer and tried running it in another computer.  That computer had a different kind of antivirus software than mine.  I think it may have been McAfee.  Whatever it was, it decided that the PortableApps platform was malware, and promptly deleted it.  Presto!  The sleek interface was gone.  The antivirus software also wiped out a couple of individual apps within the PortableApps set.

That pretty much ended my use of  Instead, I switched to a different portable applications setup, one that was not quite as slick but was much more robust.

Tuesday, July 20, 2010

McAfee Quarantine -- What's In There?

I discovered that McAfee VirusScan seemed to be putting large numbers of files with a .bup suffix into folders called C:\QUARANTINE and E:\Cache\McAfeeQuarantine.  (The location of the latter was no surprise; I had set aside E:\Cache for miscellaneous folders.)  I wondered what was in these .bup files; and if they were things that I did not want to be quarantined, I wondered how I might retrieve their contents.  I tried to open them by double-clicking on them, but I got this message (in Windows XP):  "Windows cannot open this file."

Apparently there was supposed to be a McAfee Quarantine Manager program.  I didn't have that.  Actually, I couldn't even tell what I did have.  Normally, I would store the installation program, in case I needed it again, but it wasn't turning up right now.  I suspected that I had gotten McAfee something-or-other installed, for free, during the installation of some other program.

A search led to a McAfee page that seemed to indicate that McAfee Quarantine Manager was a Large Enterprise product.  I registered to receive a free download of the beta version.  They said I would be getting an e-mail within a few hours, but it was actually just a few minutes, and then I downloaded Quarantine Manager.

While that was all in the works, I went to McAfee's main support page.  It did not have links to any knowledgebase, forum, or FAQs.  I clicked on the big Get Support button.  Here, I had options for Tech Support, Customer Service, or Virus Removal.  I chose Tech Support, and that did give me a link to FAQs.  I tried a search there and got several items that seemed relevant.  One, document no. TS100617, "How to recover a file that has been quarantined by VirusScan," advised me to begin by double-clicking the M icon in my taskbar.  I didn't have an M icon; I just had a shield whose tooltip said, "McAfee OAS: enabled."  I double-clicked on it anyway and got "On-Access Site Scan Statistics."  It had no options.  This was different from the picture shown in the document, which showed a screenshot from McAfee Security Center.  Another document, no. TS100843, "How to recover a file that has been quarantined by VirusScan," likewise assumed I had an M icon.

Taking another approach, I tried McAfee's Chat and Email support option.  I started with the Community Forums link, which oddly appeared on that webpage even though a forum is neither chat nor e-mail.  It seemed that I could have gone directly to the forums, if I had had the URL, instead of going through all those other pages.  Once I was there, at any rate, my searches didn't turn up anything on point, so I backed up and tried their free online chat.  I sent them a message.  They replied immediately with this:

Sorry, we don't support your operating system
We currently support Windows 7, Vista, XP, 2000, NT 4.0 and Mac OS X v10.4 Tiger or newer.
I was using Ubuntu to send this message.  So I guess it did not occur to McAfee that someone might use one computer to contact them about a problem on another.  I went into a Windows XP virtual machine on that Ubuntu computer and tried again; but then the web browser I was using (Firefox) crashed there.

While that was developing, I did a search for McAfee Security Center.  This seemed to be a product, or rather part of another product, that I could buy for about $35-50.  I also did a search for the On-Access Site Scan.  Michael Dance at said OAS was a key part of McAfee VirusScan.  My search for that generated the impression that I could download VirusScan and use it free for the first year.  Unfortunately, it seemed that that particular promotion had been active in autumn 2009, whereas it was now summer 2010.

At about this time, it occurred to me that I could check Start > Control Panel > Add or Remove Programs and see what, exactly, I did have.  And well, lo and behold, it seemed I had McAfee Agent, McAfee AntiSpyware Enterprise, and McAfee VirusScan Enterprise.  No shortcuts to anything like that in my Start Menu, though.  I went into C:\Program Files and didn't see much; but then I noticed that there was a newish C:\Program Files(x86) folder whose only contents were a McAfee folder.  There, in a VirusScan Enterprise subfolder, I found 22 Application-type (i.e., .exe) files.  I tried double-clicking on mcadmin.exe, but nothing happened.  I tried mcconsol.exe, and that opened the VirusScan Console that I had been able to open by right-clicking the shield icon in the taskbar; but that Console still didn't have any more relevant options than it had had earlier in the day, and most specifically it seemed useless for purposes of finding out what was in those .bup files in McAfeeQuarantine.  I clicked on most of the other executables in that VirusScan Enterprise subfolder and still got nothing.  Nor did a search for files or folders with McAfee in their name turn up anything interesting.  Somehow, it seemed, I had gotten a sort of ghost version of McAfee VirusScan on my PC.

I decided to move the .bup files from C:\Quarantine to E:\Cache\McAfeeQuarantine, so they would all be in one place.  While I appreciated whatever it was that the installed free version of McAfee AntiVirus might be doing on my behalf -- especially an Enterprise version (woo hoo!) -- I was mostly just wanting to get rid of it if I could replace it with something else, not necessarily by McAfee.  I was, in fact, running avast! AntiVirus, and avast! was in fact running a one-year free special.  Anyway, neither was top-ranked, according to TopTenReviews.  The only PC Magazine editor's choice antivirus award in 2010 went to Panda Cloud 1.1 (free).  So really, all I needed was to investigate what was in these .bup files and then bid avast! to McAfee.

By now, McAfee online chat was finally ready for action.  The only place it would run for me, even in the Windows XP virtual machine, was in Internet Explorer; it didn't run in Firefox, and it had to install several different programs before its chat interface would run.  Even then, it was just sitting there, with this message:  "Your representative has arrived.  Thank you for waiting."  I was glad s/he had arrived, but I couldn't tell where s/he was, exactly.  After a while, I killed that window and tried again, and now it worked.  I proceeded to spend a half-hour chatting with Deepu, who had no idea how to view the contents of .bup files.  She was not able to verify my installation, which was what I told her -- that I really didn't recall how this program had gotten onto my system -- and therefore she would not pass the question on to her supervisor.

A couple of days passed, and no more word from McAfee.  By now, that free download of McAfee Quarantine Manager seemed to be the only game in town.  Therefore, I went ahead and tried to install one of the programs included in the download.  But I got, "The operating system is not adequate for running McAfee Quarantine Manager DBSuite."  Same thing when I tried the more modest version:  "The operating system is not adequate for running McAfee Quarantine Manager."  They hadn't warned me about this over at

I never did hear anything more from McAfee.  Basically, they had put several gigabytes of stuff from my computer into their .bup files; they were not going to help me figure out what was in those files; and if I was worried that they might have stuck some data in there along with allegedly infected program files (some of which, I had concluded, were false positives, i.e., guilty until proven innocent).  I had had a prior crappy experience with McAfee, back in the 1990s, and this was probably going to be the end for them, as far as I was concerned.

Sunday, July 18, 2010

Using VMware Workstation; Time to Try VirtualBox?

A year earlier, I had tried using VirtualBox in place of VMWare Workstation as a virtualization solution.  I wondered whether I should try it again now.

I ran a search for recent comments and reviews.  A number of people had good things to say about VirtualBox.  It sounded like it had been progressing well in the year or so since Oracle bought it.  Rob Williams at Techgage listed some pros and cons.  A month after my previous try, an InfoWorld review said that VirtualBox had been gaining ground really quickly.  More recently, just a few months before this post, ZDNet's Jason Perlow did a comparison of VirtualBox 3.2 and Workstation 7.1.  Perlow said this:

In virtually all of our tests, [Workstation] matched or exceeded the performance of Oracle VM VirtualBox. Windows XP and Windows 7 32-bit and 64-bit performance was extremely snappy, and close enough to native that when we were running it in full screen mode, we couldn’t perceive the difference between “On the metal” and virtualized on our test system.
That reminded me that, once again, I was looking at a "professional" review by someone who comes in, tries the software on a fresh system, does their benchmarks, and then closes the doors and turns out the lights -- not sticking around for a few months, that is, to see how the thing holds up in everyday usage and abusage.  Perlow admitted that VirtualBox, not VMware, was his workaday tool.  But for me, by contrast, VMware Workstation 7.1 was huffing and puffing, and it had never approached the performance of a native Windows XP installation.  (Perlow also noted that VirtualBox performed well in his tests, but failed miserably when using Windows rather than Linux as the host.  I was not concerned about that; I would be using Ubuntu Linux as my host.)

These sources reminded me of the issues that had become par for the course in my use of VMware Workstation.  There were quite a few, as readers of my many posts on VMware would know.  One, as just noted, was the slowness.  There were things I couldn't do in VMware, like video editing, because of the poor performance.  Another kind of problem was hardware-related.  While I had worked through many of those issues, as noted in previous posts, there were always others.  VMware would recognize only some USB devices, including my multifunction printer/scanner, and/or would recognize them imperfectly (i.e., permitting only some functionality).  VMware would slow to a crawl if I tried to get it to use multiple processors.  It had originally seemed to handle at least a couple of open VMs at the same time, but more recently would become unusably slow if I had more than one VM open.

On the other hand, I knew that a switch to a new virtualization platform would require some downtime and many hours of tinkering, as well as some lost work in the process of making mistakes and learning how it worked.  I was also curious about what was going to happen with VirtualBox.  When Oracle bought Sun in 2009, some were predicting that this was awful news for open-source projects like VirtualBox.  It may be.  But Oracle has recently come out with a relatively significant new release of VirtualBox.  Before making the leap, I would like to let more time pass, so as to see whether the naysayers are wrong or whether, instead, Oracle was just cleaning out the closet, putting the last of its in-process improvements into production before marking the VirtualBox product for shelving or sale to some other tech company.

A quick check also suggested that transitioning from VMware to VirtualBox would probably entail creation of new VMs from scratch.  While there are surely countervailing opinions, what I got from the first few hits of a search on the matter leaned toward "the Fat Bloke's First Rule of VM Migration," which he stated as follows:  "Don't, if you can help it. If you can create a new vm from scratch on the new virtualization platform, you probably should."  Wand Weaver likewise said that graphics issues made it "tricky to import existing VMWare machines into VirtualBox."

I had other fish to fry.  I was in no rush to get myself into a new mess, dealing with creation of new VMs for VirtualBox at this point.  It seemed to met that the better strategy was to watch and wait, to see whether VirtualBox (or possibly some other virtualization program) would become the champ or would instead fade away.  This seemed especially advisable since a recent effort to free up some space and relocate the paging file in one of my WinXP VMs seemed to have improved performance.  So before dabbling with VirtualBox again, I decided to see what I could do to improve VMware's performance.

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 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 (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 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.