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.

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 and VMware: New Installation

In January 2009, I decided to install plain-vanilla Ubuntu (i.e., not one of the official derivatives, e.g., Kubuntu, or many other unofficial distributions) on a new computer. This machine was running an AMD Phenom 8450 Triple-Core CPU on a Foxconn A7GM-S motherboard (with a maximum of 8GB RAM) and, at the start, a single 640GB Seagate hard drive. The latest release available at this time was Ubuntu 8.10 (meaning it was released in October 2008), known as Intrepid Ibex, so that was what I planned to install. I chose the 64-bit version of Intrepid because I wanted VMware to have access to more than the 32-bit maximum of 4GB of RAM. As with my 2007 and 2008 investigations of virtualization, I decided that VMware remained the best candidate for my virtualization needs. I had gone through many issues in the process of refining my VMware Workstation 6.0 (and, more recently, 6.5) installation, and this time around I hoped the process would be relatively straightforward. I installed Ubuntu on the target machine. Windows XP was already installed, and GRUB set up its usual menu. (I covered most of these details at length in my previous posts. For terms not defined here, use the search box at the top of this page to search my blog, and then use Ctrl-F or whatever is appropriate in your browser to find the specific locations where the terms are discussed.) Before the installation, I used a bootable GParted CD to add two Ubuntu partitions at the end, after my Windows NTFS partitions (for PROGRAMS, DATA, etc.) -- one for the Ubuntu program files, and the other for swap. That way, it was easier to see what I was doing when I got to the partitioning part of the Ubuntu installation. I modified the panels on my Ubuntu desktop, followed the steps to install my restricted NVIDIA graphics drivers, adjusted the font sizes in File Browser (Nautilus), and otherwise got the desktop in shape to suit me. Then it was time to install VMware. The file name was VMware-Workstation-6.5.0-118166.x86_64.bundle (meaning that I was installing the 64-bit version). To run it, I opened a Terminal session, navigated to the folder where the bundle file was located, and typed "sudo sh VMware-Workstation-6.5.0-118166.i386.bundle" (here, and elsewhere in these posts, without the quotation marks except as otherwise indicated). The installation was much smoother than it had been last time, when I had installed Workstation 6.0 instead of 6.5 (which was not out yet). In fact, the installation was painless and almost instantaneous. I rebooted into Windows XP and used VMware Converter to make a VMware virtual machine from that existing Windows installation. Unfortunately, when I booted back into Ubuntu, I found that VMware could barely run that VM. Performance was much, much worse than on my other computer -- partly because the VM was 40GB, larger than the 15-20GB VMs I ran on the other machine, but especially, I think, because I had only one hard drive. On the other machine, I had separate drives for Ubuntu program files, for data, and for the virtual machine. To speed things up, I ordered another hard drive. I had never owned a 10,000 RPM drive, but I found one on sale and decided to put my Windows and Ubuntu program files on it. I also revisited the Windows installation, removed some programs and otherwise got its size down to 15GB, used GParted to trim its size down to 25GB, and used VMware Converter to make another virtual machine. The next steps after that are the subject of a later post.