Yes, here: http://apaste.info/zz4
From clicking on "create" to receiving the deployment error. Ciao Martin -----Ursprüngliche Nachricht----- Von: Timothy Lothering [mailto:tlother...@datacentrix.co.za] Gesendet: Freitag, 10. Juli 2015 13:12 An: users@cloudstack.apache.org Betreff: RE: Deployment failed on XenServer due to capacity miscalculation Thanks Martin, Could you please dump your full logs somewhere so we can look into this further? -----Original Message----- From: Martin Emrich [mailto:martin.emr...@empolis.com] Sent: 09 July 2015 03:49 PM To: users@cloudstack.apache.org Subject: Re: Deployment failed on XenServer due to capacity miscalculation Hi! Am 08.07.2015 um 16:15 schrieb Timothy Lothering: > Hi Martin, > > Thanks for the information. > > From the details below, I understand that your Cluster will not allow > additional VMs to be created if 85% of the memory is consumed. This value is > important as you also need to factor in what amount of memory is required by > the Hypervisor (XenServer) to run. Xenserver needs a minimum of 1GB -- Check > out the following link: > http://support.citrix.com/servlet/KbServlet/download/34970-102-704220/installation.pdf. Correct. On the other host, only 60% is used, so still enough free space in the cluster. The cluster actually allows new VMs, but tries to start them on the wrong host. > Secondly, unless you are running memory intensive applications, using a 1:1 > ratio is not entirely economically viable, you can safely up the > mem.overprovisioning.factor to 2 or 4 (depending on your Memory over > provisioning calculations vs CPU). This means that you are essentially > doubling or quadrupling up on the actual amount of memory you have available. > We prefer to give our users the full memory they request. XenServer does no "real" memory overprovisioning, but proportionally scales VMs down if the hosts real memory is exceeded. Unless there's real dynamic memory scaling (including swapping, deduplication and pressure sensing), we prefer to stay at 1:1. > Another option to look at is your deployment.planners.order & > vm.deployment.planner fields. In my case, I use FirstFitPlanner for both as > we prefer to fully utilize each host before provisioning on another host. That's what I prefer, too. The problem is not that the algorithm is wrong, but that the data it bases its decisions on is faulty. So not CloudStack fails to create VM, but the underlying XenServer. Ciao Martin Timothy Lothering Solutions Architect Managed Services T: +27877415535 F: +27877415100 C: +27824904099 E: tlother...@datacentrix.co.za DISCLAIMER NOTICE: Everything in this e-mail and any attachments relating to the official business of Datacentrix Holdings Ltd. and its subsidiaries ('Datacentrix') is proprietary to Datacentrix. It is confidential, legally privileged and protected by law. Datacentrix does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of Datacentrix. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Datacentrix cannot assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference.
