Everytime my host network access changes, Fusion restarts the NAT guest networks

[sr105]

Every time my ethernet link status changes, Fusion 5.0.3 restarts my NAT network for my Ubuntu 10.04 guest. This causes all of my SSH and NFS connections to freeze for up to 1-2 minutes. This also sometimes causes Fusion itself to beachball.

Why does it do this? How do I fix it?

Thanks.

[tracywang]

Have a look at: Understanding Networking in VMware Fusion

How about try Bridged mode instead?

[sr105]

If I put the VM in bridged mode, it will expose it to the network outside of my laptop and it will fail to work with my laptop when no external network is available. I chose NAT specifically because it's local, but when there's an external network available I can use it (to pull down guest OS updates for example).

From that link you gave:

NAT	Starbucks mode
Host-only	Airplane mode

I use my laptop with Fusion in these two types of places often. Maybe I'll switch to host-only mode and see it that's stable. However, I still contend that Fusion should not beachball when the ethernet link status changes on my laptop. It's not even my source of internet.

[nancyz]

sr105 wrote:

Every time my ethernet link status changes, Fusion 5.0.3 restarts my NAT network for my Ubuntu 10.04 guest. This causes all of my SSH and NFS connections to freeze for up to 1-2 minutes. This also sometimes causes Fusion itself to beachball.

Why does it do this? How do I fix it?

Thanks.

Hi sr105,

I think this should be expected behavior. NAT will should detect the link state change of your ethernet, when your network get alive, the VM network will work and will have the same network as your new network. Also, if the ubuntu is installed as physical , the OS will have the same behavior.

[sr105]

nancyz wrote:

the VM network will work and will have the same network as your new network.

It sounds like you're talking about Bridged networking.

Imagine a typical home network setup like this:

Laptop       -- Wireless NAT Router -- Cable Modem

Networked Printer --^

Now, imagine that the cable modem goes offline for some reason. Now, would you still expect to be able to print from the laptop? Certainly, the laptop and the printer are both on a private network. They won't be able to access the internet, but they can still talk to each other. VMWare Fusion's NAT router doesn't do this. When the cable modem goes away, Fusion brings down the *entire* network. This is the problem I'm trying to solve.

[nancyz]

They won't be able to access the internet, but they can still talk to each other. VMWare Fusion's NAT router doesn't do this. When the cable modem goes away, Fusion brings down the *entire* network. This is the problem I'm trying to solve.

Yes, NAT VMs still could talk to each other. They will have the same network as your Mac OS. If your Mac OS could acce the printer, NAT VMs will access it, too.

[tracywang]

Imagine a typical home network setup like this:

Laptop       -- Wireless NAT Router -- Cable Modem

Networked Printer --^

Based on your setup, when you at home, select Bridged mode for the VM, the VM should get a DHCP IP from wireless NAT router such as 192.168.0.x, and printer also get a DHCP IP address from router, you should be able to add the printer to the VM since it's in the same network.

[sr105]

Thank you all for your suggested work-arounds, but bridged networking is not what I want. I want my VMs to be on a private network (inaccessible from outside the host), but to still have access to the network outside the host. This is exactly NAT. The real problem is that Fusion 5 (and 6, too) restarts the NAT network when any host link changes. At most, Fusion should just update the routing table to indicate that the external network is no longer available (although, in my case, it is still available). The other reason I must use NAT is because I give my VMs static IPs so my host can easily access the VMs with constant addresses no matter what physical location my host is at.

Here's another detailed description that I just posted elsewhere about this problem with Fusion:

Whenever the link status changes on any external network interface to the host, Fusion restarts the NAT guest network. I'm not sure what it does to bridged or internal-only networking.

For example:

• Ubuntu 12.04 guest
• MacBook Pro with OSX 10.8.4
• VMware Fusion 5 or 6
• Wireless is default and active connection for host
• guest is using NAT
• Plug in thunderbolt ethernet adapter.

Now, dis-/connect the ethernet adapter to a hub or anything else that will cause a link status change. You'll see the network go down for the guest and resume within 15-60 seconds. I open an ssh connection to the guest from the host and run "watch -n 1 vmstat", but any continuous, regular output over the network will do.

Note: you don't need two external links to do this. Simply turning the wireless on/off above will achieve the same effect. The above scenario is simply a common one for me since I'm directly ethernet connected to a device I'm constantly rebooting for testing. Every time I reboot, my VM networking stalls. I've bought a small portable hub, to get around the problem.

[mudaltsov · Accepted solution]

Since NAT may use any (or all) of the host's interfaces, there's no way to tell which interfaces are being used at any given time. So if any host interface is disconnected, the VM's NAT interface needs to be reset. For most use cases, this is the appropriate safe behavior, otherwise the guest will never notice that the link state changed, and will leave stale connections until they time out.

However, it's understandable that there may be some situations where it's not ideal. It's possible to disable the NAT link state propagation for all NICs in the VM, and make NAT networks appear always connected, by adding the following line to the .vmx file:

vmnat.linkStatePropagation.disable = "TRUE"

Note that this is separate from the bridged interface link state propagation, which is controlled by individual ethernet#.linkStatePropagation.enable options.

[sr105]

Thank you, thank you, thank you. That setting did the trick.