I obviously wasn't checking my environment well enough. I had this issue start on one of my vCenters. I believe our VMWare team was doing hardware changes that made this start happening.
FOR NETAPP: Here is how you can fix it in the certified version. Line 315 is currently " $hbas = Get-VMHostHba -VMHost $globalVmhosts" Append " -ErrorAction SilentlyContinue" to the end, and it will solve the issue.
Blando: Until Netapp fixes the certified Datasource, you can do the following to get around it.
From WFA go into the "Designer" tab
Go into 'Data Source Types'
Right click on the Vcenter Data Source Type, and choose clone.
Modify the following Fields:
-- Datasource Version: Append _modified, or something to change the name
-- Scheme: Choose vc
-- Script: Change line 315 to " $hbas = Get-VMHostHba -VMHost $globalVmhosts -ErrorAction SilentlyContinue" (This may be easier if you paste it out to some other editor like notepad, or notepad++)
Go back into Data Sources under the Execution Tab.
On the 6.3 acquisition issue, have you validated what version of OCUM you are running? I don't believe in pre OCUM 6.3 they had the metro cluster tables. If your OCUM install is anything other than 6.3, you will need to delete the datasource from your configs and re-add it with the proper version.
This is NOT a WFA error. The error is thrown by VMWare Powershell toolkit when a ESX Host dosn't have any HBAs and the cmdlet
is executed for this particular ESX host.
This is a toolkit bug. If there were no HBAs on an ESX host, the cmdlet should have returned empty instead of throwing an Object Referance Error. This case is not handled gracefully in the Vmware PowerCLI toolkit. I'll check if this is fixed in the new VMware PowerCLI 6.0
Else I'll log a bug with VMware.
WFA code can only ignore this error as described by Corey.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.