Virtualization: Running Ubuntu and WinXP in WinXP

I had been through a number of difficulties in my attempt to install Windows XP. After what finally seemed like a successful installation, I found that I was still having problems with blue screens of death (BSODs) and that I was still unable to make some hardware work. A crucial piece of nonworking hardware was the Canon MF5730 scanner, and that was ironic: one of my reasons for stopping a previous effort to use Ubuntu Linux was that I could not use Adobe Acrobat in it. So now, as far as scanning was concerned, I couldn't use Acrobat in WinXP either. As far as Canon's very helpful tech support people could determine, the problem in my system was a Windows problem, not a Canon problem. Acrobat was not the only thing that encouraged me to keep a Windows installation going. There were other pieces of software and hardware that appeared likely to require me to try again with a Windows XP Professional installation. But I was unhappy with the enormous amount of time it had taken to troubleshoot Windows issues. I was also disappointed that my new, more advanced motherboard, RAM, and CPU still could not run Windows in a snappy, responsive way. Ubuntu on my laptop was actually faster than WinXP on my desktop. So I thought that, this time around, I would try to make it a minimal Windows installation, and see if I couldn't use Ubuntu, within that Windows installation. The goal would be to become more proficient in using Ubuntu for various needs. I considered using Wubi for this purpose. CNET said that it made Ubuntu readily accessible as a program running inside Windows. The scenario, in that case, would be that I would reinstall Windows; I would add Wubi to it; and then I would install programs as needed. Where possible, I would install them in Wubi; but if necessary, I would install them in Windows. This, I thought, might help me get my work done, and would also make it easier to transition to Ubuntu, which seemed likely to be my long-term direction. Problem: Wubi did not appear to be ready for prime-time. CNET's page contained some negative ratings; 12 voters gave it only 3.5 out of five stars. Moreover, it did not appear to be very widely used yet. There was talk that it might be included in the next version of Ubuntu, but I needed a working system now. As an alternative, I thought I might try using VMware again. I had previously played with VMware for this purpose, based on wide impressions that it was a solid performer. That time, however, I was trying it as a way to run Windows within Ubuntu. Now it seemed that I might do it the other way around. One advantage of this approach was that I already had this whole complete WinXP installation sitting on my computer. If I could make a VMware virtual machine out of it, then I could run it within my new WinXP installation as needed, without larding down that new WinXP installation with the problems and sheer weight of this existing installation. If the virtual machine crashed, I would tinker with it, without the delays and problems involved in a crash of the host system. I also had a working Ubuntu installation on another drive. I thought that, if I could make a virtual machine out of that as well, I would be all set to run either operating system within a much simpler, hardware-oriented WinXP system. But VMware Converter (Starter edition, free, as distinct from Enterprise edition) did not speak Ubuntu, so I could not use it to make a virtual machine out of that Ubuntu installation. I could, however, download a free virtual machine appliance, as VMware called it, containing a complete canned Ubuntu installation. At that point, they were only up as far as version 6.10, with the dorky name of "Edgy Eft," from autumn 2006; but it was Ubuntu, so I downloaded that and held onto it, to see if I might be able to use it. As I looked into the matter more, reading my previous post on virtual machines, I thought that perhaps I should also reconsider Microsoft Virtual PC 2007. It was designed to run assorted operating systems inside Windows. It sounded like you would install Windows, install Virtual PC, and then open up an empty virtual machine and install your operating system inside that. One important drawback was that it wasn't clear whether you could import an already existing Windows installation (much less an Ubuntu installation) into a virtual machine. That is, it seemed I would have to create my virtual machines from scratch. In any case, I was eager to be less reliant on Microsoft. It seemed that, if I created a virtual machine in VMware within Windows, I would probably eventually be able to run it in Ubuntu in a way that would satisfy me (as newer versions of Ubuntu came out); but I doubted that a virtual machine created by a Microsoft product would ever run on anything other than Windows. I thought about trying to install Windows XP Professional x64 (64-bit) as my host operating system. A reason for doing so, as discussed in a previous post, would be to enable access to RAM above 2.7GB. But because I understood that x64 had less than ideal hardware support, and since hardware was a crucial consideration, I decided to make regular 32-bit WinXP my host operating system. (The VMware Guest Operating System manual made it sound like 64-bit guests could be problematic; also, there didn't seem to be any point in installing a 64-bit guest that would be constrained by the limits of the 32-bit host.) So after I had created the virtual machine containing my old WinXP installation, I deleted that installation from my drive and constructed a basic, hardware-oriented WinXP 32-bit installation. Once that was in place, the next step was to set up the VMware layer, using the free VMware Server for Windows. Earlier in the day, I had already used VMware Converter to create a virtual machine of the previous Windows XP installation. It went very smoothly. Actually, I had done it twice. The first time, I did not tell Converter to use the minimum amount of disk space, so I wound up with a 50GB virtual machine. That took less than an hour. The second time, I did specify minimal disk space, and it seemed like that took longer. My plan now was to run two virtual machines in VMware on Windows XP. One virtual machine would contain WinXP. In other words, I would use VMware to help me run an older, expanded Windows installation that had all kinds of programs already installed, but was showing signs of dysfunctionality; and I would also use VMware to help me run Ubuntu. My hope was that, in this way, I would be able to switch back and forth easily between WinXP and Ubuntu virtual machines, thereby making it easier for me to make a gradual transition to Ubuntu. So I began to install VMware Server on the WinXP base. First, I got an error message indicating that I needed to install Internet Information Services. This involved going into Add or Remove Programs > Add/Remove Windows Components. Next, I received a warning that "VMware Management Interface is only supported on Server operating systems. You may encounter some issues when using VMware Management Interface on this system." Countering that, however, I received some assurances that VMware Server would run on WinXP. Then, as the installation of Server progressed, I received this:

Warning 25300. The VMware Management Interface Website was correctly configured but failed to start. The site will have to be started manually from the IIS configuration console.

