I have this problem as well in a VM running Ubuntu 7.04, except that in my case the problem starts after about a day of using the VM. Restarting all the vmware services via fixes things for me for another day or so. I expanded the command line with full paths so I can put it in a bash alias and run it from anywhere:

[code]sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --stop; sleep 2; sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --start[/code]

Note: when I experience the problem, it's intermittent. DNS will come in and out (although it's more out than in).

Do other network services also become inaccessible?

This problem just started happening to me in Fusion 1.1.1 with a WinXP-SP2 guest.
Everything has been working great for months, and I don't believe I have changed
anything recently. If the network is in NAT mode, most DNS queries timeout in failure.
Everything works perfectly from the guest in bridged mode (IP directly from router),
and the Mac queries work perfectly. Somehow, the NAT service is not filling DNS requests
in time.

I ran some tests below. Please let me know what other tests may be of help.
-Brad

EDIT: my host in Mac OS X 10.4.11. Restarting Fusion helps for a few minutes,
and then lookups start to fail again. Records cached by windows continue to work.

Here is the output of nslookup from WIndows:
C:\>nslookup communities.vmware.com
DNS request timed out.
timeout was 2 seconds.

• Can't find server name for address 192.168.184.2: Timed out
• Default servers are not available

Server: UnKnown
Address: 192.168.184.2

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.

• Request to UnKnown timed-out

Here is the dump from wireshark during the above query:
No. Time Source Destination Protocol Info
1 0.000000 Vmware_71:ae:bd Broadcast ARP Who has 192.168.184.2? Tell 192.168.184.131

Frame 1 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: Vmware_71:ae:bd (00:0c:29:71:ae:bd), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

No. Time Source Destination Protocol Info
2 0.004653 Vmware_f2:c5:24 Vmware_71:ae:bd ARP 192.168.184.2 is at 00:50:56:f2:c5:24

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Vmware_f2:c5:24 (00:50:56:f2:c5:24), Dst: Vmware_71:ae:bd (00:0c:29:71:ae:bd)
Address Resolution Protocol (reply)

No. Time Source Destination Protocol Info
3 0.005526 192.168.184.131 192.168.184.2 DNS Standard query PTR 2.184.168.192.in-addr.arpa

Frame 3 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: Vmware_71:ae:bd (00:0c:29:71:ae:bd), Dst: Vmware_f2:c5:24 (00:50:56:f2:c5:24)
Internet Protocol, Src: 192.168.184.131 (192.168.184.131), Dst: 192.168.184.2 (192.168.184.2)
User Datagram Protocol, Src Port: re-conn-proto (1306), Dst Port: domain (53)
Domain Name System (query)

No. Time Source Destination Protocol Info
4 2.015341 192.168.184.131 192.168.184.2 DNS Standard query A communities.vmware.com.localdomain

Frame 4 (94 bytes on wire, 94 bytes captured)
Ethernet II, Src: Vmware_71:ae:bd (00:0c:29:71:ae:bd), Dst: Vmware_f2:c5:24 (00:50:56:f2:c5:24)
Internet Protocol, Src: 192.168.184.131 (192.168.184.131), Dst: 192.168.184.2 (192.168.184.2)
User Datagram Protocol, Src Port: pacmand (1307), Dst Port: domain (53)
Domain Name System (query)

No. Time Source Destination Protocol Info
5 4.028124 192.168.184.131 192.168.184.2 DNS Standard query A communities.vmware.com

Frame 5 (82 bytes on wire, 82 bytes captured)
Ethernet II, Src: Vmware_71:ae:bd (00:0c:29:71:ae:bd), Dst: Vmware_f2:c5:24 (00:50:56:f2:c5:24)
Internet Protocol, Src: 192.168.184.131 (192.168.184.131), Dst: 192.168.184.2 (192.168.184.2)
User Datagram Protocol, Src Port: jtag-server (1309), Dst Port: domain (53)
Domain Name System (query)

I restarted the vmnet-natd service, and everything is OK again.
If/when it happens again, I'll run the additional tests.
Thanks for the reply.

-Brad

Worked for me too, just did a sudo from the terminal. All's well. Thanks a lot

José

Interestingly, my SO upgraded her MacBook (early 2008) from 2GB of ram to 4GB of ram and the problem hasn't reappeared.... Perhaps some subtle swapping/resource issue?

I still see this on 2.0beta1, although it seems to happen less frequently. But there seems to be a correlation between the problem and a particular process that uses a lot of network. When I run JungleDisk in my Linux VM and use it to back up a remote server, it queries several gigs of data on the remote server, downloads some portion of that data to my local machine, and then uploads it to my backup server. This involves lots of network activity over a long period of time (a backup can take up to a day to complete), and DNS seems to break much more quickly when JD Is running a backup.