I should say that it randomly fails with the larger memory limits (as the process grows it eventually causes problems), if dom0 has a small amount of memory like devcloud does. Shane said in a previous message that 4.1 works. So I'm not entirely sure, but one thing to check at least would be that the java process isn't asking for as much or more memory than dom0 has.
On Sun, May 26, 2013 at 1:01 AM, Marcus Sorensen <shadow...@gmail.com> wrote: > It's because the tomcat memory limits were raised in 4.1 to deal with > the initial memory footprint increase back in Feb. It hasn't run in > stock devcloud since. I increased the dom0 memory on mine to make it > work. I think there was subsequent work in April or so to get the > memory back down, so we may be able to decrease the xmx=2G or whatever > it is back down. > > XCP may not have ever increased their run limit. > > On Sun, May 26, 2013 at 12:43 AM, Prasanna Santhanam (JIRA) > <j...@apache.org> wrote: >> >> [ >> https://issues.apache.org/jira/browse/CLOUDSTACK-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667216#comment-13667216 >> ] >> >> Prasanna Santhanam commented on CLOUDSTACK-2683: >> ------------------------------------------------ >> >> This doesn't seem to be a problem on a XCP 1.6 host. The devcloud >> xcp-xapi.log lists the following lines: >> >> [20130526T06:36:32.088Z|debug|devcloud|510 INET >> 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|audit] >> VM.set_memory_limits: self = 9b937ca6-9548-d334-0d01-54657aea2c3f (s-5-VM); >> static_min = 134217728; static_max = 104857600; dynamic_ >> min = 104857600; dynamic_max = 104857600 >> [20130526T06:36:32.090Z|debug|devcloud|510 INET >> 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|xapi] Raised at >> xapi_vm_memory_constraints.ml:56.13-184 -> xapi_vm.ml:157.1-90 -> >> pervasiveext.ml:22.2-9 >> [20130526T06:36:32.092Z|debug|devcloud|510 INET >> 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at >> pervasiveext.ml:26.22-25 -> rbac.ml:229.16-23 >> [20130526T06:36:32.092Z|debug|devcloud|510 INET >> 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at >> rbac.ml:238.10-15 -> server_helpers.ml:79.11-41 >> [20130526T06:36:32.092Z|debug|devcloud|510 INET >> 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|dispatcher] >> Server_helpers.exec exception_handler: Got exception >> MEMORY_CONSTRAINT_VIOLATION: [ Memory limits must satisfy: static_min ≤ dy >> namic_min ≤ dynamic_max ≤ static_max ] >> >> The memory limits are in the required range with static_min <= dynamic_min = >> dynamic_max = static_max >> >> >> Further investigating the failure. >> >>> creation of system VMs fail when using devcloud >>> ----------------------------------------------- >>> >>> Key: CLOUDSTACK-2683 >>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2683 >>> Project: CloudStack >>> Issue Type: Bug >>> Security Level: Public(Anyone can view this level - this is the >>> default.) >>> Components: Install and Setup, Xen >>> Affects Versions: 4.2.0 >>> Environment: Host OS is Mac OS X, devcloud 2.0 appliance >>> Reporter: Shane Witbeck >>> >>> Following the devcloud guide [1] in the wiki, I get the following exception >>> when the management server attempts to create system VMs: >>> WARN [xen.resource.CitrixResourceBase] (DirectAgent-21:) Catch Exception: >>> class com.xensource.xenapi.Types$XenAPIException due to >>> MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? >>> dynamic_min ? dynamic_max ? static_max >>> MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? >>> dynamic_min ? dynamic_max ? static_max >>> at com.xensource.xenapi.Types.checkResponse(Types.java:1936) >>> at com.xensource.xenapi.Connection.dispatch(Connection.java:368) >>> at >>> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) >>> at com.xensource.xenapi.VM.setMemoryLimits(VM.java:3735) >>> at >>> com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixResourceBase.java:3530) >>> at >>> com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1240) >>> at >>> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1582) >>> at >>> com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResource.java:143) >>> at >>> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:546) >>> at >>> com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:137) >>> at >>> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) >>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) >>> at >>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) >>> at java.lang.Thread.run(Thread.java:680) >>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud >>> Verified same setup steps work with 4.1. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira
