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.

Windows XP SP3 CD Won't Boot

I was trying to install Windows XP on a Compaq Presario CQ60-420US laptop. I had just gotten it back from HP service in Texas, where they supposedly replaced the motherboard to fix a nonworking wired network interface card (NIC). They had reinstalled Vista on it, which I thought was very nice of them, and now the NIC still did not work for purposes of accessing the Internet, but did work for half of a crossover cable connection with another computer. That is, the other computer could access the laptop, but not vice versa.

So I had decided to try to see if WinXP would fare better than Vista on these problems. I wiped out the Vista partition, used GParted to create a new partition, and stuck the WinXP installation CD into the CD drive. Unfortunately, XP would not boot from the CD. GParted had just booted from the CD, so I was pretty sure it wasn’t the drive hardware per se. With the WinXP CD inserted, the computer would recognize that there was a CD in its drive, and would say, “Press any key to boot from CD,” but this just caused the thing to grind away, apparently trying to read and act upon the information on the CD, before eventually (after maybe five minutes) giving me a BSOD (blue screen of death).

I found that this problem occurred with a WinXP CD, containing slipstreamed SP3, that I had used to install XP on another computer; but it appeared somewhat different with an SP2 XP CD.   With that CD, the system went all the way through "Setup is loading files" and said, "Setup is starting Windows" before giving me the BSOD.  Then again, this may have been what was happening when the SP3 CD was grinding away; perhaps it was just not reporting all of the drivers it was loading.

To fix this, one suggestion said to disable BIOS virus detection. But the BIOS did not have a virus detection option. Someone else said laptop CDs are not eager to boot from DVDs, but this was definitely WinXP on a CD.

The BIOS Setup seemed willing to let me try to boot from a USB drive. I wondered if I could install WinXP from a 4GB USB jump drive that I had lying around. To try it, I rearranged the Boot Order so that USB Diskette on Key / USB Hard Drive came first. I wasn’t too sure how to do the rest of this process, so I started by just copying the WinXP CD directly to a 4GB USB drive. While that was underway, I researched the question and found that there were many websites on how to do this, and all of them sounded complicated.

At the same time, I continued trying to figure out what was wrong with the laptop’s DVD drive. One source said that they solved the problem by flashing the BIOS on the laptop. This seemed like a more comprehensive kind of solution, so I decided to try this second – right after inserting the USB drive with a copy of the Windows XP CD and verifying that, no, it wouldn’t install WinXP by itself; booting from that USB drive would just give me “Invalid system disk. Replace the disk, and then press any key.”

It seemed odd that the system would boot a Vista CD but would require a BIOS update in order to boot a WinXP CD.  Or at least it had booted a Vista installation CD previously.  I decided to try that again.  Sure enough, with the Vista installation CD inserted, I got “Press any key to boot from CD or DVD” and then “Windows is loading files.”  I thought about trying to slipstream Vista into a WinXP CD, but got some warnings that maybe this would not be a good idea.

So, continuing with the current plan, I went to the HP-Compaq download page and looked for a WinXP BIOS update for this laptop.  All I saw there was a firmware update named sp43474.exe, for the GSA-T50L optical drive, dated April 2009.  Firefox 3.5.8 wouldn’t download it to my other computer; I had to right-click and use the IE View extension to download successfully.  The problem now was that this update was an .exe file, which I would only be able to install from within a running Windows installation.  Catch-22!

Just to be sure, I double-clicked on the sp43474.exe file on the other computer.  It said, “This software update will upgrade the firmware of your system’s optical drive GSA-T50L to rev SC05.”  I had done a printout to PDF from a system information utility before sending the laptop to Texas, so now I searched it for a reference to this model of DVD drive.  It said that, actually, what I had (at least before sending the laptop to Texas) was an Optiarc DVD RW AD-7561S ATA Device.  This seemed to be made by Sony, whereas the GSA-T50L was made by LG.  I supposed that both might ultimately have been made by the same Chinese sweatshop somewhere, but I preferred to try to find a driver for the Optiarc.  But I was curious why my laptop would have an unofficial CD drive.  I was not able to find any references to the Sony Optiarc AD-7561S drive on the Sony Optiarc page, so apparently it was an older or in some sense unsupported model.  I stumbled across a recent thread in which someone else was tired of hassling with HP, couldn’t find a firmware update, and was at the point of just installing the wrong update to see what would happen.  Same problem in another thread.  I even found a thread on an official HP forum where they were talking about this problem.  As one participant in that last thread said, “There does not seem to be any updates for the 7561s at all.”  So, OK, updating the firmware was not an option; the more likely option was to send the machine back to HP for a replacement, assuming they were willing.  I couldn’t do that now -- I needed the laptop -- so we were back at the option of installing XP from the USB.  I went through a long effort of that nature, but ultimately abandoned it and came back to this post.

While that long effort was underway, I began looking into other possibilities.  One was to adapt an Acronis True Image backup (or you could try Macrium for freeware) of a Windows XP installation from another machine, so that it would work on this laptop's different hardware.  The Acronis option that I would need, to avoid a BSOD, seemed to be Universal Restore, which would apparently cost at least $365 (list).  Alternately, it seemed that OEMs use Sysprep to deploy the same operating system installation on many computers, but it looked like more hassle than it would be worth for just one system.  I also looked into the possibility of installing XP via network connection.  This led me to a site that specialized in boot disks.  I didn’t see how I could use any of that, unfortunately -- at least not without a substantial additional time commitment, which was impossible.

The effort to install XP from the USB did not pan out, so at this point I returned to this post.  There seemed to be two basic options.  Either find a way to develop or adapt an Acronis image from another machine so that it would work on the laptop, or get to a command prompt (via USB drive, network connection, or otherwise) and run an installation command (seemingly something like X:\i386\winnt /s:X:\i386, where the /S switch defines the location of the startup files) to install WinXP from scratch.

I wondered if (a) Windows updates were being designed and revised to defeat the Acronis approach and (b) it would be possible to bail out of a WinXP basic installation before installing many hardware drivers, and make an Acronis image at that point.  I tried that, but WinXP would crash almost immediately; and as with other efforts, it would not boot into Safe Mode either.  I figured that putting the Acronis image on the laptop would at least have installed the I386 folder there, so now maybe it was just a question of getting to a command prompt.  I didn't need BartPE on a USB stick for that; I could boot BartPE from a CD.  I had a CD version of BartPE from 2007.  I guessed it would probably work, since XP was much older than that.  But it seemed that whatever caused the laptop to crash when I had the WinXP CD inserted was also going to reject WinXP as part of a BartPE CD.

I also had an Ultimate Boot CD for Windows (UBCD4Win).  The UBCD ground away for a long time, eventually showed me the WinXP splash screen -- and didn't crash!  Instead, it gave me a choice, "Select shell to start." It still seemed to be in its process, so I waited, and it chose the automatic option for me.  It gave me an option of setting up networking, but I didn't know how to answer the question as to which sort.  I tried to cancel, but it seemed intent upon continuing, so I just used the default options.  I went to Start > Command Prompt and typed DIR C: (using capital letters here just to indicate the actual command; DOS is not case-specific) and, no, the I386 folder was actually not installed there yet.  I put the WinXP CD in the CD drive and typed DIR X: because it looked like X was the letter that UBCD had assigned to the CD drive.  I typed COPY X:\I386 C:\ and it copied files.  Then it froze.  I killed that window and tried running Start > Programs > File Management > Explorers.  None of the explorer programs would run.  Eventually I realized this was because I had removed the UBCD disc.  I put it back in and tried again.  The explorers still didn't work.  I had belatedly realized that COPY was probably not the best command, so I tried XCOPY X:\I386 C:\I386 /E /H /Y.  It copied lots of stuff, and not the way I intended.  Now all the stuff that should have been in the C:\I386 folder was instead in the root (C:\) folder.  Oops.  I wound up deleting it all and starting over.  There were just a few files in C:\ that I couldn't delete (i.e., biosinfo.inf, bootfix.bin, config.sys, and mstask.inf), and of course several folders (i.e., Documents and Settings, I386, Program Files, and Windows).  Problem:  there was no WINNT.EXE file to be found.  On my other computer, it was in C:\I386, but it was not in that folder on either the laptop or the WinXP CD.  I carried it over via jump drive.  It took UBCD a minute to recognize the jump drive, but it did.  I typed WINNT.EXE and hit Enter.  I got this:

Windows XP Setup

This program does not run on any 32-bit version of Windows.

Use WINNT32.EXE instead.

Setup cannot continue.  Press ENTER to exit.

So, OK, I jumped WINNT32*.* over to C:\I386.  (The USB flash drive was recognized as drive G, as I discovered by feeling around.  That is, I tried D: and got a partition; tried E: and got a partition; tried F: and got an error; tried G: anyway and there it was.)  But it froze.  It would copy the WINNT32.* files, but not the WINNT32*.DLL files, not even one at a time.  I tried running C:\I386\WINNT32.EXE anyway.  It gave me an error:

The file C:\I386\WINNT32U.DLL could not be loaded or is corrupt.  Setup cannot continue.

I didn't have that particular one on the jump drive, so I went back to the source machine and tried to jump it over.  But I got the same problem:  the command window froze and had to be killed.  I rebooted the computer with an Ubuntu 9.10 CD and then copied all of the WINNT32*.* files (and a WINNT32 folder) from the source computer to the laptop's C:\I386 via jump drive.  Back in UBCD, I tried running that same WINNT32 command and got that same "could not be loaded or is corrupt" error.  One post suggested this sort of message might be due to insufficient RAM.  A Microsoft webpage said that I should double-click on WINNT32.MSI.  I wasn't in a GUI, so I just tried typing WINNT32.MSI at the command line.  This opened a dialog asking me what program I wanted to use to open this kind of file.

Since I had a command prompt using UBCD, I tried a different approach.  The command I used this time was:

X:\i386\winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource

But this gave me an error, stating that this command was not recognized.  I tried it again, inserting a BartPE jump drive and replacing X: with H: since H was where the jump drive was.  This worked, but it just gave me the same error message I had gotten a long time earlier:

Setup cannot continue because upgrade functionality is disabled and your copy of Windows XP only allows upgrades.

I tried replacing H with C, since I had already copied I386 to C.  This just gave me the message about WINNT32U.DLL being unloadable or corrupt.  One post led me to think that this problem might be unique to my WinXP SP3 disc, so I loaded an SP2 disc and tried winnt32.exe with that.  That did not seem to achieve anything:  the disc spun up and then down and I was back at the command prompt.  I tried it again with the SP3 CD.  Same result.  Apparently I had mistyped the command previously.

I thought maybe I could run winnt if I could find a 16-bit DOS equivalent.  My search led to FreeDOS, where I downloaded FDFullCD.iso.  I burned it and booted the laptop with it.  I indicated that I wanted to boot FreeDOS, and then chose option 3, FreeDOS Live CD with HIMEM + EMM386.  But I got this error:

Selected page frame e000 not available, searching automatically

No suitable page frame found.  EMS functions limited.

I gathered that EMM386 was not a good option in this case.  I rebooted and tried again, this time choosing option 4, HIMEM only.  This produced a bunch of error messages, but at least it put me to an A: prompt.  Drive B appeared to be a RAM drive.  The program did not recognize drive C.  I thought this must be because it was an NTFS drive, but no, FreeDOS did not recognize any drive, including the CD drive.  I booted FreeDOS again, and this time chose option 5, FreeDOS Live CD only.  I still got some error messages, including "There is no CDROM, or the wrong CD-ROM!"

