We are using VMware Workstation 7 running on a Windows 7 Pro system. When trying to update the VMware Tools, either when starting a VM or manually using edit>preferences>updates, we receive a message that says "There was a problem updating a software component. Try again later and if the problem persists, contact VMware Support or your system administrator." Has anyone else ran into this issue and, if so, how were you able to resolve it? The guest VM is a Windows XP Pro system that was converted over from a physical computer.
Cannot Update VMware Tools
vmware-workstationwindows-xp
Related Solutions
What's your budget? I mean, I can give you several really cool options but they may not fit your budget.
You can easily fit that into a 1U though.
UPDATE:
Now that we've established a budget of $1,000 or so...
- Quad core processor for sure.
- Decent motherboard that can handle as much memory as you can afford.
- As much RAM as you can afford
- Get a couple (or more) of 7,200RPM or better large drives. Speed over size but try for both.
- RAID if you can. (I'm not gunna get into a RAID-type discussion here)
- 64 bit base OS (I prefer Linux)
- VMWare workstation will be just fine for your purpose.
Obviously the more drives, etc you add to this thing the louder its going to be so I don't think you need to go too hog wild.
Hardware is getting cheaper all the time so you don't really need anything over the top... just enough to keep you happy for 1-2 years... then you can update/upgrade as you see fit.
I have seen a similar phenomen.
Symptoms sound not too similar at first sight: Windows Explorer sometimes hangs for a few seconds regardless whether a local disk or a network share is accessed.
But after some investigation I believe the hang is caused by a similar NetBIOS issue.
Some system details:
- Windows XP Pro SP3
- VMware Server 1.0.9 installed
- VMNet1 (host-only) network adapter and NetBOIS over TCP/IP enabled
- VMNet8 (NAT) network adapter and NetBOIS over TCP/IP enabled
- The system's only physical network adapter's static IP address is 192.168.10.111. This adapter is configured to use 192.168.10.192 as its only WINS server. MAC address: 00-16-17-FA-2C-D4
- On the VMNet1 adapter the system's static IP address is 192.168.137.1. No WINS server configured. MAC address: 00-50-56-C0-00-01
- On the VMNet8 adapter the system's static address is 192.168.145.1. No WINS server configured. MAC address: 00-50-56-C0-00-08
- All VMs are configured to use NAT but are stopped anyway.
I was running Wireshark all day sniffing packets on the physical adapter. I noticed that whenever Explorer hung for a few seconds simultaneously a NetBIOS Name Service query packet was sent to the WINS server. These packets contained one of the VMNet adapter's address as its source IP address!
Here's one of the suspicious packets:
Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
Transaction ID: 0x82a5
Flags: 0x0000 (Name query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN
I think this is not correct. The packet's source IP address should be set to 192.168.10.111 instead.
I haven't sniffed packets on the WINS server's interface. But I expect it to send a reply to 192.168.145.1 via its default gateway since it is not connected to the 192.168.145.0 network. The gateway should reject this packet with "network unreachable".
As this is a UDP packet there's no connection in SYN_SENT state. But a TCP SYN packet that is "corrupted" in the same way should leave the connection in SYN_SENT state until a timeout occurs.
Some things I tried to work around this problem:
- Disable both the VMNet adapters: Problem solved. No suspicious packets.
- Re-enable VMnet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
- Disable VMNet1 and re-enable VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
- Enable both the VMNet adapters, but disable NetBIOS over TCP/IP for both: Problem solved. No suspicious packets.
- Re-enable NetBIOS over TCP/IP for VMNet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
- Disable NetBIOS over TCP/IP for VMNet1 and re-enable it for VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
- Change interface metrics from automatic metric to static values for all interfaces. The LAN adapter having the lowest metric: Explorer still hangs sometimes and suspicious packtes captured.
I have checked adapter ordering in Network Connections->Advanced->Advanced Settings as well as by running netsh interface ip show config. Local Area Connection is the first connection listed in both places.
Additionally I noticed some NTP packets with source IP address 192.168.137.1 as well as 192.168.145.1 being sent to 192.168.10.192 (it's an AD DC) via the physical adapter.
Best Answer
I had similar problem with vms migrated from vmware server to esxi. Uninstalling old vmware tools with 'add/remove programd' and installing new version from windows.iso solved the problem.