Hello, After I limited max memory usage in one domain, how could I reset mem-max to no-limit? Besides, I used "xm create -F xxxx.xm" to create a domain successfully. But when I shut it down, this domain disappear from "xm list". Why that happened? Thanks. Vincent
On Thu, Mar 5, 2009 at 2:21 PM, Yi-Long Ding (Vincent) <Vincent.Ding@sun.com> wrote:> Hello, > > After I limited max memory usage in one domain, how could I reset > mem-max to no-limit?AFAIK you can''t change it online. Changes with "virsh setmaxmem", or in the config file, takes effect on the next server start. And even then it''s not unlimited. You can set it to amount of total memory in your system.> > Besides, I used "xm create -F xxxx.xm" to create a domain successfully. > But when I shut it down, this domain disappear from "xm list". Why that > happened? >Try "xm new -F xxxx.xm" and "xm start xxxx" Regards, Fajar
Hi, AFAIK as I know you can only shrink the memory for DomU and not add additional memory to it. So you should start the DomU with the maximum memory you''ll ever need and then shrink the memory to the currently needed value. Later than you can resize it again until the memory amount while starting the DomU is reached again regards Bernd Yi-Long Ding (Vincent) wrote:> Hello, > > After I limited max memory usage in one domain, how could I reset > mem-max to no-limit? > > Besides, I used "xm create -F xxxx.xm" to create a domain successfully. > But when I shut it down, this domain disappear from "xm list". Why that > happened? > > Thanks. > > Vincent > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org > >-- Bernd Schemmer, Frankfurt am Main, Germany http://home.arcor.de/bnsmb/index.html M s temprano que tarde el mundo cambiar . Fidel Castro
On 03/05/09 02:52, Bernd Schemmer wrote:> Hi, > > AFAIK as I know you can only shrink the memory for DomU and not add > additional memory to it. >Not true. You can change the maximum memory with "xm mem-max". no-limit would be setting it to the max ram on the machine. You can''t reduce the max memory below the original maxmem specified in the domain configuration file. If maxmem isn''t specified, it defaults to memory. Here''s part of my typical config file: # Initial memory allocation (in megabytes) for the new domain. memory = 256 maxmem = 1024 Given this I can "xm mem-set" up to 1024 while the domain is running. I can then do "xm mem-max 2048" to up the limit and then "xm mem-set" up to 2048. I can "xm mem-max" anywhere between 1024 and up, but not lower. Mick
On Thu, Mar 5, 2009 at 9:03 AM, Mick Jordan <Mick.Jordan@sun.com> wrote:> On 03/05/09 02:52, Bernd Schemmer wrote: >> >> Hi, >> >> AFAIK as I know you can only shrink the memory for DomU and not add >> additional memory to it. >> > Not true. You can change the maximum memory with "xm mem-max". no-limit > would be setting it to the max ram on the machine. You can''t reduce the max > memory below the original maxmem specified in the domain configuration file. > If maxmem isn''t specified, it defaults to memory. Here''s part of my typical > config file: > > # Initial memory allocation (in megabytes) for the new domain. > memory = 256 > maxmem = 1024 > > Given this I can "xm mem-set" up to 1024 while the domain is running. I can > then do "xm mem-max 2048" to up the limit and then "xm mem-set" up to 2048. > I can "xm mem-max" anywhere between 1024 and up, but not lower.Note that the guest OS needs to support raising the memory above the original allocation. Solaris currently does not support this. Xen will allocate memory to the domain, but the memory will not be used. The last time I looked (which was a long time ago), Linux did not support this either. -Ryan> > Mick > > > > > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
On 03/05/09 09:12, Ryan Scott wrote:> > Note that the guest OS needs to support raising the memory above the > original allocation. Solaris currently does not support this. Xen > will allocate memory to the domain, but the memory will not be used. > > The last time I looked (which was a long time ago), Linux did not > support this either. >I think you mean "needs to support raising the max memory above the original allocation". Certainly Solars/Linux support raising "memory" above the original allocation via the balloon drivers. Actually I was quite surprised that it was even possible to raise max-memory. It almost seems like a contradiction in terms. It essentially makes max-memory a pretty useless concept for a guest. E.g., you might imagine you could permanently size data structures dealing with memory based on this value, but no. Mick
On Thu, Mar 05, 2009 at 12:18:59PM -0800, Mick Jordan wrote:> >Note that the guest OS needs to support raising the memory above the > >original allocation. Solaris currently does not support this. Xen > >will allocate memory to the domain, but the memory will not be used. > > > >The last time I looked (which was a long time ago), Linux did not > >support this either. > > > I think you mean "needs to support raising the max memory above the > original allocation". Certainly Solars/Linux support raising "memory" > above the original allocation via the balloon drivers. > > Actually I was quite surprised that it was even possible to raise > max-memory. It almost seems like a contradiction in terms. It > essentially makes max-memory a pretty useless concept for a guest. E.g., > you might imagine you could permanently size data structures dealing > with memory based on this value, but no.mem-set affects the running guest (balloon driver), but mem-max does not (it will only apply after a reboot). All kernels use the max-mem value for precisely what you suggest, and they won''t see any changes in the value until they''re rebooted (that is, no memory hotplug, only balloon). regards john
On 03/05/09 12:27, John Levon wrote:> mem-set affects the running guest (balloon driver), but mem-max does not > (it will only apply after a reboot). All kernels use the max-mem value > for precisely what you suggest, and they won''t see any changes in the > value until they''re rebooted (that is, no memory hotplug, only balloon). >Ok, so maybe I am being foolish in even trying to support a dynamic change to mem-max (memory hotplug) in my kernel. I notice there is no equivalent of "target" (mem-set) to watch for a change, so I actually check mem-max whenever I get a mem-set event. I don''t understand how kernels see the change after a reboot, unless this is related to managed domains and the xm mem-max setting is being squirreled away for the next time the guest runs. Mick
On Thu, Mar 05, 2009 at 04:42:34PM -0800, Mick Jordan wrote:> I don''t understand how kernels see the change after a reboot, unless > this is related to managed domains and the xm mem-max setting is being > squirreled away for the next time the guest runs.Exactly. regards john
On 03/06/09 09:26, John Levon wrote:> On Thu, Mar 05, 2009 at 04:42:34PM -0800, Mick Jordan wrote: > > >> I don''t understand how kernels see the change after a reboot, unless >> this is related to managed domains and the xm mem-max setting is being >> squirreled away for the next time the guest runs. >> > > Exactly. >I discovered that the acceptable mem-max values seems to be completely arbitrary in the increasing direction. For example it is possible to set past the end of machine memory with no complaint and then do a mem-set of that value, again with no complaint from Xen. Mick
On Fri, Mar 06, 2009 at 09:39:38AM -0800, Mick Jordan wrote:> I discovered that the acceptable mem-max values seems to be completely > arbitrary in the increasing direction. For example it is possible to set > past the end of machine memory with no complaint and then do a mem-set > of that value, again with no complaint from Xen.The verification happens when you try to start the domain. It really can''t possibly know otherwise, since the ability to allocate whatever memory you request is dependent upon free memory. You could argue that it should never allow more than the physical memory on the machine, but this is of limited utility. regards john