[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
Testing has demonstrated a fairly simple way to reproduce the problem using Xen 4.0.1. On a large memory server (mine is 16 Gigs), set up the following scenario. 1. Boot the server with dom0_mem=2048M thereby limiting the host to 2 Gig. Also set (enable-dom0-ballooning no) in xend-config.sxp to disable ballooning. 2. Create two windows guests. My test case included the following. Guest 1: win2k3 with 512 Meg and sufficient disk space to hold a 10 Gig file. Create a shared folder which can be mapped by the win2k8r2 guest. Create or copy a 10 Gig file to this shared folder. Guest 2: win2k8r2 with 4 Gig and sufficient disk space to hold a 10 Gig file. Map the shared folder on the win2k3 guest. 3. Using robocopy on the win2k8r2 guest, copy the 10 Gig file to a local folder. With the above scenario, the copy gets to about 23.7% when the win2k8r2 guest is terminated with the mmap error above. Observations: qemu-dm steadily mmap's all the amount of memory which the guest has been given while doing the robocopy. So if the guest was given 2 Gig, it eventually mmap's 2 Gig while the copying continues. When this 2 Gig limit is reached, it continues to copy without problem until all the file is copied. This has been observed with the win2k8r2 guest using 2, 2.5 and 3 Gig. However, at 3.25 Gig, the mmap call eventually fails for the specific case where the dom0 memory is set to 2 Gig and ballooning is off. The size of the file being copied in all tests is 10 Gig. The bug is that qemu-dm seems to make the assumption that it can mmap from dom0 all the memory with which the guest has been defined instead of the memory that is actually available on the host. - Charles _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |