There’s No Place Like lo0
As Rob posted, I came up with an interesting solution to a problem yesterday, and I hadn’t seen it written up anywhere.
The problem was: You have a user on a Mac OS X system, running Windows on VMWare Fusion. They have application code running on the Mac side, and want to do browser testing via the Windows instance on VMWare.
Now if the Mac is online and has an IP address, you can just use that IP in the browser bar in Windows, and it will work. But what happens if you want a consistent URL between work, home, the coffee shop, and other places where your IP might switch? You could write a script that would inform your VMWare instance of your live IP, but that’s kludgy. What happens if you’re on a plane and don’t have any live networking? Then what.
You want an interface that’s always up, and that can have a static IP. That rules out the ethernet port (cable out, no networking, DHCP issues), or AirPort.
But wait! There IS an interface that’s always online. And it’s lo0, the localhost adapter. Sure, it doesn’t really go anywhere, but for inter-VM networking, you don’t care about that. And while it normally only hosts 127.0.0.1, the loopback address, it’s a “real” interface, so you can take advantage of IP aliasing.
Run as root:
ifconfig lo0 inet **10.0.0.100** netmask **255.255.255.0** alias
That will bind the IP 10.0.0.100 to your localhost adapter. You can adjust the IP address and netmask to taste – just make sure it’s a nonroutable IP, and hopefully one you won’t get assigned by your NAT device. Once that IP is up on the lo0 interface, you will be able to access it from VMWare. And it won’t change with the winds of DHCP, or even a lack of internetworking at all, giving you something consistent that you can refer to.
If you want to have that persist across reboots, edit the file /etc/rc.local as root and add that ifconfig line to it. rc.local is run by the system at the end of the boot process, so that will take care of it.
Hope this is useful!
on December 11th, 2007 at 2:09 pm
VMware already provides virtual interfaces between host and guests for exactly this purpose. (Been doing it for years - yes, on airplanes even
VMware sets up a private network between host and guests with a private IP range (I forget if it uses 192.168.* or 172.16.* addresses but same idea either way) - look at your list of interfaces for ones like vmnet1 and vmnet8 (just peeked at these on my laptop - they are in the 182.168.* range). Your specifics will change based on how you set up your networking, but you should see something similar.
Having said that, am I missing something that you were trying to accomplish that this doesn’t cover?
on December 11th, 2007 at 2:22 pm
Yeah, I’d forgotten about the vmnet# interfaces. That works as well.
on December 11th, 2007 at 2:24 pm
Two addendums to my previous comment.
1. The ones on my laptop are in the 1-9-2.168 range, typo above. And actually, only one is - the other is 172.16.170.*. But it’s the 192.168 one that does what you want.
and
2. You may have to run ifconfig from a terminal command line to see these on the Mac. I dunno if they show up in the GUI tools, I know the Parallels ones did but the VMware ones may not.
on December 11th, 2007 at 2:24 pm
I know the answer:
You don’t bury survivors!
on November 30th, 2008 at 4:22 pm
A little bit of a n00b at all of this and looking for a little help. I have an instance of BIND running on my host (Mac OS X) machine but don’t know how to get the VMWare guest (Windows XP) to use the DNS server on the host machine.
What do I do with the above IPs revealed by the vmnet#s?
Thanks a thousand times (in advance) for any pointers in the right direction.