I’m going to be publishing some of the scripts I have written for VMM. These are each based on specific customer asks or conversations that lead me to go sleepless in trying to solve the problems myself. I am very interested in your feedback, especially if you would like to offer a change to improve efficiency or effectiveness.
The idea behind this script is to accelerate changing the configuration of a VM so the amount of downtime required is minimized. The script focuses on Memory and Processor Count since those are the two values that require reboot. Performing this change “manually” meant multiple clicks and dialogue navigations. In automating the change via script I can typically reduce downtime to under 60 seconds.
After a lot of experimentation, I also implemented a choice menu in the script so before committing the change and starting the process. You will be prompted to either continue, continue with intelligent placement, or stop. The idea is if you are adjusting the amount of memory in a VM to a significantly higher amount, there may not be available memory on the same host to start it. Rather than waiting for the cluster to figure this out and move a VM, the script does a quick check for the best host across the cluster, moves it, and then starts it. Note – the “best host” may still not have enough memory available, so some common-sense qualification of the memory amount is recommended!
In each of the scripts for this series, I have noted any manually assigned variables at the top of the script just under the header. For this script you will want to update your VMM server name and the Host Group name.
In each of the scripts for this series, I have added a line to load the VMM snap-in. This way it can be run from any machine, including a workstation, where the VMM console is installed by right clicking on the file and choosing “run”. If you run the script from within VMM you will get a few lines of error text that the snap-in is already loaded. You can either ignore this, or comment out the line if it bothers you.
Script starts by giving you a list of VMs. No error checking on this value, if you fat-finger the name the script would try to run but end in error that a VM by that name does not exist. See the snap-in error at the top? Since I launch from VMM, that is expected. I just ignore it, feel free to # it out.
The next screen gives you the current values for the VM and asks you what you would like to change them to. In this case I kept the values the same. The script doesn’t care, it assumes the person running the script is smart enough to know and still wants to make the “change”. The way I see it, the script should never argue with me.
Script prompting for confirmation. Just to be fancy, I did put in text for the help values, as demonstrated above.
The script finishes by returning the status of the VM as each of the jobs run. Nothing pretty. If you want pretty, switch over to the VMM console. You can see the shutdown, change, and start. If a move had occurred you would see that listed as well. In this case the VM was already on the best host. Not too bad, from shutdown to startup completing it took 46 seconds.
disclaimer: this script is not supported in any way. I have posted the code rather than the .ps1 file so that you can review it, modify it to make it your own, and test it before trusting it in a production environment. now this is your code, I am not responsible for its use.
(Modified Script on 10/7 on line 22, avoiding move to same host)