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.

Two Computers: Dividing the Workload

In this post, as part of my New Year's housecleaning, I introduce several investigations, involving various ways of setting up two computers in a workspace.

*  *  *  *  *

KVMs and Monitor-Sharing Options

I had developed the habit of working with two computers, using a KVM switch so I needed only one mouse and keyboard.  A KVM switch would let me use just one monitor with two computers:  it would be showing me what was happening on the computer that the mouse and keyboard were then connected to.

I had two monitors.  I didn't have them connected to the KVM.  Instead, I connected them directly to the two computers, one for each.  So the KVM switch would have me working on computer A or computer B, but monitor A would continue to show what was happening on computer A, and monitor B would continue to display the state of things on computer B.

Actually, one KVM had started malfunctioning, and I had replaced it with another.  In the process, I decided to disconnect the mouse from the KVM too.  So now the KVM just controlled the keyboard.  It made sense:  the keyboard was big.  I couldn't fit two keyboards on my desktop.  But I could fit two mice.  Mouse A, on the left side, was controlled by my left hand, and was controlling computer A, while mouse B was preoccupied with computer B on my right.  I wasn't sure if I liked this arrangement.  It had its advantages.  It gave my hands a more equal workout.  I could glance over at the other computer and click something, to make some process move ahead, without having to hit ScrollLock twice, which was how the KVM switched the keyboard back and forth.  The main problem was that it was hard to tell which computer the keyboard was controlling at any given time.  I was still occasionally hitting the Del key and deleting things on computer A and wondering why they weren't disappearing from monitor B.  It was a bit nutty.  But I was adapting and, like I say, it had its advantages, at least until I worked out something better.

The monitor situation was OK, too.  I had widescreen monitors, so I was able to accommodate a couple of different open windows at the same time on each of them.  But there were times when it would have been helpful to have both monitors attuned to just one computer.  I had previously used an arrangement where monitor A was dedicated to computer A, but monitor B was connected to a second KVM switch, so I could reach up and punch the button and switch monitor B back and forth between computer A and computer B.  This would let me use a multiple monitor approach on computer A, so as to spread out my work.  The problem with this was that, when there was no monitor turned on to computer B, I tended not to use it.  That was a problem because the purpose of having two computers was to let me continue to work when one of them would crash or need maintenance or get involved in some process, like scanning or rendering, that would make it virtually unavailable for other purposes.  I also used this arrangement to write these blog posts, tinkering with one machine and recording the steps in the other.  I found that, if I got too fixated on one computer, the other one tended not to be organized and capable enough to take over when I needed it.

There didn't seem to be a way to share one monitor between two computers simultaneously, with computer B running in a little window in the corner -- a real "monitor" as distinct from a big display.  There was the option of buying a little display, connecting it to the second DVI connector on computer B, and putting it off to the side, so I would always have that information about what was happening on computer B.  But that little monitor would cost more than $100.  I could probably go down to Goodwill and pick up an old CRT for less than $10, but the other problem was that it would still be more clutter, more heat, more power consumption.  And the desk didn't have room for it, so it would have to go onto a side table or shelf or something.  I would also need a video card, since my motherboard only supported one monitor.

A decision on that question of how to use multiple monitors would await the outcome of an investigation of various non-KVM strategies.

*  *  *  *  *

Dual-Booting and Virtual Machines

Over the past couple of years, my two computers had different missions.  Computer A was running Windows XP in a VMware virtual machine on Ubuntu.  Computer B was running WinXP natively.  Now I was moving away from Ubuntu and back to Windows.  I had planned to just install Windows 7 on both.  I'd been having problems with my WinXP installation on computer B, even when I restored from an image, so it seemed like a good time to upgrade rather than continue to fight it.

I liked the idea of dual-booting WinXP and Win7.  Actually, though, I rarely used my dual-boot setups.  I pretty much always went with one or the other.  Right now, for instance, I already had a dual-boot Ubuntu and WinXP setup on computer B, but I couldn't remember the last time I had gone into Ubuntu there.

Meanwhile, on computer A, it seemed like I should consider just replacing Ubuntu with Win7:  continue to run WinXP in a virtual machine (VM), that is, but run it on Windows 7 instead of Ubuntu.  This would give me access to the familiar way of doing things in WinXP, while easing the transition to Win7.  I looked into the VM option in more detail.  It looked like I would be able to use the Windows version of VMware Workstation as long as I wasn't using my Workstation license in Ubuntu.  So the tentative plan was to have WinXP running in VMware on Win7 on one machine, while just running Windows (either XP or 7) natively (i.e., without a VM) on the other.

Although I was moving away from Ubuntu, it occurred to me that this strategy would leave a door open for a possible return to Ubuntu.  Ubuntu had been far more stable than WinXP.  Assuming the virtualization setup worked, I could install Ubuntu as a VM on Win7, essentially reversing what I had tried to do previously, and I could thus continue to identify projects and programs that Ubuntu could handle just as well as Windows for my purposes.

*  *  *  *  *

Differences Between Machines

The decisions described above meant that, contrary to my assumptions, I probably should not set up identical hardware on both computers.  Computer A was probably going to need more muscle to handle the VMs.  WinXP on computer B had been struggling to run video editing software, though that may have been due to a flawed installation.

Part of the tradeoff here was simplicity versus options.  The more operating systems and hardware arrangements I had in play, the more different ways I had of configuring things, and the more time it would take.  I had always viewed the computer hobbying as a means to an end of being more productive, while having its own intrinsic interest too, and for that reason I had tended to think, in recent years, in terms of getting myself set up for the next six months or a year.  During that kind of timeframe, the problems of a setup would tend to emerge and sometimes become overwhelming.  The current Windows XP installation was a case in point.  I had been able to nurse it along despite its obvious dysfunctionality, occasionally replacing its current state with an Acronis image backup, but it was now crashing one or more times per day.  So, oddly, in this case it was the simpler installation that had become the more problematic.

The switch from Windows XP to Windows 7 probably meant that I would be spending quite a bit of time getting up to speed on the best way to configure the latter.  I was probably going to install it in a RAID array, for purposes of performance, with an external backup option.  There would be some things to figure out and play with.  Most likely, some hardware would be getting shuffled around.  So, contrary to my first thoughts during this particular housecleaning, it did not appear likely that the two computers would take on any clear definition:  they would not be mirror images of one another, in hardware terms, so as to simplify maintenance, and they would also not feature one being considerably more powerful than the other.  The plan for the coming six months to a year was just to make them both capable and to explore options without investing more time than I wanted to spare for this kind of project.

