ACP 130 with ESXI 6.5 cannot deploy more than 4 Aura app VMs

[nortavaya]

Hi all,

I have issue with ACP130 (Avaya Converged Platform) Server Dell R640 shipped from Avaya, it comes pre-installed with VMware ESXI 6.5

We have deployed 4 Avaya applications OVA on this server (SMGR, ASM, CM and AES) working fine, we want then to add Media Server VM (or any other VM machine) but we got error on during deployement saying that there is not enough CPU ressources on this ESXI Host, however, when I check on the general CPU ressources of the Host, I can see that there is arround 70 % free ressources !!

Does anyone already encounter this issue with ACP 130 (provided by Avaya) ?

Thank you in advance.

 

[kyle555]

ACP130 just means it's regular VMware and not VMware Essentials - a more basic less featured version. AVP = ACP120 = VMware Essentials. ACP130 = VMware proper.


SDM makes sure to reserve all CPU and RAM and thick provision disk. Even if you had a fully loaded server, it's darn near impossible every VM would spin at 100% and you'd see 100% CPU in use.

What SDM is telling you is that you don't have enough CPU or RAM to reserve for the next VM you're trying to deploy. So, if you have 12 vCPUs and you deploy 3 CMs with 3 vCPU each via SDM, then you'll have 9 of them reserved. Even if they're all turned off, you can't deploy a AAM that needs 4 vCPU on top.

Now, you could go turn off reservations in the VMs already deployed so SDM will see that it can "reserve" CPU or RAM for the next VM. If you know what you're doing, or you're managing a much larger VM environment, you've got to kind of cheat a bit. Just as you and I know it's not reasonable to expect any of these VMs to run 100% all the time, you can't plan a data center with provisioning that assume each VM runs 100%.

You'll get a slap on the wrist from Avaya support if your resource starvation caused the problem.

But otherwise, check with your designer/engineer. In Avaya 1 Source/ A1S, when you design a solution with... I dunno... a CM Duplex and 2 Session Managers of Profile 3 and so on and so forth, you decide for each element if you're bringing your own customer VMware or if you're using AVP/ACP120 or buying a dedicated server for each application or going ACP130.

When the design crunches down, it does the assignment of each VM on each physical server you're buying.

All to say, if you got a job installing ACP130s for whatever kind of install, it should stand to reason that the design should have done some of this thinking for you.

 

[nortavaya]

Hi Kyle555

Thanks for your reply, yes in our case we are using ACP 130 (and not ACP 120)

So you mean that the reservation of VM resources during Avaya Application deployement (through SDM) can causing this issue, however, I have used Vsphere Web Client to deploy VM (except SMGR, I used SDM)

Now I have for VMs running: CM, ASM, SMGR and AES

Once I tried to add another VM to this four, I got error saying (there is no enough CPU resource)

Do you know what is solution of this, what I can do to resolve the issue ?

Thank you.

 

[kyle555]

Well, I'm thinking your problem is that you're not deploying in line with what the design called for.

It's happened on some of our 7.x+ installs - you don't get the exact output from the design tools that placed the order.

The servers are sold as small, medium, large, etc. Either the comcode or looking at the host info in esxi with CPU type and ram would give me an idea.

You can deploy till the cows come home in esxi yourself, it's just that the VMs have a reservation, so you can't power on 20vCPU's worth of virtual machine on a 16 vCPU server.

What you can do is remove the reservation in each VMs options after that fact, but you're kind of robbing Peter to pay Paul.

SDM is Avaya's tool on top that does extra stuff + like enable root, patch, upgrade and run Avaya special scripts in the deployed VMs to make your workflow simpler. It's stuff that esxi has no idea about. But, one of the constraints there is it has failsafe in it to not let you do the job wrong - so when you deploy, it books and reserves all the disk, CPU and ram each VM needs.

So, say you deployed 16vCPU and 16 GB RAM across 3 VMs and your server only had 16 CPU/GBRAM and you wanted to deploy another VM with SDM, you could go into esxi and disable the reservations on the existing VMs and then SDM will let you deploy more.

What's the 5th VM you want to run? AES is light, so is CM. SM can install in 6 different profiles all the way down from 3vCPU to 60+vCPU

What profiles of each VM are you expecting to install?

 

[nortavaya]

Hi Kyle555
Many thanks for your reply and solution, it works fine now for the 5th VM machine (AMS) after disabling reservetion and deploying through Vsphere web client...great

However for the 6th VM machine (AADS : Avaya Aura Devices services), it can be deployed only through SDM => do you know how to disable VM reservation in SDM ? because I got the same error (CPU resource not enough!)

Thank you.

 

[kyle555]

You can deploy aads on sphere without sdm.

Still, without knowing what profiles of VM you're using and what your server specs are, be careful.

If it's for your lab, go nuts.


If you unreserve each VM and SDM still can't deploy, look for what it's not liking - disk/ram/cpu

You can thin provision hard disks but if you rob Peter to pay Paul there and go over, you can irreversibly screw up your VMs.

 

[nortavaya]

Thanks Hi Kyle555, but I think Avaya they have notice there is issue with deploying some OVA through Vsphere client (like SMGR and AADS) , see this link =

https://support.avaya.com/ext/index?page=content&id=SOLN344656

The only options is to deploy either through SDM or VCenter

When I try to deploy AADS through SDM, I still got VM reservation CPU error, I don't know how to disable reservation on this VM through SDM

Thank you.

 

[kyle555]

Good find. I don't deploy on acp130 often. Didn't know there was a problem on straight esxi.

Otherwise, turn off any VM, edit settings, where the CPU part is, put reservations to 0. If you do that on all your VMs, AADS should deploy.

Just cause you can doesn't make it a good idea!