Hi,
I'm trying to do something similar -- I wanted the ability to connect to a VM guest (OpenBSD) even if the host (Mac) wasn't attached to a routable network on any of its physical interfaces. In my case I'm using the VM to run a dedicated Postgresql server for Rails development on a MBP and want to be able to work even when disconnected from the rest of the world.
While I don't have a complete answer for you, I can tell you what seems to be working for me so far:
- Use host-only networking mode.
- From the host (Mac) side, open a shell/Terminal and use 'ifconfig -a' to see what subnet the virtual 'vmnet1' interface has assigned to it. (For example, on my machine it's 172.16.86.1)
- Use this info to configure:
-- guest's IP to an address on the same subnet within the .3 - .127 range (e.g. 172.16.86.10)
-- guest's gateway/router address to the address of the vmnet1 interface on the host Mac side (e.g. 172.16.86.1)
-- optionally, add IP/names to name-mapping files both in the VM and out on the host (e.g. /etc/hosts or LMHOSTS depending on the OS)
With this setup, I'm able to access the VM from the Mac side and vice-versa, even when the MBP is completely disconnected from any physical networks.
A few comments:
- Before using this method, I'd tried messing with Fusion's virtual dhcp server as well as OpenBSD's considerable dhcp client options, without success. At one point while still trying to use a dhcp-assigned address, I'd even considered using zeroconf/rendezvous/bonjour/howl/avahi running within the guest to see if I could get it to advertise itself back out to the host.
- Another method I'd considered (and abandoned) was running the VM in bridged mode and constructing a (physical) Ethernet loopback connector or even toting a portable network switch around, just to activate the host Mac's media layer. Perhaps this would have worked, but it struck me as a far too klugey solution for something that should be doable entirely in software.
- I'm not sure exactly how/when Fusion chooses the network addresses for vmnet1/8. (i.e. I don't know if it's when Fusion is first installed, if it's every time the vmnet-* daemons are relaunched, if it's only when
/Library/Application Support/VMware Fusion/vmware-config-net.pl
is run or when the vmnet1 interface is brought up with ifconfig). In short, the 172.16.x.x addresses
may be prone to change between host reboots. (See Dave Parson's guide below for more info)
- Just a reminder that host-only mode means that the VM can't see beyond the host, nor can anything outside the host access the VM. However since my intention was to use this setup even when I wasn't connected to an external net, this didn't matter to me.
- According to the Workstation 6 (see below) manual, addresses on the vmnet1 and vmnet8 interfaces within the x.x.x.3 to x.x.x.127 are supposed to be for statically-assigned ones. I'm taking this to mean the user can choose one of these without conflicting with ones handed out by the Fusion dhcp server.
- You may not actually need to specify a gateway/router address within the VM since it's just working within a local subnet. However some OSs get snarky if you don't give one.
- If you don't want to rely on editing /etc/hosts or LMHOSTS, I suppose one could take things further and run a nameserver within the VM or on the host instead.
Helpful resources:
- The Workstation 6 manual (pdf). While Workstation and Fusion are obviously not identical products, they share much of the same functionality and this document provides quite a bit of insight into their design. (The networking chapter is extremely helpful)
- Dave Parson's Fusion Networking Guide . In particular, it tells how to reconfigure Fusion's dhcp server to a different network range. While this was an extremely useful guide, I tend to prefer modifications that don't involve edits to global application settings. (e.g. I usually try to get things working the way I want by making changes within the VM itself or its .vmx)
Hope some of this helps.