Since I was now in a period of computer housecleaning, it seemed likely that my posts over the next few weeks would explore these considerations in more detail.

Acronis True Image Plus Pack: Converting a Virtual Machine to a Physical Machine

I was using Windows XP as the guest operating system in a virtual machine (VM) on VMware Workstation 7.1, running on Ubuntu 10.04 (Lucid Lynx).  I had developed a customized WinXP installation in that VM.  Now I wanted to install that same tweaked version in physical form, as a dual-boot option on that computer.  I did not want to go through all of the time-consuming steps that had been required to create that tweaked installation.  I hoped, instead, that it would be possible somehow to convert the VM to a physical installation.  This post describes what I tried and learned in that effort.

The fact that both the VM and the physical dual-boot installation would be on the same computer did not necessarily make things easier.  VMware VMs used virtual hardware that did not match my physical hardware.  In other words, simply making an image of the VM and restoring it to the physical machine would run into the same problems as if I made an image on one physical computer and restored it on another.  That's not to say it couldn't be done.  It would just require more than a simple image-and-restore procedure.

There seemed to be a couple of different ways to go.  Through a search, I found that VMware itself offered a virtual-to-physical (V2P) conversion procedure.  This would permit conversion of the .vmdk file directly to a physical installation.  That procedure was quite complex, however, and that meant there could be quite a few ways in which it might not go exactly according to plan.  There was also the problem that, according to the detailed description, they had not actually tested it on Windows XP.  It seemed that it might be worth investing the time in this procedure if I were going to do this frequently.  A quick glance suggested that many of the steps would only be hard or time-consuming the first time around.  For my purposes, though, I was not sure that this would be much faster than just reinstalling Windows from scratch, and it would probably be less reliable.

What looked more promising was to try the Universal Restore feature of Acronis True Image 2011 (ATI).  Universal Restore was available through the Plus Pack that had to be purchased in addition to ATI itself.  The combination of ATI and Plus Pack, together, would cost around $80 unless you got it on sale.  The general concept seemed to be that you would install ATI, install the Plus Pack, create a bootable ATI CD (or USB drive) that would automatically include the Universal Restore capability (provided you did install the Plus Pack first), use that to make an image of the VM, and then restore that image to the physical machine.  So this is what I decided to try.

When I started poking around the Acronis website in search of guidance on the details of the Universal Restore process, I came across a link to a search of the Acronis KnowledgeBase.  This turned up more than a thousand entries.  A quick scan of some of the first search results suggested that some of those entries existed because people had run into problems in the Universal Restore process.  It seemed I would need to brace myself for a somewhat finicky and potentially time-consuming effort.  I decided to go ahead with it, though.  Unlike the VMware V2P process, I knew that I had used Acronis many times in recent years, and I figured I would probably be using this procedure again, or something related to it.  So it would hopefully be a productive time investment.

The Universal Restore process was emphatically a restore process.  The instructions I planned to follow began with the assumption that I already had an Acronis image of the VM that I wanted to convert to a physical installation.  I thought, at first, that making an image of a virtual machine would be a matter of setting up VMware Workstation so that it would boot from the Acronis CD or USB drive (or, conceivably, from an ISO).  I had already worked through that setup process in another post.  So now I just had to insert my Acronis CD, boot the VM, and make the backup image on a Windows-compatible (e.g., NTFS) partition.  The VM booted, saw the CD, and Acronis started.  In my tweaked Windows installation, I had put the paging file on a separate virtual partition, so I didn't include that in the backup.

For the destination of my backup, unfortunately, I had a problem.  Within this virtual world, Acronis didn't see my "network" drives -- that is, the physical drives located within this same computer that VMware treated as though they were on a network.  I bailed out of the backup process and went into Acronis's Tools & Utilities > Add New Disk.  But that didn't provide a solution either.  My searches didn't lead to an answer.  A seemingly off-target post gave me the idea that maybe the solution was to install Acronis inside the VM and then try to do the backup there.  So I did that, and it worked.  I saved the system backup to a separate NTFS formatted drive, so that it would be visible to my Acronis CD.

I rebooted the system with the Acronis CD in the drive, and went into Acronis.  I selected Recover > My Disks > Browse and went to the image I wanted to restore.  I chose the Universal Restore option and, hoping that Acronis had already loaded itself into memory, I took out the Acronis CD and inserted my motherboard's driver installation CD.  Then I told Acronis to Add Search Path for the CD drive.  I told it to restore both drive C and the MBR and Track 0.  I designated the new partition where I wanted this to be restored to.  I named that same disk as the target for the MBR recovery.  I went ahead and the recovery process got underway.  After a while, I got an error message,

Device driver 'PCID\VEN_1002&DEV_4390&SUBSYS_B0021458&REV_00' for 'Microsoft Windows XP Professional' cannot be found.

So, oops, apparently Acronis was looking for the drivers that it did include on its own Universal Restore CD, not for the motherboard drivers.  It seemed that I should have left the Acronis CD in the drive for the time being.  The dialog did not give me a "retry" option, so it looked like this restoration might be toast.  I reinserted the Acronis CD, clicked Cancel, and started over.  But after I re-entered the target location and other options, it froze.  I punched the computer's reset button and re-restarted.  So then it went ahead and did the recovery.  But then it wound up at the same error message.  A search for that device driver name produced only four webpages, none in English, but a search for the vendor suggested that Acronis wanted the ATI driver, which I guessed meant the video driver.  So apparently it had not necessarily been a mistake to leave the motherboard's driver CD in the drive, first time around.

My hunch as to the nature of this problem was that simply pointing the installer to the CD drive was not specific enough; it was not going to search all of the subdirectories on the CD to find what it needed.  I put the motherboard CD back in the drive.  I decided, this time, to click the "Ignore" button on the dialog, so it would move on past this error and show me what came next.  Boom!  It immediately said, "Recover operation succeeded."  I wasn't sure it had needed or even looked at the motherboard CD at all.  I took out the CD, closed Acronis, and the system rebooted.  I turned off the power before it got itself fully back up again and disconnected the hard drive that contained my original dual-boot installation of Windows XP, so that now it would have to boot from the newly restored Windows XP partition or nothing.  And the answer was:  nothing.  I got "Error loading operating system."

