The PDF manual is available here.
Here are some notes on my experiences, in reverse chronological order (the most recent up top).
Just for the record, I am running vmware workstation 5.5 on a linux host. We think every now and then (such as when this issue comes up), of upgrading to vmware workstation 6.0, but we are cheap and simple folks, and none of the 6.0 features really appeal to us, just the hint of fewer hassles like this.
Up to now, I was using version 115 of the any-any patch, downloaded from the site mentioned below. There are two subsequent versions of the any-any patch which, according to information on Peter Velichkov's Blog are promised to solve my problems.
The 116 patch is the real thing, you untar it any old place you like, then
run the ./runme.pl script and it finds things and patches them, just like the
115 patch did. However it does not cleanly run on my already patched system.
I get the following output when I run it:
Updating /usr/bin/vmware-config.pl ... corrupted Updating /usr/bin/vmware ... No patch needed/available Updating /usr/bin/vmnet-bridge ... No patch needed/available Updating /usr/lib/vmware/bin/vmware-vmx ... No patch needed/available Updating /usr/lib/vmware/bin-debug/vmware-vmx ... No patch needed/available VMware modules in "/usr/lib/vmware/modules/source" has been updated.I am ignoring the complaint about vmware-config.pl being corrupted, and just forging ahead. The main thing (I think/hope) is that it fixes up the stuff in /usr/lib/vmware/modules/source.
The 117 patch is a tiny collection of a few patch files (aimed to get things going with the 2.6.25 kernel). It is meant to just be dumped into /usr/lib/vmware/modules/source as near as I can tell. It would not go in cleanly, so I ended up untarring the vmmon.tar and vmnet.tar "tarball", printing out the diff files (they are context diffs after all) and applying the patch changes by hand, then rebuilding the tarballs. This seems to have worked with the 2.6.25.14-69.fc8 x86_64 kernel I am currently running.
Get the latest vmware-any-any file, untar it, and (as root) run runme.pl
and let it overwrite vmmon.tar and vmnet.tar (maybe even vmblock.tar) in /usr/lib.
Then you should be good to go.
Now, as to why you should have to do this for a commercial product, is a really good question.
vmware-vdiskmanager -x 32Gb "Windows XP Professional.vmdk"
It turns out, this is just part of what needs to be done, since the partitions (just one in my case) inside the virtual disk have not changed. You could add a partition (which suffers from the same drawbacks as described below for "adding another virtual disk). The answer here seems to be a nice little tool called gparted (The gnome partition editor). This is open source software and you can download a livecd, which is a convenient way to run it. In April of 2008, I found gparted-livecd-0.3.3-0.iso on sourceforge. (Actually 0.3.4-11 was available, I don't know why I ended up with 0.3.3, but it did work).
There are some shenanigans to get the live CD too boot. First I set up the ISO image as a virtual CDrom, but vmware just kept booting into windows XP. I discover the first trick is to turn on the virtual machine, quickly click in the window with the mouse, and then hit the ESC button to get a BIOS boot menu. You can hammer the ESC and function keys all day long, but until you click in the vmware window, the message doesn't get through. I select CD rom device, and whammo, I am booting the gparted disk. The next issue is something with video and the gparted disk. If I follow the default path, after I select the keyboard type, I get a black screen and all is locked up (or so it seems). The fix is to select a manual legacy video device, then later when presented with a menu, I went with Vesa, 24 bit, 1024 by 768 and things seemed to work.
I have always viewed using these partition growing tools much like playing russian roulette. At least with vmware you can easily backup your data by copying the .vmdk files. There were some uneasy moments when I first tried the enlarge my disk, gparted reported some kind of error and I was in an inconsistent state where gparted thought I had a 32G disk, but windows only was seeing a 8G disk. I rebooted gparted, shrank back to 8G, then grew to 16, 24, 30, and finally 32. Who knows what was wrong the first time, all these later attempts worked. Then when I boot into windows, it decides the disk needs a consistency check, and when it was done, all seems cool and I have a 32G partition with 24G free.
Another approach (and a more conservative and "safe" approach) would be to add a virtual disk, and indeed this is easy. With the virtual machine off, use the vmware toolbar VM->Settings->Add->Hard Disk and add a 16G drive. Getting windows to partition and format this is a bit more elusive, but Control Panel->Admin Tools->Computer Management->Storage->Disk Management leads to the right place, then right clicking on various places on the displays that are provided let you partition and format it (if you don't give up). Once the smoke clears from all this, I had a E: drive (with my system drive being the C: drive, and my cdrom being the D: drive). The next step is moving stuff around from the C: to the E: drive, and this is where this approach looses it's glamor in a serious way.
I have begun using VMware 5.5.1 (a commercial product), hosted on linux (Fedora Core 4 at present), to run the rare windows application, and for real-time OS development.
su rpm -Ivh VMware-workstation-5.5.1-19175.i386.rpm vmware-config.pl
This worked fine with Fedora Core 4, but broke when Fedora Core 5 came out, and after a long delay VMware 5.5.2 was released, to get it going I did as follows:
Download the 5.5.2 RPM from the WMware site, then:
su rpm -Uvh VMware-workstation-5.5.2-29772.i386.rpm /usr/bin/vmware-config.pl
This gets utterly confused when looking for the kernel include files in /usr/src/linux/include. In the good old days this was maintained as a link, but the new and less user friendly days require a bit of mischief as follows:
yum install kernel-devel yum install kernel-smp-devel cd /usr/src ; ln -s kernels/2.6.17-1.2187_FC5smp linux
Actually this is cheating (and this link will need to be removed and recreated whenever a new kernel comes along). The right thing to do is to tell vmware that the include files are found at:
/lib/modules/[uname -r]/buildNote that uname -r will expand to 2.6.17-1.2187_FC5smp
Note that it will be necessary to rerun wmware-config.pl (in /usr/bin) when my OS kernel is updated (probably fairly frequently). This must be done as root. This rebuilds (among other things) the vmmon module. It is quite painless and takes maybe a minute.
I loaded Windows XP Professional in one virtual machine from CD install media, and arranged another virtual machine to boot the Skidoo real time operating system.
Almost the first thing I wanted to get working (after installing VMware tools) was shared folders (which require vmware-tools). VM -> Settings -> Options -> Shared Folders gives a menu to set these up.
And then my display resolution is miniscule, but after installing VMware tools, you just go to my computer, find the gizmo to dork with display resolution and drag a slider to make it bigger.
Adventures in computing / tom@mmto.org