where IIS was short for Internet Information Services (above). I found no hits on a Google search for phrases from this message. I hoped it didn't mean much, and I kept going in the installation process. Installation completed, and nothing happened. So I went to Start > Programs and started VMware Server Console. It was just me, so I specified "Local host" when asked. I found myself at the Console's main screen, where my options included creating a new virtual machine or opening an existing one. I chose the latter and browsed to where I had stored my newly created WinXP virtual machine and opened it. Console reported that the machine's status was "Powered off." The available commands were to edit its settings or start it. I have reviewed some of the available settings in my previous post on virtual machines. I will say, though, that my skills at refining my Ubuntu workspace were not nearly as good as my skills in Windows, so the look and feel of VMware in WinXP, now, was better than it had been in Ubuntu. At this time, I had not succeeded in resolving a driver conflict on the underlying XP system. That conflict had to do with sound. VMware picked right up on this and informed me that there was an "Error 2 opening default output sound device" and that therefore "Virtual device sound will start disconnected." So this confirmed what I had assumed, but had not seen explicitly stated in the materials I had reviewed: the hardware possibilities in the virtual machine could not exceed those in the host. A guest operating system would not look beyond the host to make use of perfectly good sound hardware that, for some reason, the host was not able to see. I clicked through that and the VMware window opened, with my old desktop inside it. At the bottom of the screen, it said, "You do not have VMware Tools installed." I clicked on that old desktop and immediately my cursor began to function very poorly. I pressed Ctrl-Alt to release the cursor and decided to install VMware Tools, if I could find it, since I had read that it would substantially improve graphics performance. I didn't know where VMtools were. At the VMware Server Virtualization Products page, they said that Server included Tools. I went back to the Server download page and noticed that, in addition to Server itself, it was also possible to download "Drivers and Tools" and "Open Source." But the Tools they had in mind, on that separate Drivers and Tools tab, were not "VMware Tools" per se; instead, they just meant that you could also download a Processor Check tool and SCSI Disk Drivers. It seemed that I had already downloaded VMware Tools when I had downloaded Server -- but where were they? On the Release Notes > Getting Started webpage, it said this:

If you use existing virtual machines -- either virtual machines created in a different VMware product or virtual machines created in an earlier release of VMware Server -- install the version of VMware Tools included in this release (VM > Install VMware Tools) for enhanced performance of guest operating systems.

On the VMware Server Console's menu, I saw VM, and proceeded as they said. Apparently I would have to do this with each guest operating system that I ran, and possibly each time I ran it: their message said, "You cannot install the VMware Tools package until the guest operating system is running." I clicked to install. It seemed that nothing happened. The message at the bottom of the screen still said I did not have Tools installed, and the cursor still functioned very poorly inside the Console; but VM > Install VMware Tools had now been replaced with VM > Cancel VMware Tools Install. So apparently I was in the middle of a Tools installation. I looked for an explanation. In the Console, in VM > Settings > Hard Disk, I noticed that Server was calling my SATA drive a SCSI drive. So it appeared I might need the SCSI driver mentioned above. I downloaded that. It was a *.FLP file. I could not figure out how to install FLP files, and there were no instructions. In a "wmware.com" forum posting, I found one cryptic explanation that said, "Remember: when you install an xp prof client you should use a particular SCSI driver that is vmscsi-1.2.0.4.flp and pass it before installation pressing F6 key at cdrom startup." I tried looking in the VMware Knowledgebase for flp and F6 and found nothing. I tried to get into their Communities but wound up at a page where they wanted me to join a Local User Group. I tried again and found their Forums, also under the Communities heading. I went into the VMware Server forum and searched again for flp and F6. This produced four hits, none of which was too relevant, and none of which was the wmware posting mentioned above. I ran the same search in that wmware.com site and got a total of two hits. These postings collectively intimidated me, in that they frequently referred to command-line techniques that I did not have time to master. But they also reminded me to see what the manual might say. So I went back to the Guest Operating System Installation Guide. It appeared that "install" meant installing from scratch, which was what I thought I might wind up doing with Ubuntu, later. For my preexisting WinXP virtual machine, however, I went to the VMware Server Virtual Machine Guide. (Both of these guides were also available in PDF form.) Introductory browsing in these guides suggested that the F6 approach might relate, not to the use of SCSI drives in a preexisting virtual machine, but rather when you were installing an operating system from scratch. Browsing further, a page in the Virtual Machine Guide told me to follow the instructions on the download webpage to install the SCSI driver. I again looked in vain for those instructions on that webpage. Dropping that issue for the time being, I returned to the Virtual Machine Guide's chapter on VMware Tools. This chapter told me that I was supposed to have gotten a splash screen when I started the Tools installation, followed by an option to launch the InstallShield Wizard. This hadn't happened, and I didn't know why not. I was pretty much stumped at this point, so I prepared to post a question in the forum. Then I remembered that I had not actually looked in the forum for Tools installation information, so I tried that. It developed that there were a lot of postings by people who had trouble installing Tools. I decided that Tools was not actually my first problem. My first problem was that I was not getting a full bootup of my guest WinXP operating system. I was getting my screen saver, but no Start menu or toolbar at the bottom of the screen. I looked in vain for something along these lines in the forum, and then posted my own note. Meanwhile, I had some actual work to get done, this being a Monday morning in a real world, and so forth. This actual work would entail using a word processor. I could have done that work on my laptop, where I was composing this posting, but the laptop was kind of retarded and I had a lot to do, and anyway I wanted to keep it organized on the desktop. So I thought I might try again, to see what would happen if I installed that Ubuntu 6.10 virtual machine appliance mentioned above. I couldn't easily figure out how to open that appliance from within Console, so I found the appliance download on my hard drive and double-clicked on its *.VMX file. This opened a second session of Console, with both the WinXP and the Ubuntu virtual machines shown under "Inventory" on the left side of the screen. I saw that both were also open in the first session, so I closed this second session, went back to the first one, and clicked on "Start this virtual machine." This one, unlike the Windows XP virtual machine, showed signs of life, as Ubuntu went through its bootup process. Ubuntu asked me for a ubuntu login. I had no idea what to type. I just hit Enter. That didn't work. I tried asdf. It asked for a password. I typed asdf again. "Login incorrect." I figured I might go back to the webpage where I had found this thing, in hopes of finding the answer there; but then I decided to just create my own. Part of the reason was that this login part of Ubuntu 6.10 was strictly command-line, unlike the much nicer GUI of Ubuntu 7.04. I felt that, if I was going to spend time installing an Ubuntu virtual machine, I should make it more up-to-date. So I right-clicked on the Ubuntu 6.10 entry, under Inventory, and said Close and then Remove from Inventory. Then, to start my new Ubuntu installation, in Server Console, I selected File > New > Virtual Machine. This started the New Virtual Machine Wizard. It was prepared to set up a specifically Ubuntu Linux machine (along with numerous other flavors of Linux). I designated a 20GB space for it. Back in Console, I selected "Start this virtual machine." It reminded me that I did not have Tools installed, so again I selected VM > Install VMware Tools. It told me that I would have to wait until the guest operating system was running. Separately, I got an error message saying, "No bootable CD, floppy or hard disk was detected." At this point, I had to take a break of several days. When I returned to this project, I retraced the steps described in the previous paragraph. This yielded a message reminding me that there was already a virtual machine named Ubuntu, and did I want to create another one? I backed out of that and, on the Home tab of Server Console, I selected Open Existing Virtual Machine. But this gave me a message, "There are currently no virtual machines available in the Inventory." I went into Host > Settings and changed the default location for virtual machines. I still had to browse from that folder to the subfolder containing my newborn Ubuntu virtual machine. I wound up back at the previous paragraph's message about a bootable CD, so I inserted an Ubuntu 7.04 bootable CD, right-clicked on Console's Ubuntu tab to close it, and again proceeded to open an existing machine. But this just put me back where I had just been. Looking further down on that tab's right-click context menu, I saw a Reset option, and I tried that. This gave me the Ubuntu CD's opening menu. I clicked on Start or Install Ubuntu, but nothing happened. Plainly, it was time to resolve that issue of my cursor not functioning properly inside Console. I returned to the message I had posted in their forum two days earlier. That message was as follows:

I'm running a WinXP Pro (32-bit) guest inside a WinXP Pro (32-bit) host on VMWare Server 1.0.3. (The host is a stripped-down version of XP with a focus on hardware; the guest, created through VMware Converter, is an unwieldy, hoary old monster, with a bazillion assorted utilities and other crapware, that is not necessarily the most stable thing you ever saw. My goal is to run it alongside Ubuntu, so as to ease the transition from A to B.) Or at least I'm trying to run that XP guest. In VMware Server Console, I get the desktop picture from the guest. Nice desert island. But it appears inside a thick black frame -- that is, it does not fill the Console screen. Also, there is no Start button, no toolbar, no system tray at the bottom. And when I hit VM > Install VMware Tools, I get no splash screen or other response. I thought this might relate to a SCSI drive issue. The host is running on a machine with a SATA drive. The guest was created on this same machine. VM > Settings > Hard Disk reports that this is a "SCSI 0:0" drive. I gather that there is a *.FLP file to be used with SCSI drives, but I can't figure out how to install that FLP file. Thanks for any insights ...

That message didn't draw any responses, but it still seemed to describe what I needed to know, so I looked around for some other source of insight. In the main page of the VMware Server forum, they had a link to an FAQs posting that was the better part of two years old. This posting was about GSX Server, rather than plain old Server, but I gathered that the forums for the two had merged -- which hopefully meant that the instructions supplied for one would work on the other also. There was a link to a page on installation of VMware Tools in GSX Server. That page pointed, in turn, to pages on installation of Tools in a Linux virtual machine or in a Windows virtual machine. The page on Linux said that I would have to install it in text mode, which I assumed meant downloading the Ubuntu alternative ISO. Instead, they said, I could switch to another workspace within VMware, but those instructions did not work for me; there was no response when I used Ctrl-Alt-Space as they advised. I seemed to have three problems: how to install Ubuntu, from scratch, as a guest operating system; how to make Windows XP run, as a guest operating system, after creating it by using Converter within a previous WinXP installation; and how, in each case, to install Tools. Since I wasn't making too much progress in the VMware forums, I decided to try the Ubuntu forums. I went to their Absolute Beginner Talk forum and searched for something of relevance. I wasn't finding it, so I decided to add a post. Their cool webpage conducted a search of the title I entered, there, when I was writing my post, as soon as I finished typing the title and hitting Tab. But the results of that search didn't match up either, so I posted my message, as follows:

I am trying to install Ubuntu 7.10 in VMware on Windows XP. My goal is to run the two simultaneously, so as to make a gradual transition to Ubuntu. But I am not getting too far in VMware. In VMware Server Console, I have reached the point of having an Ubuntu tab open, with the initial Ubuntu startup menu visible. This is the menu that begins with "Start or install Ubuntu," "Start Ubuntu in safe graphics mode," etc. When I click inside that window, my cursor dies. I can press Ctrl-Alt to bring it back to life. I am guessing that the problem, as reported by a status bar message, there in VMware Server, is that I do not have VMware Tools installed. I have looked at VMware's forum and have found my way to what seems to be their recommended Tools installation page, at http://www.vmware.com/support/gsx3/doc/tools_install_lin_gsx.html. That page relates to GSX Server, rather than plain old server. I am guessing that their FAQs point to that because the two function the same for these purposes. The page advises me to switch into text mode, but their instructions for doing so are not working for me. Basically, I want to install 7.10 in a VMware virtual machine, and do not know how to proceed. I will appreciate any tips that may help me accomplish this.

By midafternoon, I had two responses. One told me that I didn't need Tools until after I had Ubuntu running. The other recommended VirtualBox for a simpler solution. Since I wasn't getting anywhere in VMware, I looked at VirtualBox. Reviews at TechTarget, Liquidat, and Softpedia were positive; but what seemed to be a more careful look at this and competing products at InfoWorld gave VirtualBox the lowest score among four packages (the others were Microsoft's Virtual PC 2007, VMware Workstation (not the free Server), and Parallels Workstation. They said:

The product, unfortunately, is marred by numerous user interface bugs (the VirtualBox control shell tended to crash randomly), a cryptic error message format that left me scratching my head on more than one occasion, and a complete lack of 64-bit (host or guest) OS support. VirtualBox is also an underwhelming performer.

That review characterized VMware Workstation, by contrast, as "the only choice for serious virtualization users." They said that Virtual PC 2007 was also an underperformer, with fewer features than VMware Player. The remarks about crashes and so forth persuaded me that I was not ready for VirtualBox. The review at Liquidat also showed a performance comparison of VirtualBox against VMware in two simple tasks; and for me its significance was not that VirtualBox was somewhat slower than VMware, but that both were (as suggested in the other guy's comment, above) more than 50% slower than a native system without virtualization. It seemed that I should continue searching. I looked briefly at Wine, whose purpose was to run Windows programs within Linux. As I had gathered from other sources, at this point Wine was capable of running some Windows programs but was not yet ready for general-purpose use. I glanced at Lindows/Linspire, but got a sense that it was essentially an inferior competitor to Ubuntu. There had lately been news that not only Dell, but also other mainstream companies were beginning to offer Linux-based (or, in Dell's case, dual-system) PCs. I felt that a lot of things would be happening with Ubuntu in the next year. At the same time, it seemed to me that Ubuntu and related programs needed to develop further before I could do that easily -- that Wubi, for example, still had a ways to go. In my previous experiences with Windows, I had always completed the installation process in one fell swoop, installing everything I thought I might need at once. So within the first days of a new Windows install, I would load the system with tons of programs, utilities, and tweaks that I had used previously and that seemed likely to be useful again someday. This time, however, things were different. I did not hope to be setting up a Windows installation that would function indefinitely. To the contrary, I hoped to be switching to Ubuntu when some of the aforementioned programs matured. My review continued to persuade me that VMware would probably be the best product for facilitating a transition from Windows to Ubuntu. But it also seemed that VMware Server, supported only in thinly subscribed forums, might be more trouble than it was worth. I would have spent $189 for VMware Workstation, which the company itself would support; but at this point two things had changed. One was that I had become aware of the possibility of a serious performance penalty for using virtualization software. The other was that I had run out of time for computer tinkering. I did not know of any specific reason why Server essentially failed to work for me, and I could not indulge a $189 experiment to learn whether Workstation would be different. What I hoped for, ultimately, was to switch to 64-bit Ubuntu or some other reliable bottom layer, and on that basis to build some way to run Windows programs. In other words, I wanted to have my Windows capabilities with Ubuntu's reliability and open-source orientation. I was not too interested in mastering details of Ubuntu's command line; I did not have time to tinker; and at this point it did not seem that virtualization software, like VMware, was going to provide a general-purpose solution for me. If anything, as I especially appreciated in the wake of that InfoWorld review, it promised to add another layer of potentially dysfunctional complexity. Yet as I considered the prospect of larding down my sleek new Windows XP reinstallation with Microsoft Office -- with the time that would be involved for re-adding such programs, and also with the problems that such programs could bring -- I hesitated. Was it possible that my VMware Server problems had been due to video graphics card driver problems that I had recently fixed? I inferred, from the paucity of helpful responses to my posts, and from seeing that other posts in those same forums did get responses, that people would have been glad to give me an answer if they'd had one. My experience suggested that, if I didn't get an answer, it meant I was having a unique problem; and if I was having a unique problem, it probably meant the hardware was involved. So the question presented itself: now that I had fixed the driver issue, should I try once more to use VMware Server? Trying certainly wouldn't kill me. If I could get Server to work, I could use my old WinXP installation in a virtual machine, as described above, to run Office etc., thus keeping my base layer WinXP installation relatively clean and fast. But when I tried Server again, it was even worse than before: not only did it refuse to respond, but it froze my system, and I had to use the reset button to restart. Microsoft's Virtual PC 2007 had now become an option. I was not hoping, anymore, to import a previous existing Windows installation as a self-contained virtual machine, as I had hoped to do in VMware. Nor was I really hoping to do too much with Ubuntu in a virtual machine, at least not until one or two more generations of development. All I hoped to do, at this point, was to install a Windows XP system in a virtual machine that would run on my basic machine, where I would use the virtual machine for all the performance-degrading stuff that I had typically installed on my computers, while trying to remain true to the ideal of a bare minimum of programs in the host (underlying) system layer. I hoped that, this way, when a more refined Ubuntu did emerge, I could then proceed with the project of making a gradual transition to it, one application at a time. As I reviewed the InfoWorld article, I saw that Virtual PC 2007 was rated at or above VMware on the things that mattered to me (e.g., ease of use rather than scalability). The writeup was similarly encouraging, except in the area of performance, where Virtual PC and VirtualBox appeared to perform at about half the rate of VMware. It seemed that there might be some instances where I would install a program on the host for performance reasons; but for purposes of basic Office software and so forth, I hoped the guest would suffice. So I uninstalled VMware and downloaded Virtual PC 2007. I got some immediate encouragement about the usability of VPC, from Microsoft's VPC webpage, when I watched part of their smooth presentation video, both from what they said and from the fact that they went to the trouble. It definitely felt superior to VMware's website. Now it was a question of whether that feeling matched reality -- whether VPC would work for me. I ran VPC and set up a new virtual machine on which I would be installing WinXP. I discovered that you have to have your Windows boot CD in the drive when you start the machine, if you want to install from it. I browsed VPC's Help files and saw that they recommended using antivirus software, a firewall, and so forth. So each virtual machine would evidently be in direct contact with the outside world -- which meant that my various precautions on the host machine level weren't helpful, and that I would need to be installing Windows updates, antivirus updates, etc. in both the host and the guest. The VPC Console was a little thing, but it appeared to have the options to change the parameters of your virtual machine on the fly. Meanwhile, in the main window, I had a normal Windows XP installation underway, behaving in every way just as if I were installing WinXP on the computer as a whole rather than just in a virtual machine. The virtual machine could not see my hard drives. I learned, however, that I could use Sharing Folders to exchange files and folders between the physical and virtual machines. I decided, however, that I was not comfortable with having actual data files locked up inside a virtual hard drive. Also, the mouse performance was sluggish. At this point, although I wanted a clean and minimal system, I decided that the easier route was going to be to install needed programs on the physical machine, and to forget about virtualization for the time being. It did seem that I could use VPC to make Ubuntu run on WinXP, but I did not experiment further in that direction at this time. Instead, the path I ultimately took was to experiment with using a KVM switch to run two separate computers from a single monitor, keyboard, and mouse. *********************************** If you have found this post useful, please add a positive comment. Thanks!

Virtualization Options in Ubuntu (cont'd)

As described in previous posts, I had been researching and experimenting with virtualization tools in Ubuntu Linux. Virtualization tools, including VMware and VirtualBox, would allow me to run Windows XP as a guest operating system within a virtual machine running on an Ubuntu host. I would have the stability and online security of Linux, as well as the convenience of being able to run programs in Windows if I could not find satisfactory Linux counterparts. If Windows got flaky and crashed, it would crash only itself and the programs I was running on it within the virtual window; the underlying Ubuntu operating system would be unaffected. To review: the decision process thus involved seeking suitable Linux replacements for Windows programs; using Wine to enable Ubuntu to run some Windows programs for which there were no satisfactory Linux replacements; and using a virtual machine to run Windows programs that could not be replaced by Linux counterparts and that also could not be made to run satisfactorily on Linux via Wine. I had made a basic Windows XP installation as a dual-boot arrangement on my primary computer, and had used VMware Converter to make a virtual machine from that WinXP installation. I had then added some drivers and a few other adjustments to the basic WinXP installation, and it seemed it might be helpful to make another virtual machine from that revised form of the WinXP installation. I had not downloaded and installed Windows updates because they had previously seemed to make the system slow and unstable. I would have done so if I had been planning to continue working in the Windows dual-boot environment; but since I planned to use Windows within the virtual machine on Linux behind hardware and software firewalls, I was not especially concerned about the additional security that Windows updates might have provided. Of course, I could add those updates later if it seemed prudent to do so. In experimenting with VirtualBox, I had noticed that it was handling file movement tasks in Windows Explorer (inside the VBox virtual machine) very poorly. I was also could also not figure out how to gain access to my hard drive partitions; it seemed that everything I wanted to work on needed to be in the virtual machine. Since I had my files arranged in many directories and did not want to be dragging them back and forth to the virtual drive every time I wanted to access them, I gave up on VBox and returned to VMware. I had previously experimented with VMware Workstation 6.0, which had generally impressed me and was available for $189. Now I tried VMware Server, which was free but which, like VBox, did not seem to have the ability to let me work with files on my hard drive partitions. I wondered whether this was a limitation of Server 1.0. Server 2.0 was in beta testing and was reputed to be unstable. I was not sure when Server 2.0 would be sufficiently reliable to use, or whether it would resolve this problem. A second concern was that Server lacked Workstation's ability to make clones and multiple snapshots of virtual machines, so as to facilitate the adding of various programs to various virtual machines. Since doing that review, I had seen that quite a few people were using VBox and seemed happy with it. It seemed likely that, with additional adjustments, I too could have a better experience with it. So I went ahead and re-ran VMware Converter, to capture a virtual machine that would include the drivers and additional adjustments I had made to my basic WinXP installation on drive C of my primary computer. This time, I also used Drive Image 2002 to make a backup of it. In both the drive image and the virtual machine, this time I included drive D as well as drive C. I had long used Drive D to hold things relevant to drive C. One example: the I386 folder. This was a folder of Windows program files. When updating or reinstalling stuff on drive C, sometimes Windows would want to refer to things in the I386 folder. Normally, that folder is found on the Windows CD; but it was also possible to copy it to your computer somewhere. I didn't want to re-copy it to drive C every time I reinstalled Windows, so I put it on Drive D instead. Drive D also held a folder containing programs that were installed on a standalone basis, independently of the WinXP registry. That is, I did not need to reinstall these programs each time I reinstalled Windows; I just needed to keep my shortcuts that pointed to them, and put those shortcuts back into the Start Menu at the appropriate place. So, of course, Drive D also held a copy of my Start Menu, customized to put program shortcuts in categories that I found more accessible than the jumble in which Windows left them. I got unnecessary things off drive D, ran chkdsk /r on both drives C and D from the WinXP CD Recovery Console, resized drive D to be 2GB using GPartEd, rebooted into WinXP, and ran VMware Converter. The advantage of including drive D was simply that the aforementioned items, including the I386 folder and my permanently installed utilities on D, would hopefully now always be available within the virtual machine. The Drive Image process did not actually work. When I started it, I got error #1529, "Information mismatch in directory entry." I was not able to fix this. CHKDSK in the WinXP Recovery Console did not do it, nor did shutting off S.M.A.R.T. in BIOS or rebooting and letting Windows clean itself up. I tried using the Acronis True Image CD to make an image of the system, but the trial CD that I burned from the download was not able to do that. I had already put TrueImage in my shopping cart, but it would be several days before it arrived. So I took a pass on the drive imaging for now. When VMware Converter completed making the virtual machine, I had the predictable 12GB VMDK file. Now, what to do with it? I rebooted into Ubuntu and returned to VMware Server, to try once more installing VMware Tools and see if that made it possible to access other drives. First, in Server, I hit "Edit host settings" and adjusted the RAM available to all VMs; but when I clicked OK, I got, "You don't have the permission to execute this operation." I had gotten that in the previous post too, but had had to deal with numerous other things at that point and never got back to it. Now, when I Googled that phrase, I got the advice to open VMware from Terminal with "sudo vmware." That did it; I was able to change the RAM setting. Now I had a new problem. When I told VMware Server to open the new virtual machine I had created with Converter, incorporating an updated version of my basic WinXP installation there on the physical drive C, I got this error message:

Unable to connect to the MKS: The config file /var/lib/vmware/Virtual Mahcines/WinXPBasic/WinXPBasic.vmx is not registered. Please register the config file on the server. For example: vmware-cmd -s register "/var/lib/vmware/Virtual Machines/WinXPBasic/WinXPBasic.vmx"

I tried exactly what they said, there in Terminal. I first had to close out of VMware Server to get a Terminal prompt. I got back an error: "No such virtual machine." Oops. After creating the virtual machine on another drive when I was using Converter in the Windows XP dual boot, I had copied the three WinXPBasic files (WinXPBasic.vmdk, WinXPBasic.vmx, and WinXPBasic-flat.vmdk) to the wrong folder. I put them in the right folder and tried again. Now Terminal said, "Virtual machine already exists." OK, so I ran "sudo vmware" again. It opened, with an error message about user preferences. I closed it and opened it again. I closed it by using the Start > Turn Off option in Windows. It was slow. When I started it back up again, I got this error message:

Cannot open file "/home/ray/.vmware/preferences": Permission denied. Unable to read user preferences.

But meanwhile Windows was starting up anyway. But I guess because of that message, it hung at "Loading your personal settings." I shut down the virtual machine, went to the first tab there in Server, and clicked "Edit host settings." I adjusted those and started the virtual machine again. Now I got this:

Warning Could not get interface flags for vmnet1: No such device Virtual device Ethernet1 will start disconnected.

I okayed that. Next, I got the error message about user preferences again. WinXP here on teh virtual machine was definitely booting much more slowly than it had done in dual-boot mode on the physical drive C. VMware said,

Your display driver has changed, The Auto Rotation feature needs to reinstall the rotation driver. If this message reappears, please update your display drivers. Would you like to re-install now?

I clicked yes. Meanwhile, Windows was recognizing all kinds of new hardware, including not only the CD-ROM drive but also all that stuff that I had installed drivers for when I had revisited the basic physical Windows XP installation. There must have been 20 things that it recognized, all at once. There weren't messages that there were problems with any of them. So apparently it was a good idea to have installed the device drivers in the physical installation before using Converter to make the virtual machine. But then it still wanted to work through the Found New Hardware wizard for several items. There were a couple of reboots thrown in. I didn't recall it being such an involved process previously. I was getting a notification, after each reboot, that my video drivers had failed or needed to be update -- something like that. As soon as things settled down, I went to VM > Install VMware Tools. As before, nothing happened. I waited 10 or 15 minutes, and I was still getting "You do not have VMware Tools installed" on the status bar at bottom, and "Cancel VMware Tools Install" on the VM menu. Finally I did cancel, and then rebooted and tried again. Same thing. As noted previously, I had been hoping that the installation of VMware Tools would permit folder sharing, because without that, there was no hope for VMware Server. I completely exited VMware Server and started it again. Meanwhile, I researched the "Unable to read user preferences" message, above, and found an answer that made sense:

Often if you run apps as sudo, root will own the config files instead of your user. That could be the case here so, try running: sudo chown -R peter:peter /home/peter/.vmware And then starting via the menu item and not with sudo.

So, who knows? I was thinking, maybe that's why VMware Tools wasn't installing too. I entered the recommended line into Terminal, substituting my name for peter, and then restarted VMware Tools from Ubuntu's Applications > System Tools. I had now reached a point where there were no more error messages upon starting VMware Server, except one:

Your display driver has changed. The Auto Rotation feature needs to reinstall the rotation driver. If this message reappears, please update your display drivers. Please re-install now.

When WinXP reloaded, I tried again on VMware Tools. Someone else had had the same experience as I had previously: try and try and then, for no particular reason, suddenly Tools begins to install. I thought maybe I could help it along by fixing that video driver error message. Device Manager was showing one yellow exclamation mark circle, next to the Video Controller (VGA Compatible). Oddly, the NVIDIA nView Desktop Manager icon was not appearing in the system tray, here in the virtual machine, so I had to start it via Control Panel. I right-clicked and uninstalled the Video Controller in Device Manager, and then rebooted the virtual WinXP installation. The Found New Hardware Wizard came up, along with that notice, just quoted, about how my display driver had changed. I tried running through an automatic installation in the Wizard, as I had done before, and this time (unlike previously) it presented me with three VMware SVGA II options. So in the case of the video driver, perhaps, it had been counterproductive to install before creating the virtual machine; it seemed that VMware Server would still need to install its own video driver. I chose the first one of the three. Meanwhile, Device Manager was now showing the yellow exclamation mark again, under Display Adapters. The first of the three did not install successfully: I got "Driver is not intended for this platform." So I uninstalled from Device Manager, rebooted, and tried another one. The one I had tried was no longer first on the list; it and the others had been moved down by the arrival of a new no. 1 (there were four now). The first three were version 11.2.0.0 of the VMware SVGA driver; the last was version 10.7.0.0. So I tried the last one. That didn't work either. I had already inserted the EVGA CD for my video card during the initial attempt at installation, and that hadn't worked; but now I inserted it again, so that I could run its setup program. Unfortunately, there was no access to the CD drive. I looked at VM > Settings > Hardware, and saw that the CD-ROM drive was set to "Auto detect." I would have tried installing an updated version of the driver, which I had saved on drive D of the physical installation; but all I had here for drive D was an unformatted disk with nothing on it. Interestingly, though, I saw (in Windows Explorer) that I also had a drive E, "VMware Tools." It had a Setup.exe file, so I ran that. And, what do you know, VMware Tools began to install. I wondered if it would have run automatically if I had enabled autostart for my CD, or if I had allowed active content for programs. But anyway, now I went through the VMware Tools installation, choosing the "Complete" option. I restarted the system as recommended. Things were now much improved. The screen fit properly; the mouse worked properly. I still had that error message about needing to re-install my display drivers; but now I also had access to the CD-ROM drive, so I could take a stab at getting those drivers installed. This effort terminated, however, with this message:

The NVIDIA Setup program could not locate any drivers that are compatible with your current hardware. Setup will now exit.

I had not gotten that message when installing these same drivers in the Windows dual-boot partition on drive C, so apparently what the CD was not finding was a driver that would work in the VMware environment. With the aid of the manual, I did find a way to come close to sharing the physical drive partitions. I powered down the virtual machine and went into "Edit virtual machine settings" > Hardware > Add > Hard Disk. I chose "Use a physical disk (for advanced users)." Unfortunately, I got a "Permission denied" message when I pursued that option. The VMware Server Virtual Machine Guide shed no additional light. I exited Server and started it in Terminal with "sudo vmware," and then repeated these steps. This time, it worked for the first drive, but not for the drive on which the Ubuntu program and swap partitions existed -- even though I was specifically not trying to include those partitions, but was instead focused on another partition on that drive. Instead, I got this message:

The partition table on the physical disk has changed since the disk was created. Remove the physical disk from the virtual machine, then add it again.

But adding it again brought the same message. So Server was able to see hard drives 1 and 3, but not 2. I tried opening the virtual machine and got that error message about permissions. I closed VMware and restarted it from Applications > System Tools rather than from the Terminal command line. I immediately got "Insufficient permission to access file." Along with the "advanced users" notice, I had received a notice that this whole technique could cause loss of data. I was not comfortable with it. I decided my confidence level in this Server product was not sufficient to justify that kind of risk, now or at some worst-possible time in the future. By this point, I had come across one of my own posts from a year earlier, in which I had experienced some of the exact same issues with VMware Server that I had experienced on this day, a year later. Server 1.0 appeared to be more or less the same software from a year earlier. Granted, VMware was working on Server 2.0, but that pace of progress did not suggest rapid improvement in Server. So that was the end of Server for me. Time to uninstall! I went into Ubuntu's System > Administration > Synaptic Package Manager, but VMware Server wasn't listed there. I was advised to try this command:

sudo vmware-uninstall.pl

and that worked. Goodbye Server! Next, I wanted to try again in VirtualBox. I started it and navigated to where the VMware Server virtual machines were stored. It took a couple of tries to find the right one -- Server seemed to have multiplied them. I got lucky when I chose the oldest one, which was apparently the one I had created with Converter. But when I tried to Start it, I got this:

Failed to start the virtual machine WinXPBasicVB. The VirtualBox kernel driver is not accessible to the current user. Make sure that the user has write permissions for /dev/vboxdrv by adding them to the vboxusers groups. You will need to logout for the change to take effect.. VBox status code: -1909 (VERR_VM_DRIVER_NOT_ACCESSIBLE)

The recommended solution to this one was System > Administration > Users and Groups > Unlock > Manage Groups > vboxusers > Properties. There, I clicked on my name, closed out of everything, closed VBox, and rebooted Ubuntu. That solved the problem much more easily and intelligibly than had been the case in my previous try at it -- though admittedly I had seen so many error messages, by this point, that I was losing track of which ones I had solved, or how. Anyway, it developed that none of the VMDK files would work -- Server seemed to have modified the original one and created others -- so I booted back into native WinXP, ran VMware Converter again, and this time made a point of keeping a copy of it. This time, too, I made a version for Workstation 6 and added VMware Tools to it. I was curious whether that would be better or worse for VirtualBox, and I also thought I might still try opening it in VMware Workstation. I went back into Ubuntu > VirtualBox and set things up pretty much as before. When I started the virtual machine, nothing happened. I had a black screen. Eventually, I got this:

A critical error has occurred while running the virtual machine and the machine execution has been stopped.

I clicked OK and tried starting again. This time, I got the white-on-black Windows boot screen that gave me the option of booting into Safe Mode. Then it froze. I killed it and tried again. This time I just let it count down 30 seconds so that it would then try to start Windows normally. Again, nothing happened. I tried again, and this time sent it into Safe Mode. That froze too. I went through its settings and deselected everything (e.g., SATA controller), most of which I had just selected a few minutes earlier. Rebooting into Normal Mode once again yielded a critical error message. I Googled it and got this advice:

write in terminal: uname -a if the output is: Linux gourgi 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux then i think you need amd64.deb

The emphasis, printed in red, was on the _64 in that output line. This is what I got. So I needed amd64.deb to go with my 64-bit processor and/or my 64-bit Ubuntu. Now, what was amd64.deb? It developed that this was the 64-bit version of VirtualBox. That sounded familiar. I checked my notes and, sure enough, I had installed my version of VirtualBox through Synaptic Package Manager because I was frustrated with the Java installation process at the Sun download webpage. Ironically, I had downloaded the 64-bit version anyway; I had just done the Synaptic approach because it seemed easier. So now I uninstalled VirtualBox through Synaptic, along with the qt3-assistant program I had installed to help somehow with the VBox installation. I right-clicked on the 64-bit VBox Debian file I had already downloaded and clicked Install Package. It finished installing without difficulty. Now, how to start it? There was no icon for it in Applications, and when I typed "virtualbox" or "vbox" at the Terminal prompt, I got indications that it wasn't installed. I right-clicked and reinstalled. I had previously noticed, and now I noticed again, that a sort of rotary sawblade icon was appearing at the top right corner of the screen, and when I moused over it, its tooltip said, "A package manager is working." So I waited for that to finish. This time there was an icon under Applications > System Tools. When I started the virtual machine, I let it go once again through its 30-second startup to "Start Windows Normally." This, however, was not the solution. Once again, I got that "critical error" message. Safe Mode didn't work either. I wondered if the problem was that I had created the virtual machine for Workstation 6 rather than Workstation 5. I couldn't readily find a website that would tell me, so I just rebooted into WinXP and ran Converter again, so that now I had the latest version of the drive C installation in both Workstation formats. But that wasn't it. The Workstation 5 version of drive C didn't run in VBox either. It just sat there, black, until I clicked the mouse inside the box. Then, eventually, it gave me the critical error message again. Somebody advised renaming ~/.VirtualBox/VirtualBox.xml (~ means /home) so that VBox wouldn't see it. I did that and then restarted VBox. It started over from the beginning, asking me to register my copy of the software etc. I tried again to run the Workstation 6 version of my virtual machine. I still got a black screen. As before, I tried Devices > Install Guest Additions right away, but nothing happened. I still got the critical error message. So this was not the solution. After viewing a number of webpages, I came to the conclusion that the critical error message could be caused by any number of things. I had also come across a posting by someone who had made a mistake and now had no sound and other problems with his/her system. This was not the direction I wanted to be going. I liked the idea of free software, and I was impressed that a number of people were having good experiences with VBox. But I wasn't. So it was time to return to VMware Workstation 6. It was the only thing that had worked well for me so far. I had since thought that its deterioration might have been due to a failure to install VMware Tools before activating Windows. But using Converter, I had now created a Workstation 6 virtual machine that did have Tools installed. So I thought I would give that a try in Workstation and see how it fared. That discussion continues in another post.

Ubuntu and VMware: Cannot Install This Hardware

This situation arose while I was in a previously described process of installing Windows XP SP2 and SP3 in VMware Workstation 6.5 on Ubuntu Linux 8.10 (Intrepid Ibex). See that previous post for more background information. At this point, matters had developed as follows: VMware had been unable to run the WinXP virtual machine (VM) that I had created, using VMware Converter, from a preexisting Windows installation. In other words, I had installed Windows on my computer as usual; I had used Converter to convert a copy of that Windows installation into a VM; I had rebooted into Ubuntu and had tried to run that VM within VMware; and it didn't work. The system really never got past loading Windows, giving me a BSOD (blue screen of death), and rebooting, in an eternal recurrence. So I went back to the Windows installation and tried again. That previous attempt had involved a Windows XP SP2 (service pack 2) installation, and that had made it difficult to run the System File Checker (sfc /scannow) program in Windows. I thought that might be helpful, and I came across a deal, so I got a WinXP SP3 CD and tried again. (Could also have slipstreamed SP2 with SP3 to create an SP3 CD.) Then I started over with a new WinXP installation, using this new SP3 CD. This time, unlike last time, I installed only a partial (but large) selection of my Windows programs and utilities. These were programs that I wanted every one of my VMs to have, so it made sense to install them once and then make clones of the resulting VM. For purposes of conserving disk space, backup space, and system load time, I wanted all this to fit within a 20GB rather than 30GB VM. So I left out some big, space-consuming programs. I figured I would add those later to one larger, 30GB VM. Installing numerous programs before running VMware Converter was a different approach from the one I had taken previously, when I had installed VMware Workstation on Ubuntu 8.04 (Hardy Heron). That approach had worked pretty well: the VM had run successfully in VMware on Ubuntu, and I had then added most of my Windows programs to it after doing the conversion. This time around, as noted above, an alternate approach had failed. This time, I had tried to add all of my programs to my WinXP installation before creating the VM, and that 30GB VM had failed to boot, as just described. So in this second try, I had (1) upgraded to WinXP SP3 and (2) installed only a selection of Windows programs, to a 20GB partition, before running VMware Converter to create a 20GB VM. So that's the situation we begin with. This 20GB VM did succeed in running in VMware Workstation, but it was very slow. It seemed that part of the problem was that it was not succeeding in installing the virtual "hardware" that Workstation pretends to be using. That is, my real, partial installation had been on a system with a Foxconn motherboard and an AMD CPU; but now VMware Workstation was trying to run that installation on a virtual system with a generic, virtual motherboard and CPU supplied by VMware. But at least it did run, so apparently the crucial difference between running and not running was due to (1) the use of SP3 rather than SP2 and/or (2) the elimination of one or more installed programs that had made it impossible for the 30GB VM to load and run. What was happening, at this point, was that the WinXP VM would give me the "Found New Hardware" wizard; I would tell it to go ahead and install itself; and it would then give me a "Cannot install this hardware" error message. It seemed that VMware Workstation, itself, was not supplying the drivers that its own generic virtual hardware needed. The more successful approach would have been to do as I did before: set up just a basic WinXP installation in my Windows dual-boot, create a VM from that, and then install additional programs on the VM. I didn't want to do it that way because I wanted to have a Windows native boot that was more or less the same as my Windows VMs, and I didn't want to have to invest twice the time in installing and configuring all those various programs, add-ins, etc. So, to go through it more carefully, here's what would happen in this VM. The VM booted. It loaded the programs I had installed in my Startup folder. It gave me various messages (e.g., "30 days left for activation. To activate Windows now, click here."). I ran Windows Explorer and verified that the Internet connection was active. I went into Control Panel > System > Hardware > Device Manager. There, I saw a yellow circle with a black exclamation mark in it, next to "Other devices - Video Controller (VGA Compatible)." I right-clicked on that and chose "Update driver." This gave me, "Welcome to the Hardware Update Wizard." As before, I chose "Install the software automatically (Recommended)," and after a short pause, that gave me "Cannot Install this Hardware." I did a Google search and found that there didn't seem to be many people having this problem. Actually, I was one of the few. In a previous post, I had apparently found that I was supposed to be looking for a driver for a "VMware SVGA II" video adapter, which was more than Device Manager had been willing to tell me. In Device Manager, I right-clicked on the yellow-exclamation-marked "Video Controller" item and chose Properties > General > Reinstall Driver > Install from a list or specific location > Next > Don't search. That gave me a list of hardware items, but none of them had names beginning with "VMware." I chose Display Adapters > Next, but this gave me, "Unable to find any drivers for this device." One poster said s/he had gotten relief from this problem after, among other things, proceeding to install the mouse drivers. I thought maybe just skipping the problem on this boot would give VMware a chance to install other hardware drivers to adjust to this new setup, so I canceled out of Device Manager and waited for the system to identify and install some more hardware. But nothing happened. Everything else was installed already, as I now recalled from what I had just seen in Device Manager. Lacking other ideas, I decided to reboot. Things were unchanged. I did another Google search. One post said something about needing a minimum of 128MB RAM for the VM. That wasn't a problem, but maybe the opposite was: I saw that VMware was allocating over 3GB to this VM. I wanted it to get a maximum of 1GB. I had to start VMware as root in order to change it. I went to Ubuntu's Terminal and typed "sudo vmware." Then, in VMware, I went to Edit > Preferences. I didn't change anything there, but I did notice the option of setting hardware compatibility to previous versions of VMware. That seemed like one possible solution; I had seen one post where somebody had found a working video driver in an older version of Workstation (5.5.3). Still in Workstation as root, I next went to VM > Settings > Hardware and changed the Memory setting to 1024MB. Also, although I was running a triple-core processor, I thought I might as well try changing the Processors setting to One instead of Two; maybe VMware would let other VMs use the other cores. For the Display setting, I changed from "Use host settings for monitors" to "Specify settings for monitors," and I specified a maximum resolution of 1280 x 1024. I also checked the "Accelerate 3D graphics" box. In the Options tab, I set Shared Folders to "Always enabled" and I changed Guest Isolation to be "Enable VM communication interface (VMCI)." I saved those changes, quit Workstation, and restarted it the normal way (i.e., Ubuntu's Applications > System Tools > VMware Workstation option), and then started this VM. It started slowly, like before. But this time, when the Found New Hardware wizard came up, it was concerned with a different piece of hardware: not the virtual VGA graphics, but rather the Base System Device, whatever that was. I guessed that it went on to this problem because the wizard dialog box added a checkmark by default to the "Don't prompt me again to install this software" option, so apparently the system just went on to the next thing in that case. I went into Device Manager as above, and now saw I had not one, but two "Other devices" with the yellow exclamations: the Video Controller, and now this. I told the Found New Hardware Wizard to install automatically, but once again, it was not able to do so. In Device Manager, I right-clicked on these two items and chose Uninstall. I then chose VM > Install VMware Tools. I restarted the VM. The video and Base System hardware wizard installations failed again. I unchecked the "Don't prompt" option in each case and continued. Nothing else seemed to be happening, so I fired up Internet Explorer and went to Windows Update. It needed to validate my copy of Windows, and to do that it needed to activate it. It seemed like I had already activated it on the native WinXP installation; if so, apparently the VMware hardware was sufficiently different as to trigger Microsoft's anti-piracy sensors. So I activated. Now Microsoft Update told me there was just one update, an optional hardware update for my sound hardware, so I installed that. I re-ran it and there were no further updates. Device Manager still had the same two yellow exclamation items. I was stuck. I rebooted the VM and did another Google search. This time, when the Found New Hardware Wizard came up for the VGA, I chose "Install from a list or specific location" > "Don't search. I will choose the driver to install" > "Sound, video and game controllers." Unfortunately, that gave me only three game port options, so that wasn't the solution. I backed up and, instead of sound and video, I said "Show All Devices." The list of manufacturers that eventually came up didn't have any entries for VMware, SVGA, video, or graphics. It seemed I was in the wrong place, so I backed up one step. Ah! In the list of "Common hardware types," I had overlooked "Display adapters." I went with that, but it didn't make any difference. I got a message, "Unable to find any drivers for this device." I found a webpage where I could download a driver for SVGA II. It claimed to be version 11.11.0.0. It was actually an EXE file, and when I ran it, it said something about unplugging my USB Ethernet adapter. Apparently it was a driver for some kind of device I didn't have. It ended by saying the system would install it automatically. Whatever. I clicked Cancel on this and also on the Base System wizard. In the latter case, at least, I did it without unchecking the "Don't prompt me" option. This gave me a balloon: "Found New Hardware. A problem occurred . . . ." I restarted the VM. The VGA thing still didn't install; same Found New Hardware and Cannot Install This Hardware dialogs as before. I found another download page, a more official CNET one, for a driver for SVGA II version 10.7.2.0 that was dated September 30, 2001. But that just redirected me to the VMware download page, and they didn't have drivers, only complete Workstation packages. I went into Device Manager and decided to try updating the driver for the Base System Device. The update option led me to the "Common hardware types" dialog box again. This time, I selected "System devices." It showed only a "Compaq Deskpro Thermal Sensor." What? Well, OK; I clicked on Next. But the system gave me a warning, "Installing this device driver is not recommended because Windows cannot verify that it is compatible with your hardware." So forget that. I posted a question in a VMware forum. In a day or two, I had what looked like an answer. The explanation seemed to be that I was getting those yellow exclamation circles because VMware Tools were not actually installed. After clicking VM > Install VMware Tools, I was supposed to see VMware Tools listed in Windows Explorer as my new drive D -- as, in other words, a virtual CD drive. Sure enough, there it was. (It sounded like this could vary somewhat if I had received VMware Workstation on a CD. I didn't. I got it as a download. So this was just a virtual CD drive.) The advice was to run Setup.exe there. I did. It thought it was just taking an unbelievably long time to run, but then I decided to scroll around the screen and see what was going on. In other words, I couldn't see my whole Windows desktop at once, because VMware Tools was not yet installed. The resolution was too big. So now, when I scrolled to the top of the screen, I saw a dialog that said, "Please insert the Compact Disc labeled 'Windows XP CD-ROM' into your CD-ROM drive (D:) and then click OK." I did that. It started installing stuff -- including, I noticed, the SVGA driver. Along the way, it asked for the locations of various files. I had copied the I386 folder from the WinXP CD to my hard drive C before running Converter to create the VM, so for the most part I just had to point these dialogs to C:\I386 and they found what they were looking for there. Installation completed, and I got a dialog telling me I needed to reboot, which I did. Device Manager now showed no yellow exclamation circles. Everything was working normally. So that was the answer.

Windows 7 as Host: Choosing a Virtualization Program

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

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

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

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

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

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

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

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

Improving Performance in VMware Workstation 7.1

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

Section 1:  Hardware

A.  CPUs

1.  Hyperthreading

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

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

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

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

2.  MMU Virtualization

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.  Memory

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

C.  Storage

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

D.  Other Hardware

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

E.  Summary

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

Section 2:  Host Operating System

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

Section 3:  VMware Workstation and Virtual Machines

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Section 3:  Guest Operating System

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

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

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

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

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

Summary (for My Purposes) 

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