I did a search and found that, for Patrink Zink, the solution was just to do a cold reboot.  Another thread emphasized connecting the new drive to the same SATA port as the previous program drive.  Another thread made me wonder whether it would have helped to create the target partition in Acronis rather than using GParted.  Yet another thread said something about drivers.  I figured that was the answer.  Apparently whatever I had done with the Acronis CD was a flop.  Just out of curiosity, I booted from the Windows XP installation CD and went into the Recovery Console.  I got there by pressing F8 a bunch of times before the "Error loading operating system" message could come up.  Normally, that would have put me into WinXP's Safe Mode, but apparently Safe Mode was not interested in helping me out.  In Recovery Console, I poked around enough to verify that something resembling a Windows operating system had indeed been installed on the drive.  I typed "chkdsk /r" and let that run.  Then I typed "fixboot" and then "fixmbr."  Then I tried rebooting from the hard drive.  No joy; still "error loading operating system."

I started over again with the Acronis CD.  Following the Acronis guide page, I looked for hard drive controller drivers or chipset drivers.  There was a GSATA folder in the BootDrv folder of the motherboard driver CD, so I designated that as the place for Acronis to look for what it wanted.  But Acronis said "No items to display" when I went to that folder, making me think that it was not finding the right drivers there.  I went into the Chipset folder on the CD, but same thing there.  After checking about 20 folders and finding that none of them had any items that the CD wished to display, I went back to the BootDrv\GSATA folder and designated that, and then proceeded with the recovery process.  It gave me the same error (above).  When it was done, I rebooted.  This time, instead of giving me an "Error loading operating system" message, the cursor just sat there after the "Boot from CD/DVD" line.

I gave it five or ten minutes and then shut the machine down.  I unplugged the new drive and reconnected the old one.  But then -- what's this?  It froze after "Boot from CD/DVD" even though the new drive wasn't connected!  I shut the machine down again, and this time I also disconnected the other hard drive, where I had stored the Acronis backup.  So now only the old Windows program drive was connected.  That worked:  I now got the GRUB2 menu, and the choice of going into Ubuntu or WinXP.  I tried starting the machine again, this time with only the new Windows program drive connected, using the same SATA cable as I had just used with the old drive.  But it was no use:  I got "Error loading operating system" again.

It occurred to me that this was a basic bootup problem, and for that purpose I could try the approach mentioned on another thread.  I had already installed WinXP on this computer, but only in a basic form; I was going to all this trouble because I didn't want to spend the time and effort to install all my Windows programs and configure them.  So far, that decision wasn't paying off.  But I thought perhaps I could copy the needed files from that existing basic Windows installation to my newly created Windows installation from the VM.  So I put the system back the way it was originally, without the new drive, and booted into Ubuntu.  I connected the new drive as an external USB drive and ran a file-comparison utility to see what was different between the files in the basic Windows XP installation and this new one.  (The utility I used was Beyond Compare.)  I really couldn't identify anything that I should be copying over from one to the other.

Collegedropout said that WinXP could have boot problems when the BIOS was set to recognize hard drives as "Auto."  The solution, s/he said, was to change it to "Large."  I tried that, and rebooted with only the new WinXP drive connected.  In my system's BIOS, this setting was located under Standard CMOS Features.  I had to hit Enter at each hard drive and then change Access Mode to Large.  This did not affect the problem, so I changed it back.

I was tempted to set up the Ubuntu dual-boot on the new drive and see if the Ubuntu bootloader would make any difference, but I decided there was probably no way around it:  I was going to have to figure out what they were talking about, when they referred to "chipset drivers."  I went into Device Manager to get the properties for the SATA hard drive controller (Start > Run > devmgmt.msc), but I didn't see it.  I did have the option of putting in a service request to Acronis, but at this ponit I decided I had invested enough time in this experiment.  I decided to just install WinXP manually on the new drive, and to see if I could return Acronis True Image Home 2011 and/or its Plus Pack for a refund.

Installing Windows XP SP3 in VMware Workstation 7.1 on Ubuntu 10.04

I had decided to stay with VMware Workstation 7.1 for a while longer, adopting a wait-and-see strategy toward VirtualBox and whatever other virtualization developments might be underway.  A couple of years had passed since I had first installed Windows XP on VMware Workstation in Ubuntu.  My old virtual machines (VMs) were creaking and malfunctioning.  It was time to create a new WinXP VM.

I had obtained mixed results from efforts to use VMware Converter to build VMs from existing WinXP installations or other sources.  I decided to build a fresh installation, installing XP within a newly created VM.  I had already installed VMware Workstation.  Now I started it as root user by typing "sudo vmware," and then I went into Ubuntu's Applications > Accessories > Terminal.  In Workstation, I went into Edit > Preferences and adjusted the settings that would apply to all VMs, some of which could only be set by root.  In the Preferences > Workspace tab, I went with the default settings for the most part.  For the default location of my VMs, I chose a partition on a separate hard drive for better performance.  In the Display tab, I selected the three Autofit options.  I selected all of the Updates options.  In the Memory tab, I left about 1.5GB of RAM for the system; the rest was for VMs.

When I was done with the settings, I killed that session and restarted VMware as a normal user.  I created a new VM with these characteristics:

• I started with a 40GB independent, persistent SCSI VM, but ran into some problems when I tried to shrink it, and ultimately had to start over.  Since it was easier to grow a VM than to shrink it, I decided on 20GB to start.  Although I initially created this as a preallocated space, it seemed that clones (which I made from time to time as backup, as the installation and tweaking process went along) would default to being non-preallocated, and I decided that was actually better until things got settled, because non-preallocated drives were smaller and therefore easier to clone and to back up.
• A 4GB independent, persistent IDE virtual drive, within this VM, for the paging file (VM > Settings > Hardware > Add).  This, I discovered, was best created after WinXP was installed.  Otherwise, WinXP was quite capable of brainlessly installing itself into this little partition and leaving the 20GB partition unused, thereby providing yet another reason to start over from the beginning.  Also, this drive was best created when the VM was powered down; only a SCSI (not preferred) drive could be created while the machine was powered up.  Note also that, as soon as you start down this path, Workstation may create a miniature version of a file for such a hard drive, even if you then abort the process -- in which case your later attempts to create that file may trigger strange results, until you investigate and delete any such runt file.
• 1.5GB RAM.  I had opted for 32-bit Ubuntu and WinXP after numerous previous hassles with 64-bit systems.  The discovery of PAE-enabled kernels meant I could go above the ordinary 32-bit limit of 4GB of RAM, so I was comfortable with this 1.5GB allocation for a single VM.  I could have gone higher, but I had almost never reached the point of using even this much.
• One single-core CPU.
• Based on my own usage, I set "Don't automatically connect" for floppy, USB devices,  or printer.
• Power:  enter full screen mode after powering on; close after powering off.
• Shared folders:  always enabled, map as network drive, make read/write only those that needed to be written to in Windows.
• No AutoProtect.
• Guest isolation:  enable drag and drop; enable copy and paste; don't enable VMCI.
• VMware Tools Updates:  use application default (currently update automatically).

