It is possible -- at least, in the common case, where NAT-style network is configured for the guest. Because VMWare is providing the NAT-ing, it ought to be able to tell us, what addresses it is currently NAT-ing for. Something like vmrun list
should be outputting this information. That it does not is a flaw...
But, in any case, here is how one can find out anyway. First, run ifconfig
on your Mac (perhaps, ipconfig
would do the same on Windows, but I haven't tested it). This will list all network interfaces on the machine -- both physical and virtual. Look for the vmnet-ones. On my Mac this produces:
% ifconfig | grep -A2 ^vmnet
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:01
inet 192.168.82.1 netmask 0xffffff00 broadcast 192.168.82.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:08
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
So, my guest's IP is on either one of these two VM private networks: either 192.168.82.0/24 or 192.168.123.0/24. On your host there may be just one, lucky you, or more than two -- we need to check them all. Here is a very simple tcsh-script, entered directly on command-line, that did it for me. It attempts to ping each address in all of the class-C private networks managed by vmnet and ends, when a ping succeeds. The -W 500
option tells ping to wait only half a second for a response (could, probably, use even less), and the -c 1
tells it to send exactly one packet:
% set i=2
% while ( $i < 255 )
while? ping -W 500 -c 1 192.168.82.$i && break
while? ping -W 500 -c 1 192.168.123.$i && break
while? @ i++
while? end
The above little script ran for some time listing all the unsuccessful attempts to reach the non-existent addresses:
PING 192.168.82.2 (192.168.82.2): 56 data bytes
--- 192.168.82.2 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
PING 192.168.123.2 (192.168.123.2): 56 data bytes
...
Until it finally succeeded and finished:
64 bytes from 192.168.123.130: icmp_seq=0 ttl=64 time=0.307 ms
--- 192.168.123.130 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
Voilà, I was able to ssh into my guest:
% ssh 192.168.123.130
Password:
Now, I only had a single guest running -- so the first IP-address to respond to a ping was the right one. If you run multiple guests at once, you may need to use the same or similar ping command to build a list of all such valid private IP-addresses and then try them all until you get into the correct guest...
(And, maybe, .130 is a good guess for NAT-based addresses anyway. But I can't say for sure.)
It's amazing that vmware doesn't make this drop-dead obvious and easy like other vms! Cheers for the avahi answer, and nmap if you're desperate, but still - Big fail, VMware! – nealmcb – 2015-02-08T04:55:39.733
If you know the MAC address of the virtual machine NIC you could always try to leverage your host machine's ARP cache, or reverse ARP. – ta.speot.is – 2011-12-31T00:59:50.187