VMware Workstation 3.0: Upgrade Not as Easy as We Hoped
Dave Aiello wrote, "For the past few weeks, I have been trying to upgrade the copy of VMware Workstation on my Linux laptop. I expected to easily upgrade the existing virtual machines that I had on my laptop, and be able to utilize all of new features that we touted in our story about the VMware Workstation 3 shipment."
"Unfortunately, I ran into problems that I can only describe as frustrating when upgrading my Windows 2000 vitual machine. Read on for an explanation of what those problems were, and a couple of important tips to maximize the value of the time spent upgrading to 3.0."
Dave Aiello continued:
I began the upgrade process by reading the Workstation 3.0 Release Notes. This document is really important. If I had not followed its directions and backed up my existing virtual machines, I would have been in serious trouble, later on.
I have four vitual machines on my laptop:
- an Office Software Workstation running Windows 2000 and including primarily Office 2000, pcAnywhere, QuickBooks Pro, and Quicken;
- a Windows Web Development Machine running Windows NT 4.0 Service Pack 6 and including Netscape SuiteSpot 3.x, Microsoft SQL Server 6.5, MKS Toolkit, and pcAnywhere;
- a Windows Java Programming Machine running Windows NT 4.0 and including Netscape Enterprise Server 3.6, jRun 3.x, Epicentric Foundation Server 3, and JBuilder 5;
- a RedHat 6.2 Server Virtual Machine that I intended to use for Slashcode development, but never really used.
Backing these machines up was a pretty serious job in itself because of the limited disk space that I have available. Although I have a 20 gigabyte hard disk on my laptop, the amount of space in the Linux home partition is not sufficient to comfortably have both 6-8 gigabytes of virtual disks and gzipped backup copies of them as well.
Here is where my relative lack of Linux operating experience hurt me. I managed to use the GNU tar utility to create gzipped tar files of each virtual machine in /home/daiello/vmware, but the partition filled to 99 percent. For some reason, I could not effectively copy those files from one partition to another. When I tried to mv the files to other partitions in the file system, I experienced I/O errors in most cases. The work-around was to tar the files to the place I wanted to store them, but it took a few frustrating hours hours to realize this.
I wanted the new version of VMware so that my Windows 2000-based virtual machine would have USB. The Windows 2000 virtual machine, like most of my virtual machines, chafe under the 2 gigabyte virtual drive limitation of VMware Workstation 2. Creating a second 2 gigabyte virtual disk for each machine has always been an option, but machine configuration in these situations is not as smooth and simple as I would like. So, easily surmounting this limitation would be a big deal to me.
The first difficulty that I ran into that frustrated me was the fact that existing virtual disks still cannot be resized in VMware Workstation 3.0. I sort of assumed that with the increase in the maximum size of virtual disks, they would have created a way to resize them while the virtual machine was shut down. Apparently, they have not done this.
My next idea was to back up the user files from the Windows 2000 virtual machine and rebuild it from scratch with a new 3 or 4 gigabyte virtual disk. The easiest way to do this would be to use Samba to copy the files off the virtual disk directly to the native Linux file system. Once the virtual machine is rebuilt, I could copy the files back to the same relative places on the new virtual disk.
Easy? No. The problem is that when I installed VMware, I said I wanted the modified version of Samba that ships with VMware installed because I had not turned on the Samba that is native to my host machine. The VMware version of Samba is not at all necessary in my configuration anymore because of the implementation of virtual Network Address Translation (NAT).
I spent several hours with Samba and Linux books, and finally realized that I could not start Samba on the parent machine because the VMware version of Samba was already running. I tried uninstalling and reinstalling VMware. This did not solve the problem because the configuration file /etc/rc.d/init.d/vmware apparently was not fully recreated.
Here's an excerpt of the question I posed to VMware support about the issue:
I want to start the parent machine's native smbd and nmbd, but
the VMware versions of those daemons are already running. It appears that the file
/etc/rc.d/init.d/vmware contains the mechanism to start and stop the smbd and nmbd daemons, but the file is read only to me even when I am root.
Is it safe for me to chmod this file and change it so that the VMware versions of smbd and nmbd are never started? If so, how would you recommend doing it? Is there a better way to do this that I am not aware of?
Here is a brief summary of my progress toward fixing this problem:
- January 5, 2002: I have waited for VMware Support to reply to my question, but, I'm not sure that's worth my time. I am thinking about proceeding with editing the VMware configuration file and seeing what happens.
- January 6: I found a file called /etc/vmware/locations that contains variables that are used in /etc/rc.d/init.d/vmware. When I changed the value of VMNET_1_SAMBA from "yes" to "no", VMware's version of Samba no longer started when my machine entered runlevel 5 during startup.
In order to get the parent machine's Samba to start, I simply had to create an alias to the file that starts the Samba services at the proper runlevels. Once I figured out how to modify the VMware configuration, the rest was easy.
Conclusion
I would suggest that your milage may vary (YMMV) on the VMware Workstation upgrade. You will probably love it, if you don't have a significant investment in VMware 2 virtual machines. You will also benefit tremendously if you had VMware 2 virtual machines, you realize the limitations of the virtual machine upgrade process, and plan accordingly. But, it's more work than I expected, and the scope of the effort wasn't apparent to me until several weeks after my initial upgrade attempt.
This story will be updated as I continue to work through the VMware upgrade process.