Then I inserted the Windows XP CD and installed Windows XP, using a slipstreamed CD with Service Pack 3 (SP3) on it.  In my first attempt at this, I had to deal with the problem of making the VM boot from the CD.  I had just learned how to do this.  First, in Ubuntu's Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM, and then I went to the end of that file and added bios.bootDelay = "10000" and saved the edited file.  This gave me a ten-second delay on VMware's splash screen.  So then I had time, on reboot, to read the options and choose F2 for BIOS setup.  In BIOS setup, I chose Boot, moved the CD-ROM drive up to be first in the boot sequence, and then hit F10 to save and close.  Then I installed WinXP.  The process was completely automatic, this time; apparently the latest version of VMware Workstation was able to detect my settings from the underlying Ubuntu installation.

Once WinXP was done with its basic installation process, I right-clicked on the VMware Tools icon in the system tray (i.e., the lower-right-hand corner of the WinXP desktop), chose "Open VMware Tools," and selected all three items in the Options tab, and then closed that.  To get the Windows desktop to stretch all the way across the monitor, I used VMware's View > Stretch Guest (using the menu at the top of the screen), and then returned it to View > Autofit Guest, and for some reason that did it.  I had to map my network drives after listing them in Workstation's VM > Settings > Options > Shared Folders.  Then I turned to the process of tweaking my WinXP installation.  There are some additional VM-related notes in my post on that.  When I tried to open a PDF file from within the VM, I got a Default Host Application error message.  Another post discusses that problem.

I wanted to use Acronis TrueImage to make periodic images throughout the installation process, so as to capture each working state of the system in a single snapshot.  On a standalone WinXP installation, that would have been just a matter of inserting the Acronis CD and making the backup to a separate partition.  In the VM context, though, Acronis was only willing to recognize only those partitions that were defined as part of the VM.  What I did instead, then, was to power down the VM, use Nautilus to copy the entire VM's folder to an NTFS drive, boot Acronis, and make an image of that VM folder.  (I also made a .zip of it in 7zip, just in case.)

To get the system to pause before loading Windows within VMware, so that I would have time to make a decision to adjust the BIOS or choose boot devices, I edited the individual virtual machine as described in a previous post.  Basically, I set Workstation's VM > Settings > Hardware tab > CD/DVD > "Connect at power on" and "Use a physical device" (though I was intrigued by the "Use ISO image" option).  In Terminal, I typed "sudo gedit [path][filename].vmx," for the .vmx file pertaining to this VM; and at the end of that file I added a line that said this:

    bios.bootDelay = "10000"

and that bought me ten seconds instead of one or two, when that vmware logo came up.

*** NOTE ***

At this point, I stopped developing this post.  Several other system issues had to be taken care of first, and those were superseded by non-system tasks.  When I returned to this post several months later, my purpose was just to close it down.  I had decided, by that time, to stop working on VMware within Ubuntu.  The following fragments are the other notes I had left over, in incomplete form, when I ceased working on this post.

Fragmentary notes continue as follows:

*  *  *  *  *


At some point in the process, I started getting an error message when I was trying to shut down the WinXP VM:

End Program - VMwareUser.exe
This program is not responding.

I did a search and found that virtually nobody was having this problem.  That was not a good sign.  A different search suggested that lots of people were having problems of one sort or another with VMwareUser.exe.  That was not a good sign either.  I didn't have an answer for this problem at this time.

After adding another program, Windows Explorer began flashing, refreshing itself every couple of seconds, in what appeared to be a different network drive problem.  I have written up the process of solving that in a separate post.

After tweaking the WinXP installation, I began adding programs.  I installed Copernic Desktop Search as one of those programs.  VMware Workstation treated my data drives as network drives, and Copernic regarded network drives as a sign that I was in a workplace, so I could not use their free version with VMware.  I downloaded their professional version ($40 to buy) and used it on a trial basis.  It was not able to save its index to a network drive.  Its index, I heard somewhere, would be about 10% of the total size of the files being indexed.  So if I had 100GB worth of files, I would have a 10GB index.  I definitely did not want that kind of monster sitting on my drive C.  But there seemed to be no alternative.  I decided to add a third virtual hard drive (30GB max, not preallocated) to the VM, made it drive Q, and told Copernic to save its index there.  When Copernic was done with its indexing, that drive

The only tweak that didn't seem to work was the one where I went into Internet Explorer and tried to save its Temporary Internet Files folder to some drive other than C.  It wouldn't save to a network drive.  But it also wouldn't even save to the little drive that I had created to serve as a paging file.  Possibly there wasn't enough disk space available for it there.

In the interests of improving performance, I worked through a VMware document on that subject.

Windows XP in VMware Workstation: Default Host Application Error

I was running a Windows XP SP3 guest in VMware Workstation 7.1 on an Ubuntu 10.04 (Lucid Lynx) host.  When I tried to open a PDF file in the VM, I got a Default Host Application error message:

Default Host Application
Make sure the virtual machine's configuration allows the guest to open host applications.

A search for that sentence turned up no hits.  A modified search turned up only a few.  One thread led me to right-click on the PDF and select Open With.  There, for the first time ever, I saw the VMware icon and "Default Host Application" at the top of the list, labeled as the Recommended Program.  I clicked OK, but this put me back to the Default Host Application error message.  I guessed that maybe the problem was that I had already told Ubuntu to use Adobe Reader for Ubuntu (or maybe some other program) to be the default application for PDF files.  I had meant that to apply only when I was in Ubuntu, not when I was in a WinXP VM.  I checked VM > Settings > Options tab > Guest Isolation, and it did not have the box checked to "Enable VM communication interface (VMCI)."  So that seemed to be prohibiting the host (Ubuntu) from using its own default program to open the PDF when I was in the guest (WinXP).

The VMware Workstation 7.1 User's Manual made me wonder whether I had slipped into Unity mode, but I checked Workstation's View menu pick and, no, the setting was Autofit Guest.  I tried Open With again, but this time I browsed to the program that I wanted to use to read PDFs.  At this point, that program was Sumatra PDF.  But after I clicked on the Sumatra PDF .exe file, I was back at the Open With, and it had not remembered what I had just done.  I did it again; same result.  I tried WordPad instead.  It rendered the PDF as what looked like an XML file.  I closed that, went back to right-click > Open With, and this time the VM Default Host Application and WordPad were the only two programs listed.  Still no luck with Sumatra.  Another post made me think this was actually intended behavior, under the concept of "application sharing."  I didn't pursue that at this point.

