Using Localhost Loopback With Fusion

So you develop websites on your Mac using virtual hosts mapped to the usual localhost loopback (127.0.0.1). Everything is fine until you install virtualisation software such as VMware’s Fusion to fight IE’s dodgy rendering issues. Of course you prefer Fusion to recognise all your locally mapped DEV sites, but you can’t simply tell the virtualised Windows environment to use 127.0.0.1 since this will simply point back towards itself.

Suppose you have set up a virtual host for a site called sample.dev. This virtual host allows you to use URLs such as http://sample.dev/about-us/our-team.html

Now you want to be able to use that same virtual host in your virtualised environment (=guest environment). You’re just a few simple steps away from making this work for you.

1. Unique Loopback Address

   To make all this a little easier, I prefer to use a different loopback address than the standard 127.0.0.1. My preferred address is: 10.0.0.101. I’ll explain why I use this address later on.

2. Hosts file: Mac

   Ensure your sample.dev site is configured in your local hosts using the 10.0.0.101 address file as follows:

   
10.0.0.101 sample.dev
10.0.0.101 another-site.dev
10.0.0.101 yet-another-site.dev


   We’ll use the local IP address to bridge the guest and host environments. Please note that you can use any local IP address available to you (ie, not yet in use or assigned).

3. Host file: Windows

   Next, we’ll add the same lines to the host file of the guest environment: locate the file (windows/system32/drivers/etc on XP) and duplicate the Mac host file entries:

   
10.0.0.101 sample.dev
10.0.0.101 another-site.dev
10.0.0.101 yet-another-site.dev


4. Applying the Glue

   Now that we have configured the host(s) files on both the guest and host environments all we have left to do is create the actual bridge for these environments. We do this by adding an ifconfig directive to our system by using launchd or rc.local

   • launchd

     Introduced in OS X 10.4, launchd is a flexible way to start/stop/edit processes. To put it to our use, we’d create a plist entry in
     /Library/LaunchDaemons/

     We do this by opening a terminal window and typing:

     sudo touch /Library/LaunchDaemons/ifconfig.plist

     Next, open the file we just created in a text editor and add the following:

     <plist version="1.0">
         <dict>
             <key>Label</key>
                 <string>ifconfig</string>
             <key>ProgramArguments</key>
             <array>
                 <string>/sbin/ifconfig</string>
                 <string>lo0</string>
                 <string>alias</string>
                 <string>10.0.0.101</string>
                 <string>netmask</string>
                 <string>255.255.255.0</string>
             </array>
             <key>RunAtLoad</key>
             <true/>
         </dict>
     </plist>
     

     Finally, save and close the file.

   • rc.local

     The rc.local file runs in the background at system start up. While deprecated and essentially replaced in Leopard by the more flexible launchd, it still can be used to launch processes.

     rc.local can be found at /etc/rc.local. If you’re running a more recent system installation, chances are that you’ll have to create this file as OS X has not created this file by default since version 10.4.

     You can create the file by typing the following in your terminal window:

     sudo touch /etc/rc.local

     Now, open the file we just created in a text editor and add the following:

     ifconfig lo0 inet 10.0.0.101 netmask 255.255.255.0 alias

5. Almost done

   You may need to reboot both the hosted and the hosting environment in order to have these changes come into effect.

   Thanks to Rob Sanheim for his tips on the subject.

code