Ticket #13873 (closed defect: invalid)

Opened 8 years ago

Last modified 7 years ago

Issue With Hostonly Adapter After Suspend

Reported by: jpulec Owned by:
Component: network/hostif Version: VirtualBox 4.3.18
Keywords: Cc:
Guest type: Linux Host type: Linux


Recently I have begun to notice that after suspending my host system (Ubuntu 14.10) while having virtual box running a guest (Ubuntu 12.04), I can no longer connect from my host.

I'm using Vagrant, so the guest is setup with NAT and a hostonly interface. After resuming, the NAT connection seems to work fine on the guest. I can still ping But if I try to ping the guest from the host there is no connection. However if I restart the VM a couple of times, it usually seems to start working normally again.

Should also note that there seems to be a LOT of vboxnet interfaces defined on my host machine (vboxnet0-vboxnet14) so maybe the issue lies somewhere there.


VBox.log Download (54.1 KB) - added by jpulec 8 years ago.

Change History

Changed 8 years ago by jpulec

comment:1 Changed 8 years ago by bulletmark

This problem happens to me also. I suspect it is reproducible for anybody. I am using an up-to-date Arch host with kernel 3.19.2-1-ARCH + VB 4.3.26-2.

  1. If you have the vboxnetadp module loaded (which is required for host-only networking) then when you start VB a vboxnet0 interface gets created. VB only needs to be started once for that to get created and it is left assigned even if you close down VB. It is the presence of that vboxnet interface which seems to cause the problem with resume. If you don't have a vboxnet interface assigned on your host then suspend/resume works OK (i.e. if you don't ever load vboxnetadp, i.e. if you don't want to use host-only networking on any guest).
  1. Now if you suspend and resume your host with vboxnet0 present, vboxnet0 sometimes (usually for me) "steals" the main static IP address normally assigned to my default host enp3s0 interface [The static IP address is configured as a "manual" address within NetworkManager]. The host enp3s0 interface is left un-assigned so the host boots without any network connectivity.
  1. If I use the GNOME network control panel to disable vboxnet0, and then enable enp3s0, then enp3s0 gets it's IP address back and all is well.
  1. Note that even if vboxnetadp is loaded, resume also works ok if I never start VB after a reboot, then I suspend/resume because in that case a vboxnet0 interface never got created.
Last edited 8 years ago by bulletmark (previous) (diff)

comment:2 Changed 8 years ago by frank

I don't get it how the vboxnetX interface could steal a DHCP-provided IP address. The vboxnetX address should not interfere the address range of the host interface (in your case enp3s0).

comment:3 Changed 8 years ago by bulletmark

Note I just corrected my above description. I had written that my normal host interface (enp3s0) got it's IP address via DHCP but actually it was set as a manual static IP in NetworkManager via the GNOME applet. The fundamental problem remains the same. That address gets assigned somehow to the vboxnet0 interface after a resume and enp3s0 gets left unassigned.

comment:4 Changed 7 years ago by nickjb

I have similar issue, Fedora 22 / 4.0.2-300.fc22.x86_64 running VirtualBox-4.3-4.3.28_100309_fedora18-1.x86_64.

On resume the vboxnet0 interface exists, but has no ip address i.e.

3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff

To get the interface back up and running i have to shutdown the VM's, close the vbox manager and start it and start a VM, then i get my host IP (host-only adapter) back

3: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet brd scope global vboxnet0
       valid_lft forever preferred_lft forever
    inet6 fe80::800:27ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever

Is there a better/simpler way, a command i can run upon resume to do this?

comment:5 Changed 7 years ago by nickjb

Also, on resume, vbox thinks the interface is available i.e.

# vboxmanage list hostonlyifs
Name:            vboxnet0
GUID:            786f6276-656e-4074-8000-0a0027000000
DHCP:            Disabled
IPV6Address:     fe80:0000:0000:0000:0800:27ff:fe00:0000
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-vboxnet0

comment:6 Changed 7 years ago by vushakov

  • Component changed from network to network/hostif

comment:7 follow-up: ↓ 8 Changed 7 years ago by HetMes

Same story. Ubuntu 64 15.04. Fresh machine install. Using Vagrant to manage the box.

I'd give you the VirtualBox version too, but you guys decided it would be best to not allow people to copy-paste it off the About box.

comment:8 in reply to: ↑ 7 Changed 7 years ago by frank

Replying to HetMes:

I'd give you the VirtualBox version too, but you guys decided it would be best to not allow people to copy-paste it off the About box.

Yes, and it's so complicated to write 6 digits/letters manually...

comment:9 Changed 7 years ago by NickBelhomme

Same issue here. Running vbox 4.3.28 r100309 vagrant 1.7.2 ubuntu 15.04 kernel 3.19.0-18-generic

comment:10 Changed 7 years ago by Gevorg

I seem to be having a similar or same issue while running vbox on Debian Jessie with XFCE with latest updates on Dell Precision 4700. Here's what I see:

When I don't start vbox, I am able to suspend and resume without issues. Debian works fine. However, when I start vbox which has a NAT network and a host-only network (vboxnet0) defined, in my network manager I see a vboxnet0 connection appear. So far so good, but when I close vbox manager, that connection (interface?) stays around and doesn't go away until I reboot (logout/login doesn't help).

When I try to suspend / resume, in some cases the suspend doesn't work (even if vbox is not running - but vboxnet0 is still around), in other cases resume doesn't work, in other cases resume happens but network manager tries to connect the vboxnet0 which it cannot.

As others have posted, I also have the issue of the virtual guest not being available after resume through the host-only interface. This is very challenging as a number of VMs I run use both NAT and host-only. So my workaround is to use the VMs but shutdown the PC (I do not suspend - as vboxnet0 interface is still around even if I close vbox and resume is flaky).

If I can provide any information, please let me know. Thank you very much for your support. I would log a Debian bug but since I am not using the package from Debian repository, I felt it was probably best to share my experience here.

Thank you.

comment:11 Changed 7 years ago by Gevorg

Sorry forgot to mention vbox version 4.3.28 r100309.

comment:12 Changed 7 years ago by vushakov

What is your network configuration on the host (network manager, systemd, etc)? What does your syslog says upon resume? This smells like the host misconfigures the network on resume. VirtualBox itself shouldn't do anything funny to the interface, not to mention somehow learning and "stealing" your primary static IP.

comment:13 Changed 7 years ago by LukeDunstan

I have a similar problem on a Windows 7 host with an Ubuntu 14.04 guest, but let me know if it should be a separate bug. The VM has two virtual NICs: the first one is NAT and the second one is host-only. On the host-only network both the guest and host have static IP addresses. When I suspend and then resume the host the NAT interface continues working but the host-only network no longer works. Both host and guest think that the network is available but cannot ping each other (host unreachable).

comment:14 Changed 7 years ago by MiCa

I have similar problem, but I've found a workaround without restarting the VM. Just detach and re-attach the network adapter would work for me.

comment:15 Changed 7 years ago by Grey Panther

I have the same problem (vboxnet interface disappearing after host goes to sleep / resumes).

  • Host OS: Ubuntu 15.04 64 bit
  • VBox version: 4.3.26_Ubuntu r98988

The interface is visible with all the right parameters if I do "vboxmanage list hostonlyifs", however it is absent from ifconfig / can't use it to connect to the VMs. Shutting down the VMs *and* the VBox GUI and restarting them fixes the problem.

Other tickets which seem to describe the same / related problem:

comment:16 Changed 7 years ago by zjwolber

I think I have a potential solution for those of you running NetworkManager.

  • Host OS: Arch Linux, 64 bit
  • Kernel: 4.1.6
  • VBox: 5.0.2
  • NM: 1.0.6

I started seeing this problem a few days ago, shortly after switching from Wicd to NM. Nothing else changed on my host, so vushakov's comment stood out to me. Looking through my system logs, I saw the following just before a suspend:

Sep 11 19:32:02 hostname NetworkManager[440]: <info>  (vboxnet0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]

NM never tries to bring the device back up, and I'm guessing VBox never looks at it unless its adding or removing a VM. If so, this would explain why restarting the VMs or detaching/attaching the network adapter seems to (temporarily) resolve the issue.

To resolve this, I added the following to /etc/NetworkManager/NetworkManager.conf:


Note - after updating the config, NM will change vboxnet0's state back to 'unmanaged' (just like it does when suspending), but it shouldn't touch it from there on out. Just use one of the above mentioned workarounds one last time, and you should be good to go.

comment:17 Changed 7 years ago by NathanCollins

I also have this issue on an Ubuntu 15.04 x86_64 host with VirtualBox 5.0.10 r104061 and a Fedora Core 22 guest.

The fix suggested by @zwolber worked for me. I had multiple vboxnet<n> interfaces, so I needed to use


(you need all the unmanaged devices on a single line) in /etc/NetworkManager/NetworkManager.conf. According to, more recent versions of NetworkManager might support the more robust


instead, to match all vboxnet<n> interfaces, but that did not work for me, so instead I had to list all my host-only interfaces as you see above.

I had to reboot to get the NetworkManager.conf changes go take effect; restarting NetworkManager did not work for me.

I was using a workaround before applying @zwolber's NetworkManager fix. This workaround will hopefully work for VirtualBox running on any OS, since it doesn't have anything to do with NetworkManager: if you reconfigure a host-only interface in the main VirtualBox GUI, VirtualBox will restart all of the host-only interfaces. You don't actually need to change any settings, just open the edit dialog and then close it immediately. The menu sequence in the VirtualBox GUI is

File -> Preferences -> Network -> Host-only Networks -> <wrench icon> -> OK -> OK

Sometimes NetworkManager was crashing for me on suspend; in Ubuntu you can restart it with

sudo systemctl restart network-manager.service

Restart NetworkManager before applying the "reconfigure host-only interface" workaround, if you are using NetworkManager and it crashed.

comment:18 Changed 7 years ago by vushakov

  • Status changed from new to closed
  • Resolution set to invalid

This is a problem with Network Manager.

The problem doesn't happen on Ubuntu 14.04 with network-manager When host-only interface is create, network manager ignores it.

The problem does manifest on Ubuntu 15.04 with network-manager There network manager tries to manage the interface, removes configured IP address on suspend and then doesn't know what to do on resume, so the interface remains not properly configured. I guess Ubuntu 14.10 from the original report developed the problem when NM package was upgraded to 0.9.10 (while 14.04 LTS stayed with 0.9.8).

Please, file a bug report with network manager. Skimming through Ubuntu changelog for it I see quite a bit of patches to ignore (or to not ignore) specific kinds of interfaces, so it seems it wouldn't be the first time NM tries to touch something it shouldn't have.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use