In Windows Explorer, I went to Tools > Folder Options > File Types, scrolled down to the PDF file type, clicked Change, navigated to Sumatra . . . but still the same result:  it didn't remember what I had selected.  Following a tip, I went to Start > Run > CMD and typed "assoc .pdf."  This told me that the PDF file type was associated with pdf_auto_file.  A corresponding search led to the suggestion to go back into the File Types list, down to PDF, and click on Restore to reset it to the Windows default program for PDFs.  Now it wasn't set to run with anything.  I clicked on Change and navigated to Sumatra again, but it still didn't remember it.

The Microsoft Support page didn't seem to address this situation.  Ramesh, however, did provide an OpenWithAdd utility that added Sumatra to the Open With list.  After that, double-clicking on the PDF file opened the Open With list, with Sumatra PDF highlighted.  I clicked on the "Always use the selected program to open this kind of file" box and then OK.  I killed Sumatra, double-clicked on the PDF again, and this time Sumatra opened right up.  Problem solved!  Another way of doing it, if I hadn't wanted to run the OpenWithAdd utility, was apparently to use this registry edit:

[HKEY_CLASSES_ROOT\.pdf]
@="AcroExch.Document"

When I went to that location in my registry, I saw that it was still set to pdf_auto_file, so I made that change.  I wasn't sure whether that would have eliminated the need for the OpenWithAdd utility.

VMware Workstation 7.1: No Bootable Device Was Detected

I was using VMware Workstation 7.1 in an Ubuntu 10.04 host.  I had two Windows XP virtual machines (VMs).  One of them would start up and run without a problem.  The other one had done so previously, but was now failing to do so.  Both were pretty basic Windows installations.  There had been some hardware crashes and freezes, due to other system components, and apparently that had screwed up the one that was not starting.

Or so I thought.  I deleted the VM that was not working and recreated it from scratch, with a new WinXP installation in it.  But the problem was still there.  So, OK, I thought, the problem must be with Workstation.  So even though Workstation was still running the other VM without a problem, I uninstalled Workstation.  To do that, I used this command:  "sudo sh /usr/bin/vmware-installer --uninstall-product=vmware-workstation."  Then I reinstalled Workstation, using the same downloaded .bundle file that I had used for previous successful installations.  I opted to keep my configuration files.  Then I opened the two VMs.  Once again, the one VM ran fine; the other did not.

The one that was not functioning properly was proceeding as follows:  first, it would start in a nearly black screen with the VMware logo, as VMs typically did.  But then, instead of starting WinXP, it would take me to a screen that said "Network boot from AMD [number]" and "No boot filename received" and "Operating system not found."  It also flashed a message at the bottom right corner of the screen that said, "No bootable device was detected."

What caused this, I think, was that I was running a disk check from the WinXP CD on the other (working) VM, and then I attempted to start this (nonworking) VM without disabling its access to the CD drive.  So it latched onto the CD and started wanting to do its own disk check too, or something like that, and I killed it in a most awkward fashion, and now it was among the undead.

By process of elimination, the steps taken above seemed to suggest that Workstation's configuration files were holding a grudge against the nonworking VM, or anything bearing its name.  (I had created the new VM from scratch, but had given it the same name as the one that was previously nonworking.)  To test this, I could see what would happen with a new VM with a different name, or I could delete the VMware configuration files when I was reinstalling it.  Taking the easiest step first, I tried just right-clicking on the dud, in Workstation, to rename it.  That didn't work, so since Workstation had been nagging me to upgrade from 7.1.0 to 7.1.1 anyway, I shut down and uninstalled Workstation again, this time including the config files.  I ran "sudo vmware" and configured the program as root, and then I tried to start the nonfunctioning VM.  No dice.  And the other VM still ran.

But now I was aware of an additional difference.  I had saved the other VM in suspended mode, whereas I had shut down the nonworking one altogether.  What would happen if I tried to reboot the one that was still on its feet?  I tried it.  It rebooted fine.  Being in a suspended mode had somehow protected it, maybe.

Trying the other option, I created a new WinXP VM from scratch, but this time I gave it a different name, before deleting the other new (nonworking) one.  But I couldn't.  I got as far as the installation screen that says, "Install operating system from," and it wouldn't let me go any further.  The Next button was greyed out.  But then, duh, I thought maybe that was because I had set the system to not recognize the CD at bootup, not that that quite sense.  Or, I thought, maybe I screwed up the CD drive, or maybe I should do a cold restart.  So, OK, I shut down the computer altogether for 30 seconds, and then fired it back up.  That didn't work.  I killed Workstation.

It occurred to me to insert the WinXP CD back in the drive, setting the CD-ROM to connect at power on, and then start the VM.  That looked like it may have been the solution.  I got the Windows Setup screen, leading to WinXP's Recovery Console.  Evidently something in Ubuntu or Workstation or the VM got the idea that life was not going to be complete until it could lovingly caress that Windows installation CD one last time.  So when Windows Setup was done singing its song, it rebooted on its own and tried restarting the previously nonworking VM.

At this point, I realized I had made a dreadfully stupid mistake.  Although I knew better from previous experience, somehow I had assumed that WinXP was already installed on the VM.  It wasn't, and I think if I hadn't been so bored and burned out on computer stuff by this point, I would have realized that immediately.  What was actually going on was that I was trying to start a VM that did not yet have an operating system loaded on it.  Problems and solutions don't get much more obvious than this.  So anyway, now it was in the process of installing WinXP, as it would have done some time earlier if I'd had the WinXP CD in the drive and had enabled the drive in Workstation before those various reboots.

Resizing Virtual Disks in VMware Workstation 7.1 for Linux

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

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

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

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

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

bios.bootDelay = "10000"

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

Ultimately, I powered it off and deleted Reference--Master.  Taking a different approach, I recalled seeing indications that VMware Converter might provide an easier way to do some things related to the kind of process I was undertaking.  So I powered up Master, the original VM, and installed VMware Converter 4.0 (freeware) on it.  In Converter, I clicked on "Convert Machine" and specified the "Powered-on machine" > "This local machine."  The selected destination was "VMware Workstation or other VMware virtual machine."  I was able to specify a target size of 17GB.  Before I could proceed, though, I saw a banner message across the top:

