From owner-freebsd-emulation@FreeBSD.ORG Mon Jul 18 09:47:56 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 49127106564A for ; Mon, 18 Jul 2011 09:47:56 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id C247F8FC12 for ; Mon, 18 Jul 2011 09:47:55 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id p6I8UeUd000867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2011 10:30:40 +0200 Received: from portgus.lan ([147.83.40.234]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id p6I8UaMv002197 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 18 Jul 2011 10:30:40 +0200 Message-ID: <4E240B40.6030106@entel.upc.edu> Date: Mon, 18 Jul 2011 10:30:24 +0000 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: freebsd-emulation@freebsd.org References: <20110714095717.35581xj4rdju1pel@webmail.in-berlin.de> In-Reply-To: <20110714095717.35581xj4rdju1pel@webmail.in-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 (dash.upc.es [147.83.2.50]); Mon, 18 Jul 2011 10:30:41 +0200 (CEST) Cc: 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: Mon, 18 Jul 2011 09:47:56 -0000 Al 13/07/2011 23:57, En/na Peter Ross ha escrit: > Hi all, > > 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 also "replaced" the VirtualBox load with lookbusy occuping the 2GB > of memory the VirtualBox usually uses (to emulate the memory > footprint) but it still works. > > 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. Hi, 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.