Network problems while running VirtualBox
Gustau Pérez
gperez at entel.upc.edu
Thu Jul 21 14:13:46 UTC 2011
Al 19/07/2011 08:40, En/na Peter Ross ha escrit:
> Quoting "Gustau Pérez" <gperez at entel.upc.edu>:
>
>> Al 13/07/2011 23:57, En/na Peter Ross ha escrit:
>>> I have a problem with the network while running VirtualBox.
>>>
>>> As soon as I _run_ a VirtualBox I am not able to copy large files
>>> (e.g. virtual disks or ZFS snapshots) using ssh/scp to another machine.
>>>
>>> The ssh crashes with "Write failed: Cannot allocate memory"
>>>
>>> thrown by a write(2) in /usr/src/crypto/openssh/roaming_common.c (in
>>> function roaming_write). It returns the ENOMEM (an error it should
>>> never return, according to the mainpage;-)
>>>
>>> It is immediately working when I stop the VirtualBox, even if the
>>> VirtualBox kernel modules are still loaded.
>>> ..
>>> I experienced the problem with VirtualBox 3.2 first but the upgrade
>>> to VirtualBox 4.0.8 and the base system recently did not help.
>>
>> I have AMD64/STABLE+virtualbox[4.0.10|4.1Beta] on a Dell R710 with
>> two scenarios:
>>
>> 1.- Sending large files from the host to the guest with scp.
>> 1,. rsync+ssh in the host machine (with virtualbox) sending
>> large files to a remote machine.
>>
>> in fact both scenarios are the same, the host machine sending
>> large chunks of data. Both fail as it fails to everyone in the list.
>>
>> Ok. So far so good. To track down the problem I tested may changes
>> of configuration with STABLE (if you want the details please let me
>> know and I'll send them to the list). None did the trick. I even
>> tried communications between the host and the guest with vboxnet. scp
>> failed with the "no memory allocation" problem.
>>
>> Now I tried AMD64/CURRENT+virtualbox 4.0.10 on a laptop. I tested
>> an scenario like the one described in number 1. It worked just fine.
>> In fact I tried something like this in the host machine just to be sure:
>>
>> # for i in {1..10}
>> do
>> cat "large_file.data" | ssh -l root
>> 192.168.56.101 "cat -> /dev/null"
>> done
>>
>> Where 192.168.56.101 is the guest machine (I'm using vboxnet).
>> This large file is 8 Gb file. So it gave me an 80Gb transfer. It
>> worked fine. This scenario would have failed with STABLE.
>>
>> So I guess it has something to do with the combo
>> STABLE+Virtualbox. There must a change in CURRENT that doesn't
>> trigger the problem. I think it would be appropriate if anyone else
>> could also try with CURRENT.
>>
>> As an addition I remember all of this worked with 8.1 and an early
>> version of virtualbox 3.2 series . But I can't say which revision of
>> 8.1 I had when I was using that kind of scenarios.
>
> I experienced the problem first on VirtualBox 3.2 and
> FreeBSD-8.2-PRERELEASE. Marlon already in September 2010.
>
> The laptop isn't the ultimate test as long as you haven't the same
> data going through the netgraph subsystem.
>
> Can you try to set net.graph.maxdata as well (see my other e-mail).
> Does it solve your problem too?
>
> Thanks for your help
> Peter
>
>
Hi,
My test system is a FreeBSD8.2/AMD64 Stable r222508 in a DELL R710
with 24GB of RAM with a dual Intel PRO/1000 and 4 Broadcom Extreme II
BCM5709. The broadcoms are lagged together giving bridged connectivity
to the virtual machines to the real world. I'm also using a vboxnet
network to bring a dedicated network between the virtual machines and
the host system.
I've been testing with net.graph.maxdata="65536". I've been able to
do large transfers (like 25GB with rsync and scp) from the host to a
remote system. Also I've been able to do transfers of about 10GB from
the host system to one guest system and they went well. Without setting
net.graph.maxdata I usually triggered the problem with transfers of
about 1 or 2GB. As you can see, I saw no problems with the real network
nor with the virtual network.
I did not report earlier because I wanted to be sure enough. Now I
would say that maxdata removed the problem for me.
What I do not get is why it works with CURRENT having
net.graph.maxdata="256". Anyway I think it would be nice to know why
setting the maxdata solves the problem because it would allow the
virtualbox team to add a note in pkg-message with the appropriate
explanation or even proposing a PR to STABLE to fix the issue.
Gustau
More information about the freebsd-emulation
mailing list