Warning: Unable to locate the required Sysprep files.  Please upload them under 'C:\Documents and Settings\All Users\Application Data\VMare\Vmware vCenter Converter Standalone\sysprep\xp' on the Converter server machine. See 'Help' for more details.

Help didn't actually give me much additional information, beyond a repeat of that indication of the Sysprep file location.  I clicked Back, so that maybe Converter would search again after I located and installed those files.  It turned out that I had worked through some sysprep issues a year earlier, so I just went through that procedure again.  The only real difference was that, instead of copying setupcl.exe and sysprep.exe to C:\Sysprep, I copied them to the location specified in the foregoing quote.  I went through the rest of the Sysprep process and I guess I must have completed the Converter process, because the system did something or other and then shut down.  When it restarted, for some reason I was looking at a "Welcome to Microsoft Windows" screen, as though this were a new installation.  I played along with it.  I accepted the license agreement and entered the product key.  It defaulted to MASTERVM as the name of the computer, just as I had entered it into VMware Converter.  I wasn't sure how to answer some of the questions.  A search led me to a tutorial video and other sources, including one in VMware's Knowledgebase, regarding the step-by-step conversion process.  When the Windows setup process asked, "Will this computer connect directly to the Internet?" I ran a search but got surprisingly few hits and no clear answer, so I chose No. 
And then I was in Windows XP, and the first thing I got was this:

setup50.exe - No Disk
There is no disk in the drive. Please insert a disk into drive D:.

I clicked Cancel, but it came back.  I tried several times.  I tried Continue; same thing, and likewise for the remaining option, Try Again.  I noticed that the box in the upper right corner of the screen said this:

Personalized Settings
Setting up personalized settings for:
Outlook Express

and I noticed that the name of the program kept changing, and so did the error -- it had started out as set50.exe, but went on to shmgrate.exe and others.  So evidently we were stepping through dysfunctional installation of standard WinXP programs.  At some point, with one of those error messages still on the screen, I ran a search and got the idea to start Computer Management (Start > Run > compmgmt.msc).  There, I clicked on Storage > Disk Management.  This opened the Initialize and Convert Disk Wizard.  But that only initialized a 4GB drive that I had previously added to hold my VM's paging file.  Worse, Computer Management showed that drive C in this VM was still at 40GB.  It also appeared -- horrors -- that the name of this VM was Master.  Had we just screwed up my original VM?  It seemed so.  I shut down the VM and consulted reality.  What I found, on the disk, was no new VM and no converted VM.  Very confusing!  I restarted the Master VM.  No weird errors this time.  But the system was still as I just said:  no sign of any new VM.  So, OK, so much for that.  But I had no idea what had just happened.

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

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

Sound Device Problem in VMware Workstation 7

I was running Windows XP as a guest in a virtual machine (VM) in VMware Workstation 7 on an Ubuntu 9.10 (Karmic Koala) host.  When I used Workstation's VM > Removable Devices > Sound Card > Connect option, I got this error message:

Failed to open sound device /dev/audio:  Device or resource busy
Failed to connect virtual device sound.

I had also gotten this message:

Failed to open sound device /dev/dsp: Device or resource busy
Sound will not be available

I had been having this problem ever since I started using VMware.  I had previously changed the sound device (using VM > Settings > Hardware tab > Sound Card > Use physical sound card) from /dev/dsp to /dev/audio, and had also changed the sound card so that it would not connect at power on.  These and other efforts (e.g., rebooting) had fixed things temporarily, but then stopped working.

Some time back, I had found that I got this problem when Second Life was running in Ubuntu (that is, not in the WinXP guest).  More recently, I had had the same problem when Firefox was running in Ubuntu.  What I worked out that time was as follows:

For the time being, the solution seems to be either (a) to watch videos and other webpages that use Flash, do it in a browser session that is running inside your VM, not in a browser running in Ubuntu, or (b) after watching a video or otherwise using Flash in Ubuntu, kill the program that used it (e.g., Firefox) and manually reconnect with your sound card inside the VM.

So now I powered down my VM (i.e., not just suspended) and went into Workstation's VM > Settings > Sound Card option.  There, I put my settings at "Connect at power on" and Use physical sound card:  Auto detect.  I saved that and killed all browsers in Ubuntu, including Firefox and also Google Chrome.  I then powered on the VM.  WinXP had a hard time booting itself -- it always seemed to reboot a couple of times before it finally got itself together -- so while I was waiting, I started another session of Workstation and, in that one, I set the sound card to "Use physical sound card:  ALSA: Default sound card," and powered up that VM as well.  That one booted.  The one set to Auto Detect seemed frozen, so I changed it to "Use physical sound card:  OSS:  /dev/dsp" and tried again.  It gave me a notice that VMware Tools was not installed (it had been installed previously), but it booted, and Tools did appear to be running OK.

At this point, sound was working OK in the one that used ALSA, but not in the one using OSS.  That is, when I tried the virtual machine that was using VM > Removable Devices > Sound Card > Connect in the OSS, I got an error message.  I changed it to ALSA, like the other one, and then the sound worked in both.  The solution reached previously, of killing competing programs in Ubuntu, seemed to be the answer again.

Later, though -- after rebooting, I think, and anyway after running Firefox in Ubuntu again -- I found the audio was stuttering.  It stuttered at different speeds if I used ALSA or OSS, but either way it stuttered.

I played a sound file in the VM, and while it was stuttering along, I went to Ubuntu's System > Preferences > Sound > Applications tab.  There, I saw "ALSA plug-in [vmware-vmx]" listed, and underneath it I saw "No application is currently playing or recording audio."  That message was flickering on and off with each stutter in the sound.  A search along these lines led to a thread in which someone suggested reinstalling the ALSA packages.  In System > Administration > Synaptic Package Manager I did a quick search for ALSA.  I saw that I had a number of ALSA-related programs installed.  I started to mark one of them, alsa-base, for removal, but when I did so, Synaptic indicated that it would also need to remove a package called ubuntu-desktop.  That sounded pretty major, so I bailed out of the reinstall-ALSA approach.

I did a different search and came up with a thread in which someone said that VMware Workstation 7 supports ALSA perfectly, and if you are getting stuttering it may be because of a setting in the WinXP guest, not in Ubuntu or Workstation.  Following the advice there, I went into XP's Control Panel > Sounds and Audio Devices > Volume tab > Speaker settings > Advanced > Performance tab.  There, as advised, I set both the Hardware Acceleration and the Sample Rate Conversion Quality sliders to the lowest possible settings.  I clicked Apply and OK and then rebooted the XP guest.  With ALSA as the chosen sound card setting, and with the sound card connected in VM > Removable Devices > Sound Card, I found on reboot that I had no sound at all.  I tried changing from ALSA to OSS and auto detect and back to ALSA.  Now I could connect the sound card, and now I had sound.  But I still had stuttering.  I tried typing “/dev/audio” into the box in place of ALSA, and (after reconnecting the sound card) that sped up the stuttering but did not eliminate it.

