I've been using VMWare Workstation for several years now (after dumping VirtualPC when Microsoft bought them and promptly dropped support for Linux guest OS integration). As part of my recent upgrade to Windows Vista, I upgraded to VMWare Workstation 6.0 and had to re-enable all of my tricks to get everything working the way I like within the OS (and I had to find them all again as I hadn't written them down as I discovered them previously).
So, this time, I've decided to document them here so that others could benefit from them (and so I had them lying about for the next time I have to do the same). They are listed here in order of discovery (as opposed to any semblance of an order of importance). I will continue to come back to this and add new things from time to time as I run across them. If there's something of interest you thing should be added, let me know.
My configuration is that I have a Windows Vista host OS and two guest VMs, one running Windows XP Pro (as that is necessary for correct operation of many of our corporate tools), and one running Fedora Linux (where I do some open source development).
- ctrl-alt-del shuts down guest OS
I am using a windows host and I always lock the screen when I leave my desk/computer. Sometimes I happen to be in my linux VM at the time and this causes the linux system to log me out and/or shutdown, neither of which I appreciate, especially if I have lots of work in progress. I could figure out how to stop this within Linux, but I really just want VMWare to ignore the ctrl-alt-del and let me send one explicitly there if I need to.
I achieved this by adding the line:
to the "C:\Users\All Users\VMware\VMware Workstation\config.ini" file. This tells the VMWare to ignore the ctrl-alt-del and so the client's don't see it. If I want to send a ctrl-alt-del to the client, I use the VMWare defined ctrl-alt-ins combo.
mks.ctlAltDel.ignore = "TRUE"
- Shared Folders are slow in Windows XP Guest
My Windows XP guest was extremely slow in accessing shared folders (to the point that I didn't want to use them). At first I just thought this was normal, but then after a quick google search, I found this :
1) Create a text file called 'lmhosts' in the folder C:\WINDOWS\system32\drivers\etc - if it doesn't already exist. If it does, simply edit it. 2) Add the following line: 127.0.0.1 ".host" 3) Save the file.
This is done in the Guest OS and it worked like a charm, though I didn't consistently have the slowness problem before implementing this and didn't study it long enough to figure out the specific mixture of circumstances to cause the problem. Implementing this fix got rid of the problem in all situations (so far).
- Text input cursor icon disappears in Win XP guest
In my windows XP guest, the standard I-Beam text input mouse cursor icon (the one that is used when the mouse is over a text input field such as a field entry, or an edit box) would not show up. I would be left without an indication of where my cursor was. At first, with just editing some forms, this was just an annoyance, but later, when I went to edit a document or an email message, it was downright painful.
I first tried fixing this by changing the cursor icon. This worked in some cases, but left the most important (editing docs/emails) still broken. Some more searching (and this took a bit of work) and I found the right article in VMWare's forum which included:
In the guest, try dropping the display hardware acceleration down a notch. Start->Settings->Control Panel->Display Settings->Advanced->Troubleshoot->Hardware acceleration
Note that there's also a "Troubleshoot" button on the Settings Tab. This isn't the one, you want to use the Advanced button and then go to the Troubleshoot tab.
For me, dropping it down one notch (to turn off some of the acceleration of the cursor operations) was all that was needed.
- Printing from a Windows XP Guest
Printing from my Windows XP host was a problem as I would sometimes be connected to the corporate VPN and sometimes not. While on the VPN, the printers on the system's local network were not available from the guest as the connection to the physical network was through a NATed VMNet and thus two levels away from the guest.
I worked around this by sharing the printer from my host OS and then using the host-host VMNet to access that "network" printer -- which was a local connection and thus allowed under our VPN configuration. This works whether or not the VPN is up and running.
- Conflict between Communicator and VMNet setup
In my Windows XP guest, I was unable to connect to our company's Microsoft Office Communicator SIP server. Playing around with this for a while, I was able to determine that the problem was related to my host-only VMNet. Disabling the VMNet allowed Communicator to connect, enable it and Communicator would again fail to connect.
The problem was that the DHCP server was setting a DNS server in the guest host and the failure of that DNS host was causing the problems (probably timing) for Communicator. So, I disabled DHCP on that connection and hard-coded an IP address for the host and guest OSs manually and did *not* specify DNS servers for that connection (didn't need them) and voila, it all worked fine.