Cloud Management and AIOps
This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
v8.14.4
Hot Add auto enable feature in the policy would need to be executed as part of compliance. We onboard VMs into our Turbonomic resize DOWN policies and enable Hot Add at the same time since they both require a reboot. Hence one reboot for Hot Add and one for Resize DOWN. I need to Hot Add to be enabled regardless of pending actions, otherwise if no pending action, Hot Add doesn't get enabled and any subsequent dynamic resize UP will not happen. Please ensure that Hot Add is a compliance requirement ensuring enablement.
How will compliance for Hot Add and vCPU Socket matching, vMEM, vCPU occur? All at the same time or individually reboots? Need to mitigate the back-off period to avoid delays in execution of pending actions. Expect that all actions get executed and finish withing a couple of market cycles.
@Simon Ravenscroft as the below statements have noted this would "significantly lower the barriers for customers to execute Turbo's actions." asking for double outages for turbo actions and also in most cases this would limit the enabling of hot add to VMs that get scale actions reducing downtime for VMs that do not currently need actions.
We had this same challenge in our environment when implementing Turbo's scaling actions. Scaling down to reclaim resources is only palatable to an end-user if they know Turbo will scale the VM back up non-disruptively when resources are needed again. By having hot-add automatically enabled during the action sequence, we would be significantly lowering the barriers for customers to execute Turbo's actions.
Level of effort is high to enable hot-add on VMs since it requires downtime. I'm now having to ask application owners to take their VM down twice. Once to enable hot-add, and again to have Turbo automatically size the VM.
So in our environment it was many hours over a few weeks of communicating to end users that we were going to take their VMs down, shutting down those VM, developing a script to enable hot-add on all powered-off VMs, and then powering the VMs back on. ...and guess what happens when someone deploys a new VM on a later date, the whole process needs to start happen again. Would rather avoid that situation completely and just have something take care of enabling hot-add when it's already taking the VM down for scaling.
This very well could be part of a broader feature to have some out-of-the-box action scripts that performed simple tasks. Enable hot-add, install VMTools, etc (perhaps others might think of more). Should be in the context of "if Turbo could also take care of this really simple task, it would be a no-brainer for me to execute this action."
The level of effort is significant since enabling hot-add requires the VM to be powered off, which would mean a separate outage window to complete this work. The advantage of doing this with Turbo is that Turbo will already shutdown the VM for scaling when hot-add is not enabled and customers can take advantage of the single downtime to enable hot-add on the VM instead of having multiple downtime windows to essentially achieve the same end result. Agreed we should have a popup or hover over explaining the impact of doing this. .In my case with customers, they want to have this enabled so that when scaling down they can have hot-add enabled to give resources as needed over time when additional performance is needed.
Nice idea, thanks Simon!
We do need to be mindful of the following if doing this:
Enabling hot-add negatively impacts some vCenter features (vNUMA; Fault tolerance being two) which would affect performance or availability.
The Guest OS needs to support it.
The Application needs to support it.
That said, perhaps an option to enable/disable/preserve hot-add sockets on the vCPU Scaling Controls policy settings would be a good first step. With a quick help or hover help to communicate the above so it's clear to the user what the impact is.
In terms of value. What is the level of effort required to enable hot-add on VMs ahead of automating the resize up actions?