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.