start/Stop VMs during off-hours
Current start/Stop VMs solution in preview seems not so flexible due to the current limitaion/restriction and the use of the asset variables. Example:
1) Not allow to create multiple schedules to stop and start for different servers at different timezone in the same automation account. The Resource group and servers exclusion lists are all defined in the variables. Correct me if I’m wrong, in order to have the above solution in place, we need to have multiple automation account in place.
2) Not possible to set any specific date to exclude the job being triggered. For example we need the server to be On during Maintenance week but with the current limitation, we need to disable the schedule manually
1) This solution will create multiple runbooks with tagging version 188.8.131.52. Will this runbooks get updated automatically if there is any new release in future? If not, how do we get inform about the new version and how do we ensure the runbook is up to date and with no impact on the current scheduled?
2) What is your recommendation to use this "start and stop solution" to manage large number of servers except using the RI?
Can I create multiple schedules for multiple VMs attached to the same solution?
Ariel Coloma commented
Hi, is it possible now to set the following schedule?
1. Start 9:00 am weekdays only
2. Stop 6:00 pm weekdays only
3. Stopped during weekends from 6:00 pm Friday to 9:00 am Monday.
The solution needs a maintenance aspect to it. Like most we need to be able to bring the server up say once a week for 4 hours in the night to install updates and then shut back down until the morning.
Steve Kittinger commented
Hi Todd, I like the idea of adding parameters to the Parent runbooks to allow for greater customization. Ideally, we'd have Resource Group, VM List and Tag parameters. We have one subscription with hundreds (soon to be 1000+) VMs spread around the world and need the ability to stop/start all of them at times appropriate to their time zones without having to create separate automation accounts for every region.
David Schweikert commented
Further feedback from my side regarding the Start/Stop VM solution:
1) I miss the possibility of selecting a group of hosts by tag, as it is possible for Update management.
2) Once the solution is created, it seems impossible to see what the parameters are or to change them.
3) I wish it was as well integrated as the Update management feature (for instance not requiring a "Run As" account, etc.)
Once you deploy the solution, how do you go back and change the VMs its trying to START/STOP?
Is this solution applies to Reserved instances as well?
This is now released, You will have to uninstall/reinstall to get the changes. Give it a try and let us know any feedback.
Regarding including a VMlist parameter. The logic works like this. If no value is provided for this parameter, the runbook would determine which servers to start/stop as the logic works today by looking to these variables: External_Start_ResourceGroupNames, External_Stop_ResourceGroupNames, External_ExcludeVMNames.
If a comma separated list of servers was provided as a parameter to VMList the above variables would be ignored and the supplied server list would be the VMs that are targeted for start/stop actions.
A user could create multiple schedules with multiple schedules providing more granularity and potentially a way to manage more servers.
Alex Leong commented
Hi Todd, sorry, would you mind to share the solution on how to "add in a VM list parameter to "ScheduledStartStop_Parent" and "SequencedStartStop_Parent" to allow for scheduling servers directly? Currently I have created two schedule for daily and weekend but both are referring to the same variables. Please ignore the RI (Reserved Instance). My second question is more related to how we could use "start and stop" solution to manage large environment (looking at about 400-500 Azure servers)?
Hi Alex, thanks for submitting this feedback. You're pretty perceptive and call out some legitimate limitation in the current marketplace offering. To each of your points:
1. You are correct, it would require multiple automation accounts to achieve this in the current solution. What do you think of adding in a VM list parameter to "ScheduledStartStop_Parent" and "SequencedStartStop_Parent" to allow for scheduling servers directly? The logic could work similarly to this parameter that existing in the "AutoStop_CreateAlert_Parent" runbook.
2. Sorry what is RI?