The capabilities of PowerShell/PowerCLI always intrigue me; when I'm tasked with any project or objective where its usage saves time, increases consistency and makes work more efficient, I look for methods to integrate it. Not being exceptionally proficient with it requires me to often research and test, but it's well worth it when the results achieve the target goal consistently and productivity improves.
I was once involved in repetitive, planned Disaster Recovery Tests (Bubble Tests) that had a very specific requirement: The failed over VMs in the isolated network needed to have IP settings that varied from the settings of their SRM Recovery Plans. Changing the actual Recovery Plan settings for each one of the involved VMs and groups was not allowed - If there was ever a need for a true fail over event and the Recovery Plan was modified, that would not have been good, plus that would mean changing the entries back after the tests completed.
I was once involved in repetitive, planned Disaster Recovery Tests (Bubble Tests) that had a very specific requirement: The failed over VMs in the isolated network needed to have IP settings that varied from the settings of their SRM Recovery Plans. Changing the actual Recovery Plan settings for each one of the involved VMs and groups was not allowed - If there was ever a need for a true fail over event and the Recovery Plan was modified, that would not have been good, plus that would mean changing the entries back after the tests completed.
Initially the IP, Default Gateway and DNS values for the VMs in the 'Bubble' were manually changed from the console; this method consumed a lot of time as we needed to do it for multiple machines, it was prone to errors and had to be done every time the Bubble Tests were ran.
Invoke-VMScript cmdlet, is an amazing tool!
The goal was to change IP, Subnet, Default Gateway and DNS values. Since the bubble tests were repeated, it was worth taking the time to build the commands for each VM.
Two commands needed to run for each VM after the SRM bubble test was failed over and machines were up and running, first command to set DNS and second to set IP, Subnet & DG.
Connect-VIServer RecoverySite-vCenter
Invoke-VMscript -VM MachineName -ScriptText "netsh interface ip set DNS 'Local Area Connection 1' static Primary-DNS-IP Secondary-DNS-IP" -GuestUser Administrator -GuestPassword 'LocalAdminPassword' -RunAsync
Invoke-VMscript -VM MachineName -ScriptText "netsh interface ip set address 'Local Area Connection 1' static IP-Address SubnetMask DefaultGateway" -GuestUser Administrator -GuestPassword 'LocalAdminPassword' -RunAsync
Some details:
Connect-VIServer RecoverySite-vCenter Connect to the recovery site which is where the bubble VMs are running.
The Invoke-VMscript command allows to send and execute Windows commands inside the guest from PowerCLI - this is a very powerful option that I also used to patch Windows Templates Automatically.
netsh interface ip set address command needs to have the correct name of the Local Area Connection as listed in the OS, some machines may have this renamed and the command obviously needs to reflect that. Use single quotes for the connection name: 'Local Area Connection 2' per example.
For multiple VMs inside the bubble, the commands to change DNS were ran first for all systems, then the commands to change IP, Subnet & Default Gateway last.
An edited command for a machine named My2012Server may look like this:
Invoke-VMscript -VM My2012Server -ScriptText "netsh interface ip set DNS 'Local Area Connection 1' static 10.10.20.15 10.10.20.16" -GuestUser Administrator -GuestPassword Cr@zyP@ssw0rd -RunAsync
Invoke-VMscript -VM My2012Server -ScriptText "netsh interface ip set address 'Local Area Connection 1' static 10.10.30.131 255.255.255.0 10.10.30.1" -GuestUser Administrator -GuestPassword 'LocalAdminPassword' -RunAsync
Some time afterwards I also discovered the SRM built-in dr-ip-customizer command which also was very helpful for this and other related tasks. I may do a blog post about it soon.
No comments:
Post a Comment