This is mostly due to incorrect calculation of XS memory overhead calculation by cloudstack. However, it is expected that the VMs launch is retried on other available host in cluster.
Regards, Somesh -----Original Message----- From: Martin Emrich [mailto:martin.emr...@empolis.com] Sent: Monday, July 27, 2015 9:55 AM To: users@cloudstack.apache.org Subject: AW: Deployment failed on XenServer due to capacity miscalculation Hi! (sorry for the delay, was on vacation). I have never heard of XenServer having this limitation, and have also never experienced it (We use XenServer w/o ACS heavily for several years now, but I never ran into this issue). I also found nothing conclusive... can you provide some documentation on this limitation? I'll try to evacuate and reboot the host, that might "reset" the stats and help. Thanks, Martin -----Ursprüngliche Nachricht----- Von: Stephan Seitz [mailto:s.se...@secretresearchfacility.com] Gesendet: Sonntag, 12. Juli 2015 22:52 An: users@cloudstack.apache.org Betreff: Re: Deployment failed on XenServer due to capacity miscalculation Hi there, despite not reading the whole thread, I'ld assume that there's simple no single memory segment of the requested size available at your particular xenserver. Just keep in mind, that Xen partitions memory and - after long run - could not assign a contiguous block, even if the sum of all segemented blocks is greater. It depends on the version (and if you're brave on different tmem settings) how reorganization is managed. Long story short: put the particular host in maintenance, reboot it and get it back into your ACS. cheers, Stephan Am Freitag, den 10.07.2015, 18:02 +0200 schrieb Martin Emrich: > Hi! > > Am 10.07.2015 um 16:42 schrieb Timothy Lothering: > > Hi Martin, > > > > From the logs it seems that ACS has found that the host has sufficient > > memory capacity, but when it deploys it, it seems there is not enough. It > > could be a bug whereby technically the system has enough capacity, but > > during the provisioning stage, it suddenly does not. > > > > errorInfo: [HOST_NOT_ENOUGH_FREE_MEMORY, 4447010816, 1744826368] > > > > I read this message as [..., Requested Memory, Available Memory ] on the > XenServer. > > > From the logs it seems you are also using Local Storage (vs Shared), so > > initially it finds that host 335 has enough memory (albeit ~7MB left) and > > tries to deploy. The deploy fails and it tries to redeploy the VM using > > Host 335's storage, which is inaccessible. > > > > 1. Have you tried to deploy a 2GB memory Machine on this host? > > Yes, won't work either, as the XenServer just had 1,7GB free. > But I could create a 512MB VM as expected. > > Now ACS thinks the host has 3,507 GB free, while XenServer reports 1,2GB > free. So the gap between what is really free and what ACS thinks is free > remains the same. > > > 2. Do both hosts have the same CPU and memory configuration? > > yes, absolutely identical. > > > 3. Try to the following: > > > > a. Increase the cluster.memory.allocated.capacity.disablethreshold from > > 0.85 to 0.90 and restart MS - Test redeploy > > b. Decrease the cluster.memory.allocated.capacity.disablethreshold from > > 0.85 to 0.80 and restart MS - Test redeploy > > > > The above two tests should get your Host a bit more manoeuvrability and see > > what happens in the MS Logs. > > No effect, as these options refer to a complete cluster, not a single > host. After changing them, ACS still tries to deploy a new 2GB VM on the > full host. > > I think the key is to somehow force ACS to _ask_ XenServer how much > memory is really free, instead of doing it's own calculations. > > Ciao > > Martin
