Why does my Debian VMWare virtual machine lose all network connections ~15 minutes after boot?

Question

I’m having a strange networking problem with a Debian (6) VMWare virtual machine on my Mac. Around 15 minutes after starting it up, I can no longer SSH into, view websites served from, or ping the VM.

I usually run the VM in headless mode, using vmrun -T fusion start VIRTUALMACHINEPATH nogui, but the problem occurs when I start the virtual machine via VMWare.app too.

When I use ifconfig to check the machine’s IP address once the network connections have failed (which I do via the GUI — launching VMWare.app after the server is inaccessible in headless mode gives me a GUI access to the server), the following line is missing:

 inet addr:192.168.231.137  Bcast:192.168.231.255  Mask:255.255.255.0

(This line is present when I boot up; it disappears after the network connections go down.)

This started happening yesterday, seemingly for no reason — the VM’s been running fine for a couple of weeks. I installed rsync on the VM yesterday, and was writing some Python code that used subprocess to start Xvfb and Selenium Server. I don’t know if that code somehow managed to permanently bork networking on the VM.

I’ve tried copying the .vdmx files and opening them in a VirtualBox virtual machine. The network issue doesn’t seem to happen there (i.e. the inet addr line in ifconfig stays present for over an hour); however, VirtualBox VMs don’t by default make the virtual machine accessible on the network, whereas VMWare seems to do so. I haven’t figured out how to turn on NAT port forwarding for incoming connections to the VirtualBox VM in the same way that VMWare is set up. (Both my VMWare and VitualBox virtual machines use NAT for networking.)

I’m a total networking idiot, so I don’t know if this is a VMWare issue, something I’ve managed to do in Linux, or some sort of random external attack — hence the cross-posting.

Solution

Sounds like a MAC duplication problem, i guess the VMware guest's MAC is same as another on the network, hence the loss of ip after some time. Try changing to NAT or change MAC address of VM if you use bridged mode.

Comments

[Alen Milakovic]

A fairly retarded approach to debugging this, though possibly an effective one, would be to install a second vm on your machine, and monitor both of them. This would help you eliminate some of the variables. Eg if the problem is peculiar to one vm and not the other. Alternatively, consider using a free software option. :-)

[penguin359]

Sounds like it's DHCP lease is expiring. Not sure why, but try running sudo /sbin/ifdown -a && sudo /sbin/ifup -a or sudo /sbin/dhclient when the problem happens. This means you won't be able to run headless for the test.

[Paul D. Waite]

@Faheem: No, that’s a really good idea. The problem mysteriously stopped happening yesterday (just as mysteriously as it started), but I’ll be keeping an eye on it. I think it might be something to do with the fact that, on my host MacBook, I switched between a normal wifi internet connection and a wifi-tethered iPhone connection whilst working on the VM — I reckon this might have confused it.

[Paul D. Waite]

@penguin359: sure, I’ll give that a go.

[Paul D. Waite]

@penguin359: alrighty, neither sudo /sbin/ifdown -a && sudo /sbin/ifup -a nor sudo /sbin/dhclient seemed to have any effect. ifconfig still returned the same results, and the VM was still inaccessible over the network.

[penguin359]

@Paul Sounding more like a VMware issue now. Anything from the kernel log? dmesg | tail

[Paul D. Waite]

@penguin359: sure, I guess it would be the most likely culprit. I can’t see anything that looks related to a networking issue via dmesg, although I’m not currently experiencing the issue, so I’ll check it again if/when it recurs. I’ve got a support call in with VMWare, so hopefully the problem will be found there and we can close this question off.

[Paul D. Waite]

@penguin359: I checked dmesg after the issue occurred again after a restart, and I couldn’t see anything different from the previous session when the issue didn’t occur. As such, I reckon this is a VMWare issue. If you want to pop in a little answer to that effect, I’d be delighted to accept and upvote it, I really appreciate your help here.