PowerCLI Get-TagAssignment and InaccessibleDatastore

I was recently speaking with a customer who mentioned an issue that occurred when using the PowerCLI Get-TagAssignment cmdlet. They had a tag category which applied to clusters only. If a host were offline or in maintenance mode, they were getting an error that a local datastore was not accessible. I was able to recreate this issue and observed the following error text.

Get-TagAssignment -Category h225-clusteronly-category

Tag                                      Entity
---                                      ------
h225-clusteronly-category/h225-cluste... h206-cluster-storagepath
Get-TagAssignment : 7/14/2024 10:30:04 AM       Get-TagAssignment               Datastore 'Local-h206-vesx-02' is not accessible. No
connected and accessible host is attached to this datastore.
At line:1 char:1
+ Get-TagAssignment -Category h225-clusteronly-category
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-TagAssignment], InaccessibleDatastore
    + FullyQualifiedErrorId : Client20_TaggingServiceCisImpl_GetVDisks_Error,VMware.VimAutomation.ViCore.Cmdlets.Comma
   nds.Tagging.GetTagAssignment

This is a peculiar error as the tag category only specifies ClusterComputeResource as an Associable Entity, so datastores should not be in scope and it is unexpected to see them called out in this context.

While looking into this error message, I stumbled across this blog post from a couple of years ago: https://virtuallyjason.blogspot.com/2022/02/powercli-and-get-tagassignment.html. The article doesn’t touch specifically on this error message, but discuses performance related impact on specifying the -Entity parameter of the Get-TagAssignment cmdlet. I did a bit of testing and confirmed that not only does specifying the entity improve performance, it also suppresses the error message that occurs for offline datastores.

To double check performance, I wanted run each command several times. The loop below runs each command 100 times, then outputs the min, avg, and max run times for each command. In my case, specifying -Entity (Get-Cluster) caused the execution to complete on average 5x quicker.

$myCommand = @()
1..100 | %{
  $myCommand += [pscustomobject][ordered]@{
    Iteration = $_
    RunTime1 = (measure-command {Get-TagAssignment -Category h225-clusteronly-category}).TotalSeconds
    RunTime2 = (measure-command {Get-TagAssignment -Category h225-clusteronly-category -Entity (Get-Cluster)}).TotalSeconds
  }
}

$myCommand | Measure-Object -Property RunTime1 -Minimum -Average -Maximum 
$myCommand | Measure-Object -Property RunTime2 -Minimum -Average -Maximum 

When using Get-TagAssignment there are a couple of good reasons to limit the scope of the cmdlet to only those entities required.