I guessed that whatever kept this CD-ROM drive from recognizing WinXP was also impairing its recognition of the FreeDOS CD somewhat.     In that case, I wondered if I could install the contents of the WinXP CD from a bootable FreeDOS USB drive.  To make that, I followed instructions to install Unetbootin on my Ubuntu machine, and then used Unetbootin to make a FreeDOS bootable USB stick.  When that was done, I checked its properties and saw that Ubuntu indicated the filesystem type was msdos.  I copied the /I386 folder from the slipstreamed WinXP SP3 CD to the USB stick, put the USB into the laptop, and rebooted.  After a Unetbootin screen, I was back at the FreeDOS menu.  I tried option 3; same errors as before.  I tried option 5.  This time, it recognized the USB drive as drive C.  Then I realized that this was no help; it still couldn't see the partition on the hard drive where I wanted to install WinXP.  Well, could I reformat that partition as FAT32?  I formatted another USB drive as FAT32, put it into the laptop, and rebooted from the FreeDOS stick.  It did recognize the FAT32 USB drive.  Now, could I install WinXP on a FAT32 partition?  It looked like it was supposed to be possible.  I pulled out the USB drives, rebooted the laptop with GParted, and replaced the NTFS partition where I had planned to install WinXP with a FAT32 partition.  (I figured this would be much faster than trying to convert from NTFS to FAT32.)  Of course, now I was wondering whether the FAT32 alternative would also have made a crucial difference with some of the attempts to install from UBCD.  When GParted was done, I rebooted with the FreeDOS stick.  Sure enough, now I could see the FreeDOS stick as drive C and the WINXP partition as drive D.  I tried using XCOPY, but it didn't work.  I wasn't sure how to copy subfolders etc. in FreeDOS.  Rather than research it, I removed the FreeDOS USB, rebooted with UBCD, plugged in the FreeDOS stick, found that WINXP was now drive C and the FreeDOS stick was drive G, and therefore used XCOPY G:\I386\*.* C:\I386 /E /H /Y to copy the I386 folder from the FreeDOS to WINXP.  This time around, that ran very smoothly.  I rebooted with the FreeDOS USB stick.  I went into the I386 folder on the WINXP partition (which was drive D in this case), and typed WINNT.  Windows XP Setup asked me where the XP files were located.  It defaulted to D:\I386, so I left it at that.  Next, it said this:

Windows XP Professional Setup

Setup did not detect SmartDrive on your computer.  SmartDrive will greatly improve the performance of this phase of Windows Setup.

You should exit now, start SmartDrive, and then restart Setup.  See your DOS documentation for details about SmartDrive.

