VirtualBox

Ticket #5254 (closed defect: fixed)

Opened 5 years ago

Last modified 23 months ago

Host-only networking stops working

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

Description (last modified by Hachiman) (diff)

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

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

Change History

Changed 5 years ago by henrik242

comment:1 Changed 5 years ago by henrik242

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

comment:2 Changed 4 years ago by henrik242

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: dm-devel@redhat.com
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 192.168.56.1) 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:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feeb:81dc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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:192.168.56.3  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe6a:f22e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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 Changed 4 years ago by Licho

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 Changed 4 years ago by Licho

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 Changed 4 years ago by Licho

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 Changed 4 years ago by Licho

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.

Strange..

comment:7 Changed 4 years ago by henrik242

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 Changed 4 years ago by Licho

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 Changed 4 years ago by henrik242

I don't use VRDP at all...

comment:10 Changed 4 years ago by Licho

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 Changed 4 years ago by henrik242

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

comment:12 Changed 4 years ago by henrik242

I just realized that the forum topic link in the issue description somehow lacks a question sign. Here it is again:  http://forum.virtualbox.org/viewtopic.php?f=6&t=19457&start=30&sid=d2fa7b3d50bc97a49f596a0df94743ce

comment:13 Changed 4 years ago by boecko

#5871 might be related to it.

comment:14 Changed 4 years ago by jwilliams108

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 Changed 3 years ago by Miro Dietiker

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 Changed 3 years ago by frank

  • Component changed from network to network/hostif

comment:17 Changed 3 years ago by frank

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

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

comment:18 follow-up: ↓ 19 Changed 23 months ago by vagrant77

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 23 months ago by vagrant77 (previous) (diff)

comment:19 in reply to: ↑ 18 Changed 23 months ago by Hachiman

  • 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use