CMS VM CPU and host requirements

[Nick Halbert-Lillyman]

Reading through the CMS VM guides, the number of vCPUs required depends on the number of calls you want to support, which seems reasonable, however it appears that the same requirements apply to both the edge and core servers.  These requirements seem a bit excessive for the edge servers, considering it's not doing any transcoding - am I missing something or do you actually need the same amount of CPU per call as the core/Callbridge?

It also says you need to dedicate a host to CMS, which I assume means you can't run any other VMs on the same server - does this apply to the edge also?

[Patrick Sparkman · Accepted solution]

Take a look at the Virtualization for Cisco Meeting Server, it provides VM requirements for Core, Edge, and Combined deployments. It also lists requirements for external database and recording servers. 

[Nick Halbert-Lillyman]

Thanks Patrick and Jamie - I'd been reading the CMS VM installation guide: http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Installation/Cisco-Meeting-Server-2-0-Installation-Guide-for-Virtualized-Deployments.pdf

Which is a bit less helpful thank the link you provided :)

[Jaime Valencia · Accepted solution]

No, you can have a dedicated host for CMS, or run it co-res, but the sizing changes depending on that.

For a co-res deployment, CPU hyperthreading has to be disabled, and you only get 1.25 HD per physical CPU core

For a standalone VM (dedicated server), you can enable hyperthreading, and you get 2.5 HD per physical core.

CMS Edge only has two options, which are covered in the link Patrick provided.

[Jason Neurohr]

Hey Jaime,

Can you point me to where it is documented that HT must be disabled for a co-res deployment?

Jason

[Jaime Valencia]

I don't believe we have that info on documentation yet, most of the docs only talk about dedicated servers for CMS and not co-res deployments.

Where available, hyperthreading should be enabled on the host

The host must be dedicated to the Cisco Meeting Server

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Installation/Cisco-Meeting-Server-2-0-Installation-Guide-for-Virtualized-Deployments.pdf

[AhmedBassiony]

can we have two CMS 1000 servers, and on those two servers enabling the Hyper-threading, and install three instances of the the Database, as we need high availability and we have only two servers?

[Jaime Valencia]

No, 1 CMS 1K = 1 CMS instance

You need a 3rd CMS 1K, or to install as a VM on other server.

[Patrick Sparkman]

You need to install CMS on a third server, separate from the CMS 1000 servers. The CMS that will run the database doesn't have to be licensed though, as a database only CMS can run without an activate key or any license keys.

[Jonathan Els]

Hi Jaime,

Please can you quality this statement on disabling hyperthreading?

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-cisco-meeting-server.html

From the guide:

Running multiple VMs co-resident on a single host
When running multiple virtual machine on a single host, at most one vCPU per physical core should be allocated regardless of the hyper-threading mode. If an option is available to choose both number of sockets and number of cores per socket for a VM, a single socket should be configured with all the virtual CPU cores.

Compared to:

---

@Jaime Valencia wrote:

No, you can have a dedicated host for CMS, or run it co-res, but the sizing changes depending on that.

For a co-res deployment, CPU hyperthreading has to be disabled, and you only get 1.25 HD per physical CPU core

For a standalone VM (dedicated server), you can enable hyperthreading, and you get 2.5 HD per physical core.

CMS Edge only has two options, which are covered in the link Patrick provided.

---

To me, this indicates that your statement above about having to disable hyperthreading is incorrect.  It just means that in co-res mode, I must count physical cores only for port sizing.

Would you agree with this?  If not, please can you clarify where the explicit disablement is referenced?

Thanks!

[Jaime Valencia]

See slide 23

https://clnv.s3.amazonaws.com/2017/eur/pdf/BRKCOL-2803.pdf

Not sure if they might have changed their policies on that recently.

[Jonathan Els]

Yeah, this is great, thanks.  I just don't know what becomes the point of truth in this case.  I'd presume that the Wiki is. 

I can in theory see that hyper-threading's full wait time behaviour could create problems with video and contention during co-res, but I don't have sufficient low-level knowledge of VC characterization of CPU to time to assess it's impact on context switching.

Any suggestions on where to look for the answer to this?  Co-res is a pretty common requirement of us in the 7K market, so I would like to have an answer for future design guidance.

[Jaime Valencia]

Open a case with us and we can clarify that with the BU, sometimes the info in the virtualization wiki is written with a different wording and that causes confusion (even if they meant to explain the same thing).

[Jonathan Els]

Perfect - will do.

[Jonathan Els]

@Jaime Valencia

Confirmation from the BU in PDI case - 

Hi Jonathan,

The information I shared with you in the last email was gotten from a BU resource, so we can rely on it.
They said "Either can be right,its just what consequences you have in capacity", so it's not mandatory to disable hyperthreading for Co-residency deployments.