I looked into SmartDrive.  Along the way, I ran across the ingenious suggestion that I could use an IDE to USB adapter and, with that, could use the internal CD drive on a desktop computer as an external drive for some other computer (if I had needed to do that).  (This would require leaving the CD drive's power connected in the host computer.)  SmartDrive itself was an MS-DOS disk cache program, to speed up file transfer times.  It appeared that FreeDOS might have its own cache arrangement, presumably faster if I could get HIMEM and/or EMM386 to load.  The best I could do was to reboot, choose FreeDOS option 3, ignore the FreeDOS boot error messages, and continue past the WinXP setup message about SmartDrive.  WinXP setup next said, "Please wait while Setup copies files to your hard disk."  It copied files for a while, and then froze.  I had heard something about how WINNT would only start the process, so I rebooted with UBCD, went into C:\I386, and typed "winnt32.exe /syspart:C: /tempdrive:C: /makelocalsource" and, this time, it worked!  It gave me "Welcome to Windows Setup" and then asked for my WinXP's product key.  I went through the various options, accepting the defaults (including the offer to upgrade my drive to NTFS), and it began the installation process.  It estimated that it would take 52 minutes, instead of the usual 39.  But then something happened.  I turned away, and when I looked back, we were back at the UBCD prompt.  I ran WINNT32 again, just like before, but this time I said No to the option of upgrading to NTFS.  It didn't matter.  I ran it a third time, and again it crashed, shortly after it finished "Copying Installation Files."  No error message or anything.  I rebooted UBCD and tried installing again from the I386 folder that I had added to the bootable FreeDOS USB drive, using the command "G:\i386\winnt32 /syspart:C: /tempdrive:C: /makelocalsource" (because G was where the system saw the FreeDOS USB drive).

So now I wondered whether I could boot to a very WinXP-compatible 32-bit command line.  I started with Vista.  My Vista installation was not booting at this point, probably because I had told GParted to hide the Vista partition, so I inserted the Vista DVD and rebooted.  I went with its Repair Your Computer option but didn't proceed with the repair, choosing instead the steps necessary to get a command prompt.  I inserted the FreeDOS USB and found it at drive H.  But before trying it, I went to C:\I386 and ran that WINNT32 command again.  It proceeded just as it had done in UBCD, except I didn't recall having to agree to the license agreement in the UBCD process.  It crashed -- it put me back to the command line -- just as it had done in UBCD.  I tried again, this time starting from the I386 folder in the FreeDOS USB.  I even swapped out the Vista CD for the WinXP CD, just in case that would make any difference.  It didn't.  Another crash.  I took out all bootable items, rebooted, and got "Disk error.  Press any key to restart."  So, no, it had not by some magic completed the process.

I rebooted UBCD.  On another computer, I copied C:\Windows\system32\chkdsk.exe to a new Utilities folder on the FreeDOS USB.  I plugged in the FreeDOS USB, navigated to C:, and typed D:\Utilities\chkdsk /r.  It ran.  I told it to force a dismount.  It quickly checked files and slowly checked free space.  It found no problems.  I rebooted with GParted and had it check the filesystem on the WINXP partition.  No problem there either.  I wondered if the presence of even a hidden Vista partition was screwing things up for WinXP.  I deleted both partitions and recreated WINXP.  The WinXP CD would still not boot.  The Vista CD would still boot, and it gave me a command line from which I could run winnt32.  Even so, it crashed again.  I wondered whether the problem was with my SP3 CD.  I made another folder on the FreeDOS USB, naming it I386-SP2, and copied the I386 folder to it from the WinXP SP2 CD that I had used in making the SP3 CD (i.e., having the same product key).  I tried running WINNT32 again from the Vista command prompt, using this I386-SP2 folder as the source.  This gave me an error:

Setup was unable to build the list of files to be copied.

The system cannot find the path specified.

I verified that the WINXP partition was still drive C, and that it contained an I386 folder.  The problem seemed to be that the I386 folder has to be named I386 -- nothing more, nothing less.  I renamed I386-SP2 to be I386 and re-ran the WINNT32 command.  It crashed again, in exactly the same way as before.  I checked C: to see what WINNT32 was actually doing there.  The answer: not much.  It was creating files named $WIN_NT$, with the extensions .~BT and .~LS, along with a file named textsetup.sif, and it had copied NTLDR over.  And that was about it.  I deleted those $WIN_NT$ files and tried WINNT32 again, this time using the product code from my other WinXP CD.  It crashed, of course.

Someone said that a problem something like this one sounded like it might be due to a bad CPU or other hardware.  Of course, that was always possible.  I wasn't ready for that yet; after all, everything else seemed to work OK.  But I was running out of other theories.  Then I stumbled into a search from which I gathered that "downgrade" was an official searchable term, especially where Vista was concerned.  PC Magazine had a two method article, but neither method would work for me since I wasn't able to boot from the XP CD.  I found what looked like the consummate downgrading guide, with specific information for my laptop model.  For a CQ60 with an Intel CPU, it seemed to say that I should slipstream the ICH9 SATA driver (ICH9M-E/M SATA AHCI Controller) into the XP installer using nLite.  To get the ICH9, I downloaded and unzipped f6flpy3289.zip, but I did not understand why the highly regarded CherylG was telling me that I would find my driver inside iaAHCI.inf.  In the process of digging around for the driver she named, I contracted a virus, which prompted me to get up-to-date on Spybot Search and Destroy and on the Web of Trust add-on for Firefox.  I eventually found the driver on an HP webpage (though not the downloads webpage for my laptop).  I ran it on another computer (it was an .exe file) and it tried to install itself but then said the computer didn't meet the requirements, which I assume meant something about its particular CPU.  The conclusion there seemed to be that it would help to run it on a computer whose hardware was very different from the target computer, so that it would just extract but would not install.  I didn't know if it would run on the laptop from the Vista prompt, but anyway this was not the concept of slipstreaming, so I went back to the first one that CherylG had pointed toward.  Then I downloaded nLite and looked at the recommended guide for slipstreaming the driver.  Now that I saw the guide, I understood why CherylG was pointing me toward an .inf file.  She apparently didn't mean that I somehow had to extract the driver from iaAHCI.inf; I just had to include that .inf file in the slipstream.  This seemed to be the only thing I had to slipstream, so I went ahead with it.

The slipstreaming process began by copying the entire SP3 CD to a folder on the hard drive that I called SP3CD.  I started to install nLite, which required the Microsoft .NET Framework 2.0.  Installing that required trying to update .NET Framework 1.1 and then downloading a tool to uninstall it when the updates failed, and then manually doing registry edits etc. to uninstall it when the tool failed.  That ran overnight.  Next morning, when that was done, I followed the MaxEasyGuide to slipstreaming with nLite.  The first time, for some reason, it did nothing.  Second time, it made a file that I called SP3-SATA.ISO, containing the ICH9M-E/M SATA AHCI Controller driver from within iaAHCI.inf -- and now I understood what CherylG was saying.  Next question:  what was I supposed to do with this thing?  I decided to open it with UltraISO and copy its I386 folder to another folder.  Then I ran Beyond Compare to see how different it was from the original slipstreamed SP3 I386 folder.  It looked like there were a couple dozen differences in files.  So, OK, the nLite process seemed to have done something.  I wasn't sure I had done all of these steps right, but I decided to give it a shot.  I used Beyond Compare to synchronize the I386 folder on the FreeDOS USB with the I386 folder I had just extracted from SP3-SATA.ISO.  Whoa.  Many, many differences.  I forgot -- I had been using the SP2 I386 folder.  I changed that around and re-ran the comparison.  Still tons of differences!  Oh, I knew why.  It was because of the timechange.  The files were mostly the same, but some had been created an hour before the others of similar name.  I told Beyond Compare to ignore unimportant differences and did a full refresh, but that made no difference.  I bit the bullet and upgraded 6,992 files on the FreeDOS USB.  While that was underway, I re-ran the nLite and Beyond Compare processes, just to be sure.  Everything looked good.  I put the updated FreeDOS USB drive into the laptop and re-ran the WINNT32 command.  Alas, that wasn't the answer.

I found another thread that seemed to say that CherylG's advice on drivers was for an AMD CPU, whereas my CQ60-420US had an Intel CPU.  But some respondents said they were definitely using the Intel drivers and it still wasn't working.  Unfortunately, the drivers they pointed to were no longer availlable at the Intel website.  Daniel Potyrala advised that I download and run CPU-Z in order to find out not only my CPU type but also my chipset.  I couldn't very well run CPU-Z without an operating system.  Since it seemed that having Vista on the same hard drive did not explain why I could not even run WINNT32, it seemed to be time to restore the Vista partition using GParted and Acronis.  Adam Pash assured me that it didn't matter which came first, WinXP or Vista, so I left the WinXP partition in place (in hopes that it would someday be operational) and just added the Vista partition behind it.  I downloaded the appropriate version of CPU-Z, jumped it over to the laptop, and installed and ran it.  CPU-Z said that my mainboard chipset was an Intel GL40, which meant that I needed to slipstream . . .  the ICH9M-E/M SATA AHCI Controller driver, just like before.  So Mr. Potyrala was wrong; CherylG had given me the right tip.  But then Fernando1 said there were different drivers for 32-bit and 64-bit CPUs.  My T4200 Pentium (Penryn) was a 64-bit.  It was hard to tell the two apart; the driver names were the same.  I repeated the nLite process.  This time, the Textmode driver I selected was the ICH9 SATA AHCI Controller (Desktop ICH9R).  There were, again, some differences, so once again I updated the FreeDOS USB drive and tried it in the laptop, this time typing  "I:\i386\winnt32 /syspart:F: /tempdrive:F: /makelocalsource" because the FreeDOS USB was at I: and the WinXP partition was now at F.  That didn't work, so I tried once more, this time selecting the ICH8R/ICH9R SATA RAID Controller.  That didn't work either.

It was time to quit.  The webpages to remember, for future reference, included Quang Do's post in an HP forum, listing drivers and their sources; ditto Riskyone101; and perhaps a post, by wimb, that I really didn't understand.  The approach to remember was to use Unetbootin in Ubuntu to quickly create a FreeDOS bootable USB drive, if I needed 16-bit support, or just a Vista DVD or UBCD, if I could go straight to 32-bit support; to format the target drive in FAT32 rather than NTFS if necessary; to use nLite to create a slipstreamed ISO, assuming I could find the right drivers, and UltraISO to extract files from that ISO to load via USB drive if necessary.  I didn't know why WinXP could not run on the laptop, and I wasn't sure what else to try at this point.