VMware has a cross-platform software package which helps guests function a little better. It's required to get certain things, such as hgfs (filesystem for sharing files between guest and host) and cut/paste support between guest and host working.
Kernel upgrades, and therefore distro upgrades, always cause problems with this stuff. Here's some earned wisdom on these upgrades. If you're planning to upgrade a VMware Ubuntu guest, I recommend printing it out, because you won't be able to Google for these answers if you wait until after you've upgraded ;-).
Networking Missing?
The first thing you should do after such an upgrade is "sudo modprobe pcnet32" if it isn't already installed. This driver is required for basic (non-vmxnet-accelerated) networking and you'll be pretty frustrated without it. If I understand things correctly, vmware-install.pl puts pcnet32 into /etc/modules.conf for you so it'll get loaded at the right time; but if something is wrong with your vmware-tools installation, it may not be present and you have to load it manually. (It comes with your kernel, you don't need vmware tools at all to use it.)
Network Comes Up but Wrong IPs?
Kernel (or maybe it's just distro) upgrades always seem to re-enumerate the network devices, if your guest has more than one. In plain English, your adapter "eth0" will become "eth1" and vice-versa. This applies to you if, for example, you use both bridged networking to get onto the Internet from the guest and a private host-only network. If you only have one network adapter in your guest, this probably isn't a problem for you.
To solve this, you may have to update /etc/network/interfaces and /etc/dhcp3/dhclient.conf and adjust for the renumbering of your adapters.
vmware-install.pl Didn't Work
You have to re-run this script every time you upgrade the kernel. You will probably also have to run it if you upgrade the vmware application itself. You will certainly have to run it if you upgrade your distro. The fastest way to run it is "sudo ./vmware-install.pl defaults", which doesn't ask you any questions.
The two most common problems I've had here are:
- Script won't even attempt to compile because it can't find your Linux source. Just run "sudo apt-get install linux-headers-$(uname -r)" first, and then "sudo ln -sf /usr/src/linux-headers-$(uname-r) /usr/src/linux". Re-run the script, and it will find the Linux sources this time. This step has to be done on every kernel upgrade, for reasons that will be obvious to anyone who has read this far.
- Some kind of compile error. The most recent one I had was that the 2.6.20 kernel wasn't yet tested with the vmxnet source, and a "wrong number of arguments" bug cropped up. I found these instructions to patch this problem. (I'll add this to the bottom, in diff -u format, in case the forum post drops off somehow.)
Resolution Woes
If you have a supported default resolution for your guest, you should be fine with "./vmware-install.pl defaults", which I believe will read your old config file and plug in the same resolution value you specified the first time you installed the tools. However, I have a funky monitor resolution: 1280x768. This is not one of the choices the script gives you, so I always have to manually tweak. Fortunately, it seems to be enough to just copy a 1280x800 in xorg.conf to 1280x768 and then change the default resolution in your "Screen"/"Display"/"24"-bit depth section to "Modes" "1280x768".
Mouse
To get a mousewheel to work, I changed protocol "ps/2" to protocol "imps/2".
The 2.6.19/2.6.20+ vmxnet Patch
--- vmxnet.c.orig 2007-03-01 14:04:27.000000000 -0800
+++ vmxnet.c 2007-03-01 13:57:29.000000000 -0800
@@ -1055,7 +1055,11 @@
vmxnet_netpoll(struct net_device *dev)
{
disable_irq(dev->irq);
+#if LINUX_VERSION_CODE <>irq, dev, NULL);
+#else
+ vmxnet_interrupt(dev->irq, dev);
+#endif
enable_irq(dev->irq);
}
#endif /* VMW_HAVE_POLL_CONTROLLER */
Posts
No comments:
Post a Comment