I wondered if the stuttering was due to a larger problem with the VM.  I wondered this because its performance was generally slow at this point, and had been slow before I started this latest round of tinkering.  (In other words, I hadn’t caused that slowness just by playing with the sound problem.)  I suspended the VM and shut down the system.  Next day, I started the machine and tried again.  There was still a bit of stuttering, but the situation was much better.  (See also this other writeup on audio problems in Ubuntu and VMware.)

File Is Not Accessible. Access Is Denied.

I was using Windows XP in a VMware Workstation 7 virtual machine (VM), running on Ubuntu 9.10 (Karmic Koala).  In WinXP, I had moved some files to a new folder on a compressed external USB hard drive, and now I wanted to fiddle with the contents of that folder.  Unfortunately, I got this message:

[Filename] is not accessible.   

Access is denied.

I found a post that suggested that this might have something to do with folder sharing.  I went into VMware's VM > Settings > Options > Shared Folders.  There, I saw that the external drive was not included in the folders that were being shared.  I clicked Add, typed the name of the external drive, and went browsing for its host path.  But I couldn't add it; the dialog box was not seeing it.  It also wasn't visible in Ubuntu's Nautilus (i.e., File Browser), presumably because I had already connected to it in the VM, via VMware's VM > Removable Devices menu pick.  So now I disconnected it there, went back to Ubuntu, and waited for it to show up in Nautilus.  It didn't show up.  I went back to the VM to see what was going on, but it was definitely disconnected and was no longer visible in Windows Explorer.

Meanwhile, though, the external hard drive's light was on.  It was doing something, even though it did not seem to be recognized by any physical or virtual machines.  Some hours earlier, I had started it on a project of decompressing one of its folders.  That folder contained some large files.  So now it seemed that the drive was going to just stay locked in that process until it was done.  I left it for quite a while but, hours later, the hard drive light was still on, steady, without flickering.  I shut it down and started it back up.  Now, after a minute, Ubuntu saw it.  I went into the VM and connected to it.  When the VM saw it, I went back into VM > Settings > Options > Shared Folders and tried to add it.  But the VM still couldn't see it.  I suspected that the VM was reading from the fstab.  To explore that possibility, I disconnected from the USB drive in the VM, went back to Ubuntu, and, following some advice from one of my old posts, when Ubuntu saw the external drive again, I opened Terminal and typed "sudo blkid" and copied the UUID for the drive in question (named DAILY).  In a separate Terminal session, I typed "sudo gedit /etc/fstab" and added that UUID in two lines that looked like this:

# Entry for /dev/sde5 :

UUID=ADBG2454DBD /media/DAILY ntfs-3g defaults,locale=en_US.UTF-8 0 0

I went back into the VM and connected to the external USB drive again, and then tried again with the VM's Shared Folders option.  DAILY was still not visible there.  Maybe it was a question of what drives were visible when the VM started up?  This external drive was probably not connected and turned on at that time.  I rebooted the VM to see what would happen if DAILY was connected the whole time.  That definitely took care of the drive recognition problem, but I still got the "not accessible" error when I tried to go into the folder I was trying to view.  So I went back into the VM's Shared Folders setting and tried to add DAILY to the list of shared partitions.  Unfortunately, it was still not listed.  Ah, but back in Ubuntu, I had an error message:

Unable to mount DAILY

Error mounting:  mount exited with exit code 1: helper failed with:

mount:  only root can mount /dev/sde5 on /media/DAILY

This gave me an idea.  Did I have to be running Workstation as root in order to add DAILY as a Shared Folder in the VM?  I disconnected DAILY from the VM and went to Ubuntu to take a look at the drive permissions.  DAILY wasn't visible on Nautilus until I clicked the computer icon in the toolbar.  When I did that, it became visible on the right side of Nautilus, and that also reproduced the "Unable to mount DAILY" error message.  So it seemed that message had been generated by Ubuntu's effort to mount DAILY when I disconnected it from the VM.  But why did root have to mount DAILY?  I right-clicked on DAILY (on the right side of Nautilus) and went to Properties > Permissions.  But it said the permissions could not be determined.  So, OK, I ran "sudo nautilus" and tried that again.  But DAILY wasn't visible in Nautilus.  So I exited that and tried "sudo blkid."  DAILY was still at /dev/sde5.  nixCraft told me to make a mount point for it (in this case, "sudo mkdir /media/DAILY").  Now "sudo fdisk -l" told me that /dev/sde 5 was NTFS, in which case I could use "sudo mount -t ntfs -o nls=utf8,umask=0222 /dev/sde5 /media/DAILY" to mount it.  Now at least I was able to see that its permissions were root (not me).  Using "sudo nautilus," I went to File System > media and right-clicked on DAILY.  But I was not able to change its permissions; they changed back after I tried.  Following Merlin's advice, I went into Ubuntu's System > Administration > Users and Groups.  There, it looked like "ray" was the name of both my user and my group.  So I typed "sudo chown -R ray:ray /media/DAILY" to change the ownership of that drive (and everything on it) to ray.  This caused the external drive to grind away for maybe five minutes.  But the Permissions were still the same:  root.  Sebastian Abate made me think I might have to unmount the drive to change the permissions, and that the change of permissions would actually apply to the mount point, so I typed "sudo umount /media/DAILY."  Then I tried the "sudo chown" command again.  This time, of course, it did not make the external drive grind away.  Now I tried Sebastian's version of the "sudo mount" command:  first "sudo chmod 777 /media/DAILY" and that was the answer.  I now owned DAILY.

I went back into the VM, connected the external drive, and tried to play with it in Windows Explorer.  As I may have realized before (a day or two had passed by this point), the problem was peculiar to just one folder that I had created while the drive was owned by root.  So, OK, it seemed I needed to disconnect the drive from the VM again, go back to Ubuntu, and run "chmod -R 777 /media/DAILY."  The -R option would run the chmod command recursively, through everything on DAILY.  But that gave me "cannot access `/media/DAILY': Input/output error."  It sounded like this might have been caused by an improper shutdown, so I plugged the DAILY external drive into a WinXP computer, right-clicked on it, and did Properties > Tools > Check Now > Automatically fix file system errors > Start > Yes.  So now it would check that drive after I rebooted the Windows computer.  Meanwhile, I tried to manipulate that troublesome folder in Windows Explorer on that Windows machine, and what did I see but the same "access is denied" message!  It wasn't an Ubuntu or VM issue; it was an ntfs hard drive issue.  I rebooted and let CHKDSK do its thing.  Unfortunately, that didn't do it.  It seemed this folder was really very screwed up.  I rebooted with the Windows XP installation CD and ran CHKDSK /R from its Recovery Console.  For this 750GB hard drive, this took more than 24 hours to run twice (i.e., until CHKDSK /R reported no more errors fixed).  When it was done, I went back into that uncooperative folder.  Access was still denied.  I rebooted that dual-booting computer into Ubuntu and examined the folder there.  Ubuntu had no problems with it.  Right-clicking showed me that the folder was owned by root.  I re-ran chmod, this time specifying "sudo chmod -R 777 /media/DAILY/EXTERNAL," where "EXTERNAL" was the name of the folder in question.  This changed nothing.  I backed up another step to "sudo chown -R ray:ray /media/DAILY/EXTERNAL."  Then I re-ran chmod.  Still no change of permissions.  I tried "sudo nautilus," with Windows-style manual change of permissions but, as before, no effect.  WinXP's CHKDSK may have been good for the drive generally, but it did not seem to have changed anything regarding the recalcitrant directory.

Using Nautilus, I created a new folder, EXTERNAL2, and (in normal user mode, not root mode) I copied everything from EXTERNAL to EXTERNAL2.  Permissions were not changed.  I ran chown and chmod on EXTERNAL2.  As before, this changed nothing.  Using VMware Workstation, I went into a WinXP VM, set up DAILY as a shared folder, mapped it in Windows Explorer (Tools > Map Network Drive), and used WinEx to take another look.  Unlike in WinEx elsewhere, here I was able to view the contents of EXTERNAL and EXTERNAL2.  I deleted the contents of EXTERNAL2 in WinEx and copied them again from EXTERNAL.  Again, that in itself did not change permissions, nor did the same chown and chmod commands make any difference.  In Nautilus, I deleted EXTERNAL and renamed EXTERNAL2 to be EXTERNAL.  To delete EXTERNAL, I had to manually delete some files with names like .fuse_hidden0000ef520000009d.  In some cases, though, those files seemed to be recreated after deletion.  I found that I could delete them, one folder at a time, using the right-click Delete rather than hitting the Delete key, followed by F5.  So I did wind up with EXTERNAL2 renamed, in WinEx, to be EXTERNAL.  I bailed out of Ubuntu and rebooted into WinXP.  I noticed that, while the letters of EXTERNAL had previously been colored blue (indicating that it was a compressed folder, where it seemed that the problem may have arisen from an interruption of the compression process), this newly remade EXTERNAL folder was black (indicating no compression).  I was now able to go into EXTERNAL, see its contents, and rearrange its files and folders. I still did not know how to change its permissions in Ubuntu, but apparently that was not going to prevent me from working with it in Windows.

Summary

I think what fixed the drive was to view it in Ubuntu's Nautilus, make a copy of it, and then delete the original. I did not figure out how to change its permissions, but I was nonetheless now able to use it in Windows XP.

Ubuntu Linux, VMware, 64-bit WinXP Guest: Getting Online

I was using Ubuntu 9.04 (Jaunty Jackalope). On Ubuntu, I was running VMware Workstation 6.5.2. In VMware, I had just installed 64-bit Windows XP. I was now trying to get online.

At first, I thought the problem was with my Linksys WRT54GL Wireless-G 2.4GHz 54Mbps broadband router. I inserted the Linksys setup CD and ran through its setup steps. It said, "Checking your computer settings, Please wait." After a minute or so, it gave me an error message: "Setup Wizard MFC Application has encountered a problem and needs to close." It did this repeatedly. But when I connected the computer directly to my DSL modem, bypassing the router, I still couldn't go online. Anyway, a post I saw somewhere said that the Linksys setup CD was to set up the router, not the computer. The router had already been set up from a previous installation, so that didn't seem to be the issue. I was able to access the Internet in Firefox in the underlying Ubuntu layer, so the problem was just with getting Windows connected from within the virtual machine (VM).

In VMware, I went to VM > Settings > Network. I saw that it was set to Bridged. I believed it was supposed to be NAT, not Bridged, so I changed it. I did the same thing with Network Adapter 2. I saved that and tried again to go to a webpage in Internet Explorer, but once again got "The page cannot be displayed." I connected the computer directly to the DSL modem again. This didn't seem to make any difference, but I left it that way for the moment, just in case I had more than one problem.

It occurred to me that maybe I was supposed to restart VMware in order for the changes to take effect, so I suspended the WinXP VM, closed VMware, and restarted it. Just to test it, I started a different VM and tried to go online. Internet Explorer worked with no problems in that machine, but still wouldn't work in the new 64-bit WinXP VM. I dug out my AT&T Yahoo SBC installation CD -- I had forgotten that I had such a thing, but I got reminded of it when I ran Start > Settings > Network Connections > New Connection Wizard > Next > Connect to the Internet. All the hardware was already plugged in, so I moved pretty quickly to AT&T's Software Installation dialog. When I clicked there, I got a message, "You need to install an Ethernet adapter in your computer." So the problem seemed to be that Windows was not recognizing the VMware virtual network connector.

Looking again at the VM settings, I noticed that the working VM only had one Network Adapter. There was no Network Adapter 2 there. The VMware FAQs said there could be problems if you had two network interface cards (NICs), so I deleted Network Adapter 2. This didn't help with the AT&T installation; I was still getting the message that I needed to install an Ethernet adapter. A Google search for that message didn't turn up anything.

I went to Start > Settings > Control Panel > System > Hardware > Device Manager, as I should have done at the beginning. There, I saw a yellow question mark and a yellow circle with a black exclamation mark next to "Ethernet Controller." I right-clicked on it and said, Update driver. The Hardware Update Wizard couldn't find a driver. Someone said they had resolved this problem by installing a new WinXP x64 VM using the 64-bit rather than the default 32-bit WinXP setup. I powered down the VM and checked in VMware's "Edit virtual machine settings" option for that VM. It showed that, under Options > Guest Operating System, I had already indicated that the guest was Microsoft Windows, Windows XP Professional x64 Edition. This didn't seem like it was the problem in my case, so I posted a question on it.