Remember that the default mode of operation for VMware player is to suspend a VM, so it's conceivable that you're resuming a VM that was already up and running in your original install of Player (you didn't mention this, but it's something that Player users tend to take for granted).

Although the virtual networks installed by VMware are remarkably good at providing a consistent environment for the guests, when you uninstall and reinstall VMware one of the things that sometimes happens is that the newly installed virtual networks don't have the identical virtual IP addresses reassigned to them. So, the guests need to re-acquire their IP addresses from the virtual DHCP server VMware is providing to the guest; since the guests aren't typically aware that the network in the host is different they don't do this automatically, so you can try explicitly restarting the guest OS so that it reinitializes itself in the new virtual environment.

The other thing to bear in mind is that every new major release of VMware includes updated VMWare Tools drivers, and you definitely will want to install updated VMware Tools in the guest VMs you have. This is particularly true with respect to Linuxes, since the VMware tools guest drivers in Linux editions are having to constantly fight the enormous amount of churn in the base OS platform. And now there are the Unity capabilities which need the latest VMware tools to use.

[ Since upgrading VMware tools uninstalls and reinstalls the device drivers in the guests, that's what I did to my suspended VMs today as I transitioned from Workstation 6 to 6.5 to get them back in play again; to start experimenting with Unity mode, I did end up restarting the Guest OS completely since for Unity to work, it creates variable-resolution display surfaces for the applications inside the guest to paint into the host windowing system. ]

Incidentally, I just tried and after using Workstation to update my existing VMs, I can report that Unity not only works well with 8.04, you do also get Unity with VMware player. So, update those tools!

Can you post the output of "ethtool eth0" and "ifconfig"?  The output of the lshw you provide shows that the system sees an Ethernet controller.  Now, we need to figure out how that controller is configured.  ethtool will show the duplex/speed settings.  ifconfig will give IP Address information.

Rad wrote on Oct 12^th, 2008 at 8:34pm:

Nope, via using VMware Workstation.

On first glance I didn't see that the VM appliance you chose doesn't appear to contain VMware tools at all, so it's getting by on the legacy hardware-emulated drivers inside the guest instead of the nice, fast, virtualization-aware ones (and that also means you don't have the easy drag-and-drop between host and guest or any of the other creature features that VMware tools has always given you).  

On the other hand I'd expect that it should just start working again if you fully shut down and reboot the guest OS rather than just suspending it as Player does for you when you close the VM window. I'll set that VM appliance to download so I can look at it myself (to see that it works fine here with 2.5) but that's an overnight job from down here.

Rad wrote on Oct 12^th, 2008 at 8:34pm:

Ah, right, you haven't used Workstation to create the VM in the first place so you're not familiar with the process.

Basically, the full editions of VMWare contain VMware tools installers for all the various guest OS's that VMWare supports, typically as .ISO files containing the requisite installers. So, for users of the real products you set up VMs by:
- build the initial blank VM for a guest using the VMware wizard in the host.
- install the guest OS, typically by mounting an ISO over the guest VM's virtual optical drive and starting the guest VM.
- use the "install VMware tools" option in VMware on the host.
  This menu option mounts the appropriate VMWare tools ISO onto the guest VM's virtual optical drive, and on Windows guests runs the installer for you.

For most flavours of Unix guests, you open the virtual CD inside the guest and then unpack the appropriate archive inside the guest OS and run the ./vmware-install.pl script which takes care of the rest for you.

- once that's done, enjoy the improved speed and smooth host integration that the tools give you.

Ubuntu 8.04, as is the way of things, chose to break compatibility with all existing third-party kernel drivers so the original VMware tools packages built into the VMware product didn't work and couldn't install on it (there were similar problems with OpenSolaris 2008.05, which broke the tools installer script by moving around a lot of the places things got put relative to genuine Solaris 10, and furthermore now the kernel interfaces for filesystems have been revised in an incompatible way from VFS4 to VFS5 in preparation for OpenSolaris 2008.11).

VMware tried to cope with this by creating an open-source project for the tools, which you can get from http://sourceforge.net/project/showfiles.php?group_id=204462 but it's always a struggle to correlate that variation versus the real VMware product versions of the tools, since they play leapfrog with each other a bit. For a while you had to use the "open" version to get support for the new kernels, but now as of Workstation 6.5 there are shiny new VMware tools ISOs for all the guests and I'm not sure whether the open versions match up with this new release yet or not.

To get the full benefit of Player 2.5 - in fact, to get any real benefit from upgrading to it - you really want to be running a VM appliance that was mastered for it with the current VMware tools using the matching version of Workstation. Upgrading the VM using Workstation is pretty easy, but without it, it's kinda a pain - you have to get into hand-editing the VMX file to reconfigure it and such like.

I'm with Nigel on this one - if this VM has been suspended rather than restarted, try a power cycle of the VM first.

Rad wrote on Oct 12^th, 2008 at 9:59pm:

Ya, your ifconfig shows your device was detected as eth2 instead of eth0.  No problem.  Run the command as 'ethtool eth2' instead.  Could you also post the output of 'netstat -r'?  That will show us what your OS routing table looks like - we are looking for your default gateway.  You should get something like:

$ netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu  Interface
default            ip68-227-240-1.ph. UGS         9  9825659      -   rl2
10.1.0/22          link#1             UC          1        0      -   rl0
10.1.1.2           00:03:47:c4:91:c8  UHLc        0   214621      -   rl0
10.1.4/23          link#8             UC          7        0      -   vlan2

We are looking for the one that says 'default' in the destination column.  In this case, my default gateway is 68.227.240.1.  If you can locate your default gateway, try to ping it from the command line.