Cisco document says that CMS1000 support up tp 96HD calls. My client purchased a CMS1000
and a SMP+ license for CMS. How should I edit the CMS vm (vCPU, vRAm...) which was preloaded on CMS1000 in order to support 96HD calls? I can't find any document talking about this.
Solved! Go to Solution.
Thank you for the quick feedback! Glad to know it's already known and almost fixed!
Meanwhile a colleague of mine figured out that by forcing the memory reservation, the swap file (.vswp) attached to the VM is tiny, and the vm can boot! If there is no reservation, the ESXi creates a .vswp of the size of the allocated vRAM.
I'd really appreciate if you can get a feedback about this setting. What are the impacts, if it's the way to go, if it improves or decreases the performances...
I'm still very interested to have the official values that we must apply as VM settings for a CMS node running on CMS1000. So far, this post and the answers from @Jaime Valencia is the best source, where the official installation guide should be.
I had created a public facing defect to get those settings published in an official document, but for now you can find the configuration in the RNE for the defect.
- As for what you did as a workaround that was exactly what the developers are looking to do, but I still would appreciate if you could open an SR to make sure we can track this issue properly.
* VMware has an article that explains what's happening, and how to resolve by reserving all of the guest memory.
* You can also find a more detailed explanation in the VMware best practices guide.
I would add more than a 5stars rating to your post @beandrew ;).
The bugID is already very helpful as official statement regarding the CPU and RAM settings to apply!
And regarding the memory reservation "workaround", it looks to me even more like a best practice avoiding extra disk I/O, as we want the Host resources reserved anyway, and avoid co-location with other VMs.
Kudo to you and to my brilliant colleague @alexandrospapadopoulos who found the right setting by himself!
Regarding the TAC case, I'm still waiting for the customer to order the Support part actually, I cannot open it right now. Chasing his procurement team ;).
The issue of SSH happened to me too, nothing I did not try to do the SSH refused and I tried everything, I changed VLAN, FW rules changes, routing test etc. The weird thing is that I was able to connect the CMS during the browser (to the webadmin page) but without SSH. This occurred while installing OVA version 2.9.3 so I uninstalled it and reinstalled version OVA version 2.9.2 and and everything back to work.
I simply wiped the pre-configured VM and created a new one from the OVA and based it on a working CMS VM from a different server.
Now what's puzzling is what I'm reading in the bug report about provisioning 64GB for the M5 server. I'm not currently facing any issues with my CMS servers currently configured with 58GB of ram but I'm guessing I should modify them?
Also on another weird note, I've had on 3-4 of instance where no matter what I do with the IP config inside the VM, I couldn't connect via SSH. I was getting an error along the lines of Connection refused. Spent several hours trying to figure out the first one, it was a new datacenter, new subnet, new vlan, etc... When I wiped the VM and re-created it, it worked right away. Go figure...
I was also surprised about the new statement of 64GB for M5 instead of 58GB for M4 series. I guess that this is more a "comfort" setting, as the M5 now is built with 128GB RAM. If it worked on M4 with 58GB, I don't see a technical reason why it would not on M5. However, it doesn't cost you too much to simply add 6GB RAM in the VM settings, except a 5 minutes downtime.
I'm glad this will be soon officially documented!
Thanks for the reply!