Can I determine the IP of a virtual machine using VMware Fusion without actually entering the operating system running on the virtual machine? I'm looking for a menu option, command line, or otherwise that I can issue against the virtual image with the VMware Fusion Software itself.
Thanks - Adron
VMWare provides, not surprisingly, a built in tool for this, vmrun. It's under /Applications/VMware Fusion.app/Contents/Library/vmrun although it has moved around in other Fusion releases a bit.
vmrun list
Total running VMs: 1
.docker/machine/machines/myvm.vmx
vmrun getGuestIPAddress ~/.docker/machine/machines/myvm.vmx
172.16.213.128
Here's a tip in case it helps anyone. Install avahi-daemon on the VM. This allows you to connect via hostname vmname.local, where vmname is the name of your virtual machine. In my case, the VM's name is baremetal and on the host I can run:
ssh baremetal.local
No need to know the VM's IP. :)
As Mikhail T. said, "Because VMWare is providing the NAT-ing, it ought to be able to tell us, what addresses it is currently NAT-ing for." Indeed it does:
In my VMware Fusion 6 installation, the vmnet-dhcpd daemon writes its leases to the files /var/db/vmware/vmnet-dhcpd-vmnetX.leases, where "X" is 1 and 8. Empirically :-) I established that it is vmnet8 that I should look for. Here is an excerpt from the lease file /var/db/vmware/vmnet-dhcpd-vmnet8.leases:
lease 192.168.177.129 {
starts 1 2014/02/17 09:34:19;
ends 1 2014/02/17 09:36:56;
hardware ethernet 00:0c:29:2b:2b:10;
client-hostname "ubuntu";
}
The client-hostname is the name of the VM and the number after the word lease is its IP. You can parse these entries or just simply look at the most recent ones. Make sure the lease you are looking at is still valid.
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.)
My solution to this was:
Once you have VMware tools installed, configure sharing, so that you can access a folder (any folder) from CentOS. Then, modify /etc/sysconfig/network-scripts/ifup-post to append your current date & ip address to a file in this shared folder.
How to do this:
Modify: /etc/sysconfig/network-scripts/ifup-post
add this before the last line of ifup-post ("exit 0"):
date >> /path/to/shared/folder/guest_ip.log
ifconfig >> /path/to/shared/folder/guest_ip.log
This will append your guest_ip.log with the date and return value of ifconfig each time the network comes up.
In my case, I decided to grep for a prefix of 192 on my ip address, since i know that between my home and work, it is always 192. This can be done by adjusting the above as follows:
date >> /path/to/shared/folder/guest_ip.log
ifconfig | grep 192 >> /path/to/shared/folder/guest_ip.log
I had the same issue while running VMPlayer on Ubuntu 15.04. My virtual machine was set to NAT, and though I could determine its ip address by logging into the gui and running ifconfig in the VM, I could't ping or ssh into it.
Turns out when VMPlayer installed, it didn't enable dhcp on the vmnet1 and vmnet8 adaptor. Solution was to use the ubuntu gui to edit the network connections with "Edit Connections". Find vmnet1 under ethernet, and hit the edit button. Under IPv4 settings, enable DHCP, save and reboot.
Now if you run ifconfig on the command line, you'll notice that the vmnet1 has a ip address. SSHing into the nat-ed VM from the host now works as well.
From the manpages of vmrun (version 1.14.4 build-3204469):
getGuestIPAddress Path to vmx file Gets the IP address of the guest
[-wait]
However, keep in mind that in order for this to work the VMware Tools suite should be installed in the guest OS and this step cannot be accomplished without logging to the guest OS. You can install the tools in a "base image" and create new images from it via cloning. Then you can use the above command to get the IP address of the newly created VMs.
arp -a| grep vmnet
? (172.16.65.132) at 0:c:29:83:1:e0 on vmnet8 ifscope [ethernet]
An IP address is purely the responsibility of an OS. Therefore, the virtual framework that holds the OS has no idea about the TCP/IP stack within unless there are symbiotic additions to the framework such as Hyper-V and VMware's additional guest tools (thanks to todda.speot.is in the comments below). It's not much different than wanting to browse the files on a VM without starting it up first.
Technically, if the VM relies on DHCP, you could search your DHCP server (likely your LAN's router) for the last lease that was handed out to the MAC address of the virtual NIC to get a good idea of what the IP would probably be the next time it launches. That's assuming that same IP wasn't handed out to another device in between when you looked at the lease history and when the VM started up.
