| The parameter is maxmem, not max-mem. That could be part of it. You can get a complete list of options from "xm create --help_config". When I found this out it was a huge help for me.
Also, it is important that you NOT specify mem=XXX on the kernel commandline (via the extra option). That would completely break this behavior. In other works, DO NOT specify anything like 'extra="mem=512"'.
One other thing I've done that may affect this is that I have limited my Dom0 memory at boot time. Perhaps if it has to borrow the memory from the Dom0 it stops short. I do this by passing the hypervisor the parameter dom0_mem=524288.
Here's the relevant section of my grub.conf:
root (hd0,0) kernel /boot/xen.gz dom0_mem=524288 com1=38400,8n1 nmi=dom0 module /boot/vmlinuz-2.6.16.38-xen0 root=/dev/uba1 netloop.nloopbacks=2 xencons=ttyS libusual.bias="ub"
And here's a lightly modified copy of the .xen file that I just tested:
# -*- mode: python; -*- kernel = '/boot/vmlinuz-2.6.16.38-xenU' memory = 2000 maxmem = 4096 name = 'XXX' vif = [ 'bridge=xenbr0' ] disk = [ 'phy:/dev/XXX0,sda1,w', 'phy:/dev/XXX1,sda2,w', 'phy:/dev/XXX2,sdb1,w!', ] root = '/dev/sda1 ro' vcpus = 2
Here's the output of a session. The dates are to help match up with the following screenshots:
hostname ~ # date ; xm info | grep free Mon May 21 20:10:21 PDT 2007 free_memory : 307 hostname ~ # xm mem-set XXX 2250 ; date Mon May 21 20:12:13 PDT 2007 hostname ~ # xm mem-set XXX 2000 ; date Mon May 21 20:12:43 PDT 2007 hostname ~ #
Here are screenshots of before adjusting the memory, after upping it, and after dropping it again:
Here is uname -a from the DomU:
Linux XXX 2.6.16.38-xenU #1 SMP Mon Mar 26 03:15:23 PDT 2007 x86_64 Dual Core AMD Opteron(tm) Processor 280 GNU/Linux
And xm info on the Dom0:
host : XXW release : 2.6.16.38-xen0 version : #4 SMP Mon Mar 26 22:56:07 PDT 2007 machine : x86_64 nr_cpus : 4 nr_nodes : 1 sockets_per_node : 2 cores_per_socket : 2 threads_per_core : 1 cpu_mhz : 2394 hw_caps : 178bfbff:e3d3fbff:00000000:00000010:00000001:00000000:00000003 total_memory : 16319 free_memory : 307 xen_major : 3 xen_minor : 0 xen_extra : .4-1 xen_caps : xen-3.0-x86_64 xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Thu Feb 15 11:34:58 2007 +0000 13139:3341afbb1953 cc_compiler : gcc version 4.1.1 (Gentoo 4.1.1-r1) cc_compile_by : root cc_compile_domain : XXW.com cc_compile_date : Mon Mar 26 02:54:15 PDT 2007 xend_config_format : 3
Hopefully some of this will help somebody...but it really does work. I swear!
On May 21, 2007, at 6:10 PM, suyash jape wrote: Hi everyone , I have also been facing the same problem for the past few days. The max-mem parameter in the domU config file is completely ignored.Even if we specifiy maxmem parameter in the config file at boot time , boot time allocated memory is taken as the max memory possible for the domain. Also i observed that the max vcpu parameter also behaves the same way. VCPU Observations: | 1]We can play around with only the no of VCPUs allotted at boot time or less. | Allocating max no of VCPUs dynamically is not reflected. i.e we can make max VCPUs of a domain from 5 to 10 dynamically BUT the 5 new ones are never used...they are always paused (possibly a bug in open source xen ?) Is there a fix around these problems? Thanks..... Suyash | Paul Archer <tigger@xxxxxx> wrote:
> I have been playing with memory= and maxmem=, but I'm not seeing what
> I think I should be seeing, namely that the memory available to a
> domU can be increased on the fly.
>
> Brad wrote :
>I wasn't able to achieve this using xen-3.1. The maximum amount of RAM appears to be dictated by the value that >the machine is booted with. Has anyone else managed to increase the amount of memory allocated to a domU to >more than what the domU was booted with and have the domU utilise this memory? I.e. show up with free -m on the >domU? _______________________________________________ Xen-users mailing list
-- Jayson Vantuyl Systems Architect
| 
Home