Scenario: - amd64 machine acting as a VirtualBox host; virtualbox-ose-4.3.20_2 is installed - while a VirtualBox client is running, the command dd if=/dev/ada0s1 bs=1m is run, issued via rsh from a remote computer (the purpose is to save a copy of partition ada0s1 to the remote computer) Result: - after some time, dd exits with an error: dd: stdout: Cannot allocate memory 33006+0 records in 33005+0 records out 4326031360 bytes transferred in 69.111410 secs (62595038 bytes/sec) Expected result: - dd completes until the entire partition ada0s1 has been read Notes: - This did not happen when the machine was running FreeBSD 9.2 (with virtualbox-ose-4.3.20 installed). - After shutting down all VirtualBox clients on the machine, the same dd command runs to completion (no reboot required).
In 10.2, the same behavior still persists. The symptom is that when VirtualBox is running, a dd from a disk partition does not run to completion, but aborts with the error messsage "dd: cannot allocate memory". So, the scenario is: - I want to low-level copy a disk partition using dd - At the same time, a VirtualBox instance is running Expected result: - dd runs to completion - VirtualBox does not affect dd Actual result: - As long as VirtualBox is running, dd aborts after a random number of blocks read Workaround: - Do not start VirtualBox while dd is running Is this some interaction in how the kernel allocates buffers? It surely isn't really a userspace problem? -- Martin
I now had this error also while zfs sending a replication stream: internal error: Cannot allocate memory This aborted the 'zfs send' operation This was on a different machine. Something is very fishy with kernel memory and VirtualBox. -- MBi
I have tried to refine the scenario where the problem appears, and the results are as follows. - I run a 3 GB VB client on an 8 GB machine - On this machine I start a dd with a blocksize of 128k to copy a 250G disk slice to standard output (the purpose being to make an image backup of the Windows partition). The difference is how I start dd: - Just running dd if=/dev/ada0s2 of=/dev/null bs=128 works. - Running dd if=/dev/ada0s2 bs=128k | cat > /dev/null works. - *On another machine*, running rsh -n <the machine running the VB client> "dd if=/dev/ada0s2 bs=128k" > /dev/null produces "dd: stdout: Cannot allocate memory" quite soon (but after a non-deterministic number of blocks have been transferred). If I do this using ssh, the behavior is slightly different but still erroneous: ssh -n <the machine running the VB client> "dd if=/dev/ada0s2 bs=128k" > /dev/null produces "Connection to <the machine running the VB client> closed by remote host." without a message from dd. I could not note any anomalies in memory usage as monitored by "top" and "systat -vm 1". If, after the tests above, I shut down the VB client while keeping everything else the same, issuing the rsh command runs to completion correctly. Note that in that other scenario where I was using "zfs send", "zfs send" was also invoked via "rsh -n". So it seems that sending data via rsh while a VB client is running leads to the problem. -- Martin
what is your net.graph.maxdata set to? net.graph.maxdata=8192 I set this a while ago for similar issues.
It is 512. I tried to increase it right away, but alas it is a loader tunable only, and I cannot reboot right now. May I ask why you think this is related, and what problem you experienced? -- Martin
I was seeing weird messages about not being able to allocate memory on SSH sessions and with zfs(1) sends. Someone back a while suggested it, and the problems went away when I added this tunable. Apparently the VBox network driver(s) use netgraph.
I believe this can be closed now, as the OP posted that the tunable fixed it.
Indeed it seems to be working with increasing net.graph.maxdata. I am closing this. Thank you for the help. -- Martin