host eth0 interface changes to 192.168.56.1 after first run of virtualbox GUI breaking host network

[Luis Nunes]

Host runs Oracle Linux 6.2 Virtual Box 4.3.18, but also affects previous versions 4.2.

Upon Host boot the default active network is "eth0" with IP 192.168.1.50.

eth0      Link encap:Ethernet  ...
          inet addr:192.168.1.50  Bcast:192.168.1.255  Mask:255.255.255.0

The first time running virtualbox, or vboxmanage, or vboxheadless the interface "vboxnet0" is created and it becomes the default active network, and the interface eth0 IP is changed to 192.168.56.1, breaking the host network access.

eth0      Link encap:Ethernet  ...
          inet addr:192.168.56.1  Bcast:192.168.56.255  Mask:255.255.255.0

vboxnet0  Link encap:Ethernet  HWaddr 0A:00:27:00:00:00

The host is not reachable remotely. The workaround, if near to the host to login, is to switch the active interface "vboxnet0" to "eth0". The local access is not always possible if the host is on remote site. The result of switching back to "eth0" from the host GUI, is the IPs are corrected:

eth0      Link encap:Ethernet  ...
          inet addr:192.168.1.50  Bcast:192.168.1.255  Mask:255.255.255.0

vboxnet0  Link encap:Ethernet  HWaddr 0A:00:27:00:00:00
          inet addr:192.168.56.1  Bcast:192.168.56.255  Mask:255.255.255.0

After the interface switch, all other further runs of "virtualbox" GUI will not affect the interfaces. Need some clue how to solve this situation. Before the switch, If I work locally from the host, I can run the GUI and start the VMs. But I also have to switch the interfaces if I want to access the outside world from either the host or the guests.

Additional Host network info:

# cat ifcfg-eth0
DEVICE=eth0
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
IPADDR=192.168.1.50
PREFIX=24
GATEWAY=192.168.1.254
DNS1=192.168.1.254
HWADDR=C8:60:00:??:??:??
USERCTL=no

# cat ifcfg-vboxnet0
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.56.1
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME=vboxnet0
ONBOOT=yes
GATEWAY=192.168.1.254
DEVICE=vboxnet0
USERCTL=no

Network rules

# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c8:60:00:??:??:??", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x07d1:0x3c09 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1c:f0:??:??:??", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Appreciate help, solution. Thanks

[Luis Nunes]

I did some digging to seek a workaround using rc.local and doing so, I found, restarting the network the result is the same as calling virtualbox tool the first time after host boot. This doesn't remove the cause relates with vboxnet.

The eth0 interface IP is changed to 192.168.56.1. Interesting.

# /sbin/service network restart

eth0      Link encap:Ethernet  ...
          inet addr:192.168.56.1  Bcast:192.168.56.255  Mask:255.255.255.0

If this happens it too breaks any remote access to the host. To have network restart fix the network and not break it, I then edited ifcfg-vboxnet0 and changed ONBOOT=yes to ONBOOT=no (I think it should not be ON on boot in the first place).

With this changed I can fix the network after virtualbox breaks the network: Edit /etc/rc.d/rc.local with these lines:

su -c "/usr/bin/vboxmanage list hostonlyifs" oracle
/sbin/service network restart

The above is a workaround to fix the problem caused by the first line. Is there a explanation to what makes virtualbox break the network as it does with vboxnet0?

[Luis Nunes]

I solved the problem. The host events registered in /var/log/messages points out NetworkManager is controlling vboxnet, and if I'm correct it should not. If I'm wrong and NetworkManager may control vboxnet then something needs to be set.

Summary of what was happening as initially reported and also with the workaround: As per the host boot.log, my referenced workaround above in rc.local is invoked at 11:42. At 11:42 vboxmanage is called and eth0 becomes 192.168.56.1 and it seems by NetworkManager.

Here is the /var/log/messages summary of events, with what does what:

    11:41:52 - kernel - r8169: eth0: link up
    11:41:54 - avahi - Registering new address record for 192.168.1.50 on eth0.IPv4.
    11:41:54 - NetworkManager - Activation (eth0) starting connection 'System eth0'
    11:41:54 - NetworkManager - Activation (eth0) successful, device activated.

    11:42:02 - NetworkManager - (eth0): deactivating device (reason: 0)
    11:42:02 - avahi - Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.50

    11:42:02 - avahi - Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.56.1.
    11:42:02 - avahi - Registering new address record for 192.168.56.1 on eth0.IPv4.
    11:42:03 - NetworkManager - Policy set 'vboxnet0' (eth0) as default for IPv4 routing and DNS.
    11:42:03 - NetworkManager - Activation (eth0) successful, device activated.

NetworkManager (NM) is set to control all interfaces with "ifcfg-rg" as below:

# cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifcfg-rh

I figure its okay NM to control other interfaces but not vboxnet.

Solution: The best approach I've read is to leave NM manage all devices as above, and add NM_CONTROLLED=no to the ifcfg-vboxnet as exception t the controlled interfaces:

    # cat ifcfg-vboxnet0
    TYPE=Ethernet
    BOOTPROTO=none
    IPADDR=192.168.56.1
    PREFIX=24
    DEFROUTE=no
    IPV4_FAILURE_FATAL=yes
    IPV6INIT=no
    NAME=vboxnet0
    UUID=25652c17-0e6f-4bd9-aa16-f10b63efb9cb
    ONBOOT=no
    DEVICE=vboxnet0
    USERCTL=no
    NM_CONTROLLED=no

After the above change and rebooting the host, the interface eth0 was not changed when vboxmanage is called. No need for the rc.local workaround.

Plus, not having vboxnet0 managed by NM this interface got the IP 192.168.56.1 after called vboxmanage and not only after a VM starts (a situation found before solution).

In summary what was happening IMHO, after I call vboxmanage, NM finds a new device called vboxnet and detached current eth0 ip with the one belonging to vboxnet0, breaking remote access to eth0 and leaving vboxnet without an IP. Kind of strange what it did.

I would appreciate a comment from development, because, I want to leave NM working and not allowing it to manage vboxnet. Letting me know if other approaches keeping NM working is known.

Thanks.

[evit]

I'm having the same problem with VirtualBox 4.3.22 for Windows on Windows 7 Pro 64 Bit patched as of today. After virtual box install it disabled eth0 (first NIC) and I have no networking at all. From the command line it looks like the bridged network is being assigned to the physcial interface and that breaks connectivity.

I had to log in as Admin and disable and reenable both interfaces for it to sort of work. Not it keeps putting the card off line and online. Not sure how this bug reared its ugly head so often but it has.

[Valery Ushakov]

Replying to evit:

I'm having the same problem with VirtualBox 4.3.22 for Windows on Windows

This issue is Linux-specific. Some of the comments in #3866 describe what looks similar to your symptoms, but it might be better to file a new bug report. It's always easier to close one as a duplicate than to keep track of multiple unrelated problems in one bug report.

[Valery Ushakov]

Replying to lnunes_pt:

I solved the problem. The host events registered in /var/log/messages points out NetworkManager is controlling vboxnet, and if I'm correct it should not.

[...]

In summary what was happening IMHO, after I call vboxmanage, NM finds a new device called vboxnet and detached current eth0 ip with the one belonging to vboxnet0, breaking remote access to eth0 and leaving vboxnet without an IP. Kind of strange what it did.

I would appreciate a comment from development, because, I want to leave NM working and not allowing it to manage vboxnet. Letting me know if other approaches keeping NM working is known.

This looks like host misconfiguration of some sort to me. ifcfg-vboxnet0 shouldn't exist in the first place and VirtualBox installer does not create one. NM happily coexists with vboxnet* interfaces otherwise and debugging how your system ended up in this confused state is really out of scope for us.

[Luis Nunes]

My bad. I can confirm a new vboxnetN does not add ifcfg-vboxnetN. I understand I must had that file since very first intalled vbox version and left it. Don't remember why, but I suspect to have an IP pingable at host before any VM.

I see a new vboxnetN gets registered in /var/log/message and without IP until a VM guest using it starts. Confirmed by "ifconfig -a". I understand having a ifcfg file the IP will be available. I'll take on a note on that.

Okay cool, its good to know NM works with vboxnet. Thanks for your feedback.