Hi Guys,
I'm starting to parallelize a script I've written and want to run my script against a number of VMs simultaneously. I can set the number of blocks running and I've been experimenting with finding the sweetspot.
To acheive this I've used a ScriptBlock and put almost my entire script inside the scriptblock. This hasn't been an issue.
My issue is that using Connect-VIServer seems to take a long time to execute (maybe it's just my lab box). The issue is compounded since I have to run it for every VM. (I have to run Connect-VIServer and Add-PSSNapin VMware.VimAutomation.Core for every scriptblock being run since a new powershell.exe is kicked off without inheriting any scope from it's parent.)
Is there any way around this?
Here's the code I'm using (I didn't write it) to schedule jobs:
$sb = {do stuff}
Thanks,
db
Clinton has a great post on avoiding some of the issues you are seeing with Start-Job.
See his Multithreading PowerCLI post
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
You can use the PowerShell v3 new workflow feature to run commands in parallel. That will give you the opportunity to connect to the vCenter server only once and run the commands for different vm's in parallel in one PowerShell script. See for more info: The Basics of Windows PowerShell Workflow: When to Use It and Why.
Although workflow is a great feature in PowerShell v3, note that the latest PowerCLI build does not (yet) support PowerShell v3.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Clinton has a great post on avoiding some of the issues you are seeing with Start-Job.
See his Multithreading PowerCLI post
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Although PowerCLI 5.1 R1 is not officially supported with PowerShell v3, I have been running PowerCLI 5.1 R1 with PowerShell v3 since they were released without any problem.
Thank you Robert - I'll try incorporating that and swapping out the jobs code.
foreach -parallel ($VM in $VMs)
This is going to be insanely powerful for me.
Thank you LucD on the support issue.
I'll finish the code written in v2, then re-write for v3 with workflows.
Update: The below was just proven false - seems it was an anomoly that it didn't work.
After some additional testing it looks like I'll be using v3 and workflows.
When I kick out a new powershell instance and run Set-NetworkAdapter it's throwing an exception stating the VM needs to be in a poweredon state.
When I run the same command in a powercli instance, the Set-NetworkAdapter command works fine when the VM is poweredoff (it actually only works properly when the vm is poweredoff).