Al 19/07/2011 08:40, En/na Peter Ross ha escrit:
Quoting "Gustau Pérez" <gpe...@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
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
