virtualbox.org

I have a problem with my bridged networking, here is the outline:

Host: Feodra 12 x64 with VirtualBox 4.0.6 (IP is X.X.X.18 on eth0)
Guest: Fedora 12 i386, use PCnet-II driver, IP is X.X.X.19 on eth1)

The guest is a webserver, a pretty popular one too. It was working fine yesterday when I left work at 5PM, then when I got home 30 minutes later there was a spike in CPU, to the point that I had to force close virtualbox and reboot the guest OS. Once I did that, the ethernet card could no longer get the IP unless I put it in manually through ifconfig. Even doing that only let me ping the host->guest and guest->host, but no where else not even the gateway. iptables is not used during all of this - I turned it off.

I have uninstalled Vbox and reinstalled, then created a new VM using the original .vdi for the webserver. Once I did this, the guest eth0 would not even launch - it complained that the device was inaccessible, even though the MAC was still the same. I used the fedora network manager in CLI in the guest to make a new interface, eth1. Doing this will work and eth1 comes up with the IP, but again the same issues as in the first paragraph.

Nothing changed, no one was in the system. Yet it broke... any ideas? I could really use some assistance. Let me know if I did not include any other important and info and I will reply with it.

To get back to the normal eth0 as the default edit the /etc/udev/rules.d/70-persistent-net.rules or you can delete the rules and Linux will configure it on the next boot.
Then if it still does not work you need to find out why instead of creating a new eth*. Most auto connect Linux NM's really look for the eth0 as their base, which can be changed but I see it making more of a problem than it is worth.

Thanks for the fast response.

I deleted the file and renamed eth1 to eth0 and did a reboot, but nothing has changed as far as the issue and its current results are concerned$

What's the next step?


Thanks again!

The next step is normal network troubleshooting.
Use tracert to see where the chain fails. You can also use IP addresses instead of URL to see if it is DNS failing.
I have also seen where the host actually caused the issue and it had to be rebooted to clear the problem. Routers too.