Summary:
I am using the PowerCLI plugin to PowerShell to perform repetitive actions on a 6.7 vCenter that include Get-Tag and Get-TagAssignment. The environment I administrate is thousands of VMs over 100+ hosts and when processing some VMs the tag commands can take > 60 seconds and in some cases several minutes to perform a simple assignment lookup on a single VM.
Question:
Is there a known issue (I've searched and seen many posts from years gone by on this) with a bug track or is there a workaround that can reduce the time for these actions?
Other Details:
My script is designed to make the fewest calls necessary after extensive Get-VM/Get-View filtering. I have verified the Tag commands are where the delays are coming from by using PS Write-Progress statements in front of the commands. After several runs I did note that VMs that do have a vCenter tag assigned process quickly and VMs that do not have a vCenter tag assigned are showing the delay. I have also tried using the community Powershell plugin: rCisTag and rCisTagAssignment which are showing the same behavior which suggests the API is a factor?
The Tag related cmdlet are known to be very time-consuming.
The latest PowerCLI releases have introduced some improvements to that.
Which PowerCLI version are you using?
Would you care to share your code?
There might be some improvements possible.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Powershell VMware Modules/Versions:
PS C:\Scripts> Get-Module VMware* -ListAvailable | Select Name,Version
Name Version
---- -------
VMware.Community.CISTag 1.0.0
VMware.CloudServices 12.0.0.15947289
VMware.DeployAutomation 7.0.0.15902843
VMware.ImageBuilder 7.0.0.15902843
VMware.PowerCLI 12.0.0.15947286
VMware.Vim 7.0.0.15939650
VMware.VimAutomation.Cis.Core 12.0.0.15939657
VMware.VimAutomation.Cloud 12.0.0.15940183
VMware.VimAutomation.Common 12.0.0.15939652
VMware.VimAutomation.Core 12.0.0.15939655
VMware.VimAutomation.Hcx 12.0.0.15939647
VMware.VimAutomation.HorizonView 7.12.0.15718406
VMware.VimAutomation.License 12.0.0.15939670
VMware.VimAutomation.Nsxt 12.0.0.15939671
VMware.VimAutomation.Sdk 12.0.0.15939651
VMware.VimAutomation.Security 12.0.0.15939672
VMware.VimAutomation.Srm 11.5.0.14899557
VMware.VimAutomation.Storage 12.0.0.15939648
VMware.VimAutomation.StorageUtility 1.3.0.0
VMware.VimAutomation.Vds 12.0.0.15940185
VMware.VimAutomation.Vmc 12.0.0.15947287
VMware.VimAutomation.vROps 12.0.0.15940184
VMware.VimAutomation.WorkloadManagement 12.0.0.15947288
VMware.VumAutomation 6.5.1.7862888
As to the code, the relevant command (below) is part of the scriptblock from an "If" statement (limiting the call on an as-needed basis) after which the $VMTags array is parsed for specifics:
$VMTags = Get-VM $VM | Get-TagAssignment | Where {($_.Tag -like "Domain*") -or ($_.Tag -like "Custom*")}
In my testing, I put a "Write-Progress" statement in front of this command to track which $VM objects were stalling. As noted in the OP I also tried the Get-rCisTagAssignment community module and noted the same stalling behavior on $VM objects that did not have a tag.
Again, to me this seems more like an API problem than a Powershell/PowerCli issue..
You have the latest PowerCLI version, that is good.
And yes, as I mentioned earlier, the Tag related cmdlets are notoriously slow.
And indeed, that is most probably due to the internal Tag handling code, and not PowerCLI.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference