i always use cloudmonkey to spin vm on a particular host
*cloudmonkey > !for i in {317..326} ; do cloudmonkey deploy virtualmachine
domainid=ca46xxxxxxxx7-11e3-9556-9a21ee1e2575
zoneid=52xxxxxx0dc-b9ce-c907750e0d61 displayname=hadoopvm-p$i
name=hadoop-p$i templateid=0a73a869-3aa6-4d69-94c7-4e9cd9231b73
serviceofferingid=94798ce4-45cc-429b-85f3-b168fadac6bc
networkids=85f3780a-1c26-4f76-9680-26786da626b9 *
*hostid=17b841d3-55c9-4f28-a94e-da20486881a8
**projectid=5dc4f1b8-9c14-47d4-8d0a-6dba9e6d6825
; done*
*cloudmonkey deploy virtualmachine domainid= zoneid= displayname= name=
tempalteid= serviceofferingid= hostid= projectid= ipaddress= *
*thanks *
*prashant *
On Thu, Aug 27, 2015 at 4:01 AM, Martin Emrich <martin.emr...@empolis.com>
wrote:
> Hi!
>
> I still have this problem. We added an additional server to this cluster
> last week, but it is not being used. ACS tries to start the VM on the first
> (full) server and aborts, while the new empty server is being ignored.
> Now I'll migrate some VMs manually to the new server, but I assume that's
> not the way it is meant to be...
>
> Ciao
>
> Martin
>
> -----Ursprüngliche Nachricht-----
> Von: Somesh Naidu [mailto:somesh.na...@citrix.com]
> Gesendet: Montag, 27. Juli 2015 18:40
> An: users@cloudstack.apache.org
> Betreff: RE: Deployment failed on XenServer due to capacity miscalculation
>
> 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
>
>
