Opened 15 years ago

Closed 9 years ago

Last modified 8 years ago

#5254 closed defect (fixed)

Host-only networking stops working

Reported by: henrik242 Owned by:
Component: network/hostif Version: VirtualBox 3.0.8
Keywords: Cc:
Guest type: Linux Host type: Mac OS X

Description (last modified by vasily Levchenko)

I use two network interfaces: one NAT and one Host-only adapter. The NAT interface works great all the time. The host-only interface, however, usually works as it should for a while after boot, then it becomes extremely slow and/or unresponsive. All adapters (Intel and PCnet) are affected.

A VM reboot might help, but sometimes it must be shut down completely.

This is a Mac OSX 10.6 host with a Debian testing guest (kernel 2.6.30-1).

A similar problem is discussed in the VirtualBox forum, and tickets #1256 and #4870 might be related.

Attachments (1)

VBox.log (38.7 KB ) - added by henrik242 15 years ago.

Download all attachments as: .zip

Change History (24)

by henrik242, 15 years ago

Attachment: VBox.log added

comment:1 by henrik242, 15 years ago

Also, I cannot find anything interesting in the host and guest log files (/var/log/*).

comment:2 by henrik242, 15 years ago

It happened again, appr. 15:01. There were messages in /var/log/messages on the guest a couple of minutes before that might be related:

Nov  3 11:15:51 hnrk-vbox kernel: [  274.472558] device-mapper: uevent: version 1.0.3
Nov  3 11:15:51 hnrk-vbox kernel: [  274.520621] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised:
Nov  3 11:15:51 hnrk-vbox kernel: [  279.700089] eth1: link up, 100Mbps, full-duplex
Nov  3 11:15:51 hnrk-vbox kernel: [  280.966722] eth0: link up, 100Mbps, full-duplex
Nov  3 11:16:26 hnrk-vbox lpd[3801]: restarted
Nov  3 13:25:44 hnrk-vbox kernel: [ 8090.060998] eth1: link down
Nov  3 13:25:44 hnrk-vbox kernel: [ 8091.003071] eth0: link down
Nov  3 13:25:49 hnrk-vbox kernel: [ 8096.002226] eth1: link up, 100Mbps, full-duplex
Nov  3 13:25:50 hnrk-vbox kernel: [ 8097.003697] eth0: link up, 100Mbps, full-duplex
Nov  3 13:39:57 hnrk-vbox kernel: [ 8943.555340] process `sysctl' is using deprecated sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use net.ipv6.neigh.default.retrans_time_ms instead.
Nov  3 14:44:15 hnrk-vbox kernel: [12801.528512] hrtimer: interrupt too slow, forcing clock min delta to 20576772 ns

Anyway, I started pinged the Host-only networking gateway (ping from the guest after the network stopped working. The packages wouldn't go through the first 10-20 seconds, but then suddenly the network was OK again. At least I have a workaround.

Here's the network configuration, by the way:

eth0      Link encap:Ethernet  HWaddr 08:00:27:eb:81:dc  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:feeb:81dc/64 Scope:Link
          RX packets:486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:511179 (499.1 KiB)  TX bytes:46503 (45.4 KiB)
          Interrupt:19 Base address:0xd020 

eth1      Link encap:Ethernet  HWaddr 08:00:27:6a:f2:2e  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:fe6a:f22e/64 Scope:Link
          RX packets:53544 errors:321 dropped:0 overruns:0 frame:0
          TX packets:7647 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:73582593 (70.1 MiB)  TX bytes:1941106 (1.8 MiB)
          Interrupt:16 Base address:0xd060 

comment:3 by Licho, 15 years ago

I'm having completely same problem since 2.0 series of virtual box. With different host machines, different guest machine and different network setups (using tun vs using vbox own interface in 3.0). Its always same.

Replicated this in 3.0.10. - ubuntu host, w2k3 guest.

Under heavy load it just stops transmitting data between host and guest, sometimes virtual adapter is completely frozen and you cannot even view its details in guest OS.

Thanks for your tip about pinging gateway, after VRDP to guest machine and pinging gateway adapter started up again!

comment:4 by Licho, 15 years ago

Update: tested it more times, ping gateway trick not always work. Eventually you have to reboot guest machine :(

This bug drives me crazy for ages..

Several reboots/day to keep it online..

comment:5 by Licho, 15 years ago

The issue is strongly related to load. Normal low traffic wont break it.

But game lobby server makes it break every few hours. (100+ TCP connections each of them uploads some 300kb on init + high flux/random disconnects of players).

comment:6 by Licho, 15 years ago

I did several test on my VM suffering from same bug (host ubuntu, guest w2k3).

Opening VRDP often fixes the bug.. not the "ping gateway", but just the act of opening VRDP.


comment:7 by henrik242, 15 years ago

I just got this problem again, this time with a CentOS 5.2 guest on a MacOSX 10.6.2 host with VirtualBox 3.1. I can still wake the connection by pinging the host-only gateway from within the guest.

comment:8 by Licho, 15 years ago

Are you sure its pinging and not just connecting to VRDP? In my cases connecting to VRDP fixed it, not the ping gate from guest.

comment:9 by henrik242, 15 years ago

I don't use VRDP at all...

comment:10 by Licho, 15 years ago

I thought that virtio-net solves this problem but it only reduces frequency.. (to about 1x per day on my machine - from 4x per day).

comment:11 by henrik242, 15 years ago

I just noticed that the gateway ping behaves weirdly. It seems to have a 30-second cycle three times before it finally settles to work again:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=28216 ms
64 bytes from icmp_seq=2 ttl=64 time=27207 ms
64 bytes from icmp_seq=3 ttl=64 time=26200 ms
64 bytes from icmp_seq=4 ttl=64 time=25192 ms
64 bytes from icmp_seq=5 ttl=64 time=24183 ms
64 bytes from icmp_seq=6 ttl=64 time=23174 ms
64 bytes from icmp_seq=7 ttl=64 time=22174 ms
64 bytes from icmp_seq=8 ttl=64 time=21174 ms
64 bytes from icmp_seq=9 ttl=64 time=20174 ms
64 bytes from icmp_seq=10 ttl=64 time=19173 ms
64 bytes from icmp_seq=11 ttl=64 time=18174 ms
64 bytes from icmp_seq=12 ttl=64 time=17174 ms
64 bytes from icmp_seq=13 ttl=64 time=16174 ms
64 bytes from icmp_seq=14 ttl=64 time=15174 ms
64 bytes from icmp_seq=15 ttl=64 time=14174 ms
64 bytes from icmp_seq=16 ttl=64 time=13174 ms
64 bytes from icmp_seq=17 ttl=64 time=12173 ms
64 bytes from icmp_seq=18 ttl=64 time=11174 ms
64 bytes from icmp_seq=19 ttl=64 time=10174 ms
64 bytes from icmp_seq=20 ttl=64 time=9174 ms
64 bytes from icmp_seq=21 ttl=64 time=8173 ms
64 bytes from icmp_seq=22 ttl=64 time=7174 ms
64 bytes from icmp_seq=23 ttl=64 time=6174 ms
64 bytes from icmp_seq=24 ttl=64 time=5174 ms
64 bytes from icmp_seq=25 ttl=64 time=4174 ms
64 bytes from icmp_seq=26 ttl=64 time=3174 ms
64 bytes from icmp_seq=27 ttl=64 time=2174 ms
64 bytes from icmp_seq=28 ttl=64 time=1174 ms
64 bytes from icmp_seq=29 ttl=64 time=172 ms
64 bytes from icmp_seq=30 ttl=64 time=30034 ms
64 bytes from icmp_seq=31 ttl=64 time=29035 ms
64 bytes from icmp_seq=32 ttl=64 time=28034 ms
64 bytes from icmp_seq=33 ttl=64 time=27035 ms
64 bytes from icmp_seq=34 ttl=64 time=26034 ms
64 bytes from icmp_seq=35 ttl=64 time=25035 ms
64 bytes from icmp_seq=36 ttl=64 time=24034 ms
64 bytes from icmp_seq=37 ttl=64 time=23034 ms
64 bytes from icmp_seq=38 ttl=64 time=22034 ms
64 bytes from icmp_seq=39 ttl=64 time=21033 ms
64 bytes from icmp_seq=40 ttl=64 time=20023 ms
64 bytes from icmp_seq=41 ttl=64 time=19022 ms
64 bytes from icmp_seq=42 ttl=64 time=18023 ms
64 bytes from icmp_seq=43 ttl=64 time=17022 ms
64 bytes from icmp_seq=44 ttl=64 time=16023 ms
64 bytes from icmp_seq=45 ttl=64 time=15021 ms
64 bytes from icmp_seq=46 ttl=64 time=14022 ms
64 bytes from icmp_seq=47 ttl=64 time=13023 ms
64 bytes from icmp_seq=48 ttl=64 time=12022 ms
64 bytes from icmp_seq=49 ttl=64 time=11022 ms
64 bytes from icmp_seq=50 ttl=64 time=10020 ms
64 bytes from icmp_seq=51 ttl=64 time=9018 ms
64 bytes from icmp_seq=52 ttl=64 time=8018 ms
64 bytes from icmp_seq=53 ttl=64 time=7019 ms
64 bytes from icmp_seq=54 ttl=64 time=6018 ms
64 bytes from icmp_seq=55 ttl=64 time=5008 ms
64 bytes from icmp_seq=56 ttl=64 time=4000 ms
64 bytes from icmp_seq=57 ttl=64 time=2991 ms
64 bytes from icmp_seq=58 ttl=64 time=1991 ms
64 bytes from icmp_seq=59 ttl=64 time=990 ms
64 bytes from icmp_seq=60 ttl=64 time=30851 ms
64 bytes from icmp_seq=61 ttl=64 time=29850 ms
64 bytes from icmp_seq=62 ttl=64 time=28851 ms
64 bytes from icmp_seq=63 ttl=64 time=27850 ms
64 bytes from icmp_seq=64 ttl=64 time=26850 ms
64 bytes from icmp_seq=65 ttl=64 time=25850 ms
64 bytes from icmp_seq=66 ttl=64 time=24851 ms
64 bytes from icmp_seq=67 ttl=64 time=23850 ms
64 bytes from icmp_seq=68 ttl=64 time=22850 ms
64 bytes from icmp_seq=69 ttl=64 time=21850 ms
64 bytes from icmp_seq=70 ttl=64 time=20851 ms
64 bytes from icmp_seq=71 ttl=64 time=19851 ms
64 bytes from icmp_seq=72 ttl=64 time=18850 ms
64 bytes from icmp_seq=73 ttl=64 time=17851 ms
64 bytes from icmp_seq=74 ttl=64 time=16850 ms
64 bytes from icmp_seq=75 ttl=64 time=15851 ms
64 bytes from icmp_seq=76 ttl=64 time=14851 ms
64 bytes from icmp_seq=77 ttl=64 time=13851 ms
64 bytes from icmp_seq=78 ttl=64 time=12849 ms
64 bytes from icmp_seq=79 ttl=64 time=11840 ms
64 bytes from icmp_seq=80 ttl=64 time=10832 ms
64 bytes from icmp_seq=81 ttl=64 time=9823 ms
64 bytes from icmp_seq=82 ttl=64 time=8823 ms
64 bytes from icmp_seq=83 ttl=64 time=7823 ms
64 bytes from icmp_seq=84 ttl=64 time=6822 ms
64 bytes from icmp_seq=85 ttl=64 time=5823 ms
64 bytes from icmp_seq=86 ttl=64 time=4822 ms
64 bytes from icmp_seq=87 ttl=64 time=3823 ms
64 bytes from icmp_seq=88 ttl=64 time=2823 ms
64 bytes from icmp_seq=89 ttl=64 time=1823 ms
64 bytes from icmp_seq=90 ttl=64 time=823 ms
From icmp_seq=117 Destination Host Unreachable
From icmp_seq=118 Destination Host Unreachable
From icmp_seq=119 Destination Host Unreachable
64 bytes from icmp_seq=91 ttl=64 time=30688 ms
64 bytes from icmp_seq=92 ttl=64 time=29688 ms
64 bytes from icmp_seq=93 ttl=64 time=28688 ms
64 bytes from icmp_seq=94 ttl=64 time=27688 ms
64 bytes from icmp_seq=95 ttl=64 time=26688 ms
64 bytes from icmp_seq=96 ttl=64 time=25688 ms
64 bytes from icmp_seq=97 ttl=64 time=24688 ms
64 bytes from icmp_seq=98 ttl=64 time=23688 ms
64 bytes from icmp_seq=99 ttl=64 time=22688 ms
64 bytes from icmp_seq=100 ttl=64 time=21688 ms
64 bytes from icmp_seq=101 ttl=64 time=20688 ms
64 bytes from icmp_seq=102 ttl=64 time=19689 ms
64 bytes from icmp_seq=103 ttl=64 time=18687 ms
64 bytes from icmp_seq=104 ttl=64 time=17688 ms
64 bytes from icmp_seq=105 ttl=64 time=16686 ms
64 bytes from icmp_seq=106 ttl=64 time=15677 ms
64 bytes from icmp_seq=107 ttl=64 time=14670 ms
64 bytes from icmp_seq=108 ttl=64 time=13661 ms
64 bytes from icmp_seq=109 ttl=64 time=12653 ms
64 bytes from icmp_seq=110 ttl=64 time=11641 ms
64 bytes from icmp_seq=111 ttl=64 time=10634 ms
64 bytes from icmp_seq=112 ttl=64 time=9625 ms
64 bytes from icmp_seq=113 ttl=64 time=8618 ms
64 bytes from icmp_seq=114 ttl=64 time=7610 ms
64 bytes from icmp_seq=115 ttl=64 time=6601 ms
64 bytes from icmp_seq=116 ttl=64 time=5594 ms
64 bytes from icmp_seq=120 ttl=64 time=1570 ms
64 bytes from icmp_seq=121 ttl=64 time=562 ms
64 bytes from icmp_seq=122 ttl=64 time=0.684 ms
64 bytes from icmp_seq=123 ttl=64 time=0.345 ms
64 bytes from icmp_seq=124 ttl=64 time=0.396 ms
64 bytes from icmp_seq=125 ttl=64 time=0.542 ms
64 bytes from icmp_seq=126 ttl=64 time=0.482 ms
64 bytes from icmp_seq=127 ttl=64 time=0.559 ms
64 bytes from icmp_seq=128 ttl=64 time=0.613 ms
64 bytes from icmp_seq=129 ttl=64 time=0.550 ms
64 bytes from icmp_seq=130 ttl=64 time=0.576 ms

comment:12 by henrik242, 15 years ago

I just realized that the forum topic link in the issue description somehow lacks a question sign. Here it is again:

comment:13 by Andreas Böckler, 14 years ago

#5871 might be related to it.

comment:14 by jwilliams108, 14 years ago

I am experiencing a similar problem, but it doesn't seem to correlate to load. I also can't solve it by pinging or opening a VRDP connection, but instead need to save the machine state and start it again. Strangely, this problem only shows up on 10.6.3 Server, the same VM runs find with VirtualBox 3.1.6 on 10.6.3 non-server.

comment:15 by Miro Dietiker, 14 years ago

This ist still present in VirtualBox 3.2.12. (Using Mac OS X 10.5.8) I also can't find a load relation.

This bug really makes the internal network useless... What a pity for offline development between host / guest...

comment:16 by Frank Mehnert, 13 years ago

Component: networknetwork/hostif

comment:17 by Frank Mehnert, 13 years ago

Resolution: fixed
Status: newclosed

There were relevant fixes in VBox 4.0.6. Please reopen if still relevant.

comment:18 by vagrant77, 12 years ago

I'm not sure this is fixed, I have a VM I've distributed to a few people this week and they're reporting the network freezing up. Things will start fine but after some time, shells through the forwarded port will freeze and HTTP connections to the host only network will hang. I think there's still a bug here. The configuration for all of them is

Mac OS 10.7 host

Ubuntu 10.10 guest with eth0 a NAT and eth1 hostonly

Vbox 4.1.12

Last edited 12 years ago by vagrant77 (previous) (diff)

in reply to:  18 comment:19 by vasily Levchenko, 12 years ago

Description: modified (diff)

Replying to vagrant77:

Vbox 4.1.12

Please try with 4.1.16 and if the issue still persists please attach log file.

comment:20 by ayotzinapa, 9 years ago

Resolution: fixed
Status: closedreopened

I'm having the same issue with VirtualBox 5.0.2. I followed the instructions in [this tutoria] to assign a static IP to my guest. It was working for a while, then it suddenly stopped and no amount of restarting either the host or guest will bring it back.

This is occurring on a Mac OS X 10.10.5 host with an Ubuntu 14.04.3 guest.

I was able to resolve the issue by choosing a different IP for the nat network - changing the host network config (Preferences > Network > Host Only Networks > vboxnet0) from to and the guest's IP from to I was able to reconnect.

It turns out the WIFI access point that I was connected to was using the subnet.

Last edited 9 years ago by ayotzinapa (previous) (diff)

in reply to:  20 comment:21 by Valery Ushakov, 9 years ago

Resolution: fixed
Status: reopenedclosed

Replying to ayotzinapa:

I was able to resolve the issue by choosing a different IP for the nat network - changing the host network config (Preferences > Network > Host Only Networks > vboxnet0) from to and the guest's IP from to I was able to reconnect.

It turns out the WIFI access point that I was connected to was using the subnet.

Configuration problem, not a bug.

comment:22 by AAAAdrianLi, 8 years ago

I have the same issue. I am using vagrant 1.8.1 and VirtualBox 5.0.14.

I created a VM using "hashicorp/precise64" vagrant box and what I was trying to do is to connect to a large number of VPN endpoints one by one using openvpn, and for each VPN, run various tests (like http, dns, traceroute, etc.) for a list of URLs concurrently (500 URLs).

NAT network would stop working after finishing some endpoints. Tried everything but only reboot could bring up the network.

I have also tried using ubuntu/trusty64 box and different NIC, all have the same problem.

in reply to:  22 comment:23 by Valery Ushakov, 8 years ago

Replying to AAAAdrianLi:

I have the same issue.

This is not same issue as this bug is about host-only network and your problem is with the NAT Network. Please, file a separate bug and provide as much detail as possible. When the NAT network is stuck, try to get a core dump of the VBoxNetNAT process.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use