Opened 12 years ago
Last modified 8 years ago
#11455 reopened defect
VirtualBox 4.2.6 , Guest freeze / hangs on network load
Reported by: | hexa | Owned by: | |
---|---|---|---|
Component: | network | Version: | VirtualBox 4.2.6 |
Keywords: | freeze network | Cc: | |
Guest type: | Linux | Host type: | other |
Description
Hi,
Using VirtualBox 4.2.6 on FreeBSD 8.3 host (64bit), and Debian 7.0 guest with kernel : 3.2.0-4-amd64.
When doing a large rsync of multi gigabyte file sizes, the Guest completely freezes ,
- Console is frozen (can't type)
- Network is down (ping host unknown)
It freezes for about 5 minutes, then the transfer aborts and the machine comes back.
No logs in VBox.log when the condition occurs. No logs in the Guest messages, kern.log or anything...
I tried all the Network Adapters they all fail at some point from 20 Gigs transferred to 200G.
This happens only with more then 1 CPU, with only one CPU it's stable. (Tested 1, 6 and 12 CPU on Guest) on Host : Xeon(R) CPU E5-2620
Other possibly useful information : I'm using dm-crypt on the Guest to encrypt incoming traffic, I will test without this to rule it out.
I also at one time using virt-io had this error log : virtio_net virtio0: output:id 138 is not a head!
But since it freezes using all the network adapters I assume it's not virtio related...
Any help is appreciated , I will perform any test requested ...
Thank you very much!
Attachments (4)
Change History (10)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Please reopen if still relevant with VBox 4.2.10. In that case, please provide the requested information.
comment:3 by , 8 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I ran into this or similar on a Linux VM I use for database replication, running VirtualBox 5.1.2 r108956 hosted on Windows Vista 32-bit SP2 (32GB RAM) with all updates. It has not recovered automatically.
The VM is running 64-bit Debian Jessie but with the backports kernel 4.6.3-1~bpo8+1 [13 July 2016]. It has only one vCPU assigned to it, although the host is a quad-core. The host's network driver is Broadcom Netlink (TM) Gigabit Ethernet version 17.2.0.2 [3 July 2015] on the motherboard's port.
Network communication suddenly stopped. ksoftirqd/0 is taking up 99.8% CPU. I cannot SSH into the client from the host, which is on the same network segment using bridged networking. It is connected via the virtio-net adapter. In ifconfig, eth0 still appears to be up with no errors.
On the guest I saw this message on the screen, and as the only post-boot entry in kern.log:
[57759.217382] virtio_net virtio0: input.0:id 12 is not a head!
From what I can gather this is from the function virtqueue_get_buf() and suggests that the per-descriptor state structure vring_desc_state has no content within the vring_virtqueue structure:
http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c?v=4.6#L633
http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c?v=4.6#L64
From a block device bug with a similar message:
https://bugs.launchpad.net/qemu/+bug/1359394/comments/1
"The guest kernel is looking for completed responses from the host. The host has indicated that the descriptor is the next completed response but the guest does not remember having submitted it."
Virtually reconnecting the cable, setting eth0 down/up, or deselecting and reselecting the VirtualBox NDIS6 Bridged Networking Driver in the host's Ethernet connection property pane did not fix the issue.
When I try to ping the gateway or host, I get "destination host unreachable" from the VM's IP. At this time, a wireshark capture on the host records ARP broadcasts requests from the Ethernet address of the virtual device ("who has [host IP]? tell [guest IP]"), suggesting that the route out was still clear.
Items in the host's event log occurring around this time which might be relevant:
The master browser has received a server announcement from the computer DOMINIC-PC that believes that it is the master browser for the domain on transport NetBT_Tcpip_{6241BC8F-C18A-4ED6-8D29-075760F. The master browser is stopping or an election is being forced.
The browser service has failed to retrieve the backup list too many times on transport \Device\NetBT_Tcpip_{6241BC8F-C18A-4ED6-8D29-075760F5BBE2}. The backup browser is stopping.
There was otherwise no obvious interruption in the host's networking. The host is on a cable modem's network and it shows nothing in its logs at that time. (It is also the endpoint of an IPv6 tunnel via SixXS, which is not used for this VM.)
In the end, I shut down the VM and restarted it, and the net came up correctly. Rare race condition?
by , 8 years ago
Attachment: | vboxcrash.JPG added |
---|
comment:4 by , 8 years ago
VirtualBox 5.1.4 Host OS: Windows 7 64bit Guest OS: Windows 7 64bit
I am also experiencing a similar issue on my virtual machine. I believe my issue is related to how much memory the virtual machine is allocated. The problem seems to be more prominent when the virtual machine has 4gb or more memory allocated to it. To create the issue all I have to do is copy a large file 2gb+, the large the better, from a shared network drive to a local shared drive or install a large program like Rockwell Studio v29 from a share network drive.
The crash documented in the vboxcrash.jpg was created by configuring the virtual machine with 6144gb of ram and coping a 17gb file from the z: drive to the h: drive shown in the image which resulted in a hard fault not just a lockup condition. Usually the virtual machine will just hang. When it hangs, I just power off and restart the virtual machine.
by , 8 years ago
Attachment: | Win7 Rockwell 64b-2016-08-17-14-29-19.log added |
---|
by , 8 years ago
Attachment: | Win7 Rockwell 64b.vbox added |
---|
comment:6 by , 8 years ago
To reproduce, all I have to do is to copy a large file from a shared network drive to the local virtual machine. Maybe its not related to the bug reported on this ticket, so if needed I can create a new bug. The problem still exists in 5.1.6, and does not seem to product any errors in the log files.
A VBox.log file of such a VM session is missing.