From owner-freebsd-emulation@FreeBSD.ORG Thu Jul 21 14:13:46 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3142106566B for ; Thu, 21 Jul 2011 14:13:46 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 297548FC18 for ; Thu, 21 Jul 2011 14:13:45 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p6LEDanR025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2011 16:13:36 +0200 Received: from portgus.lan (129.Red-88-13-8.dynamicIP.rima-tde.net [88.13.8.129]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id p6LEDW4V002443 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Jul 2011 16:13:35 +0200 Message-ID: <4E28343A.8010903@entel.upc.edu> Date: Thu, 21 Jul 2011 16:14:18 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ca-ES; rv:1.9.2.18) Gecko/20110713 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Ross References: <20110714095717.35581xj4rdju1pel@webmail.in-berlin.de> <4E240B40.6030106@entel.upc.edu> <20110719164059.13124pmfuonx6tbv@webmail.in-berlin.de> In-Reply-To: <20110719164059.13124pmfuonx6tbv@webmail.in-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Thu, 21 Jul 2011 16:13:36 +0200 (CEST) Cc: freebsd-emulation@freebsd.org Subject: Re: Network problems while running VirtualBox X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:13:46 -0000 Al 19/07/2011 08:40, En/na Peter Ross ha escrit: > Quoting "Gustau Pérez" : > >> 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