Get-VIObjectByVIView error in PowerShell v3

[RvdNieuwendijk]

In PowerShell v3 the Get-VIObjectByVIView cmdlet generates two errors if you specify the MoRef of a virtual machine as a parameter. It works without any problem in PowerShell v2.

I know that PowerShell v3 is not supported with "VMware vSphere PowerCLI 5.1 Release 1 build 793510" that I am using. I just wanted to let the PowerCLI team know about this problem.

It has something to do with running PowerShell v3 using a single-threaded apartment, which is the default in PowerShell v3. If you start PowerShell v3 with the -mta parameter this problem does not occur.

PowerCLI C:\users\robert> $vm = Get-VM Storage-Test
PowerCLI C:\users\robert> $vm.Id | Get-VIObjectByVIView
Get-VIObjectByVIView : 7-1-2013 15:37:24    Get-VIObjectByVIView        The object has already been deleted or has not been completely created
At line:1 char:10
+ $vm.Id | Get-VIObjectByVIView
+          ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-VIObjectByVIView], ManagedObjectNotFound
    + FullyQualifiedErrorId : Client20_QueryServiceImpl_RetrievePropertiesEx_ViError,VMware.VimAutomation.ViCore.Cmdlets.Commands.DotNetInterop.GetVIObjectByV
   IViewCommand

Get-VIObjectByVIView : 7-1-2013 15:37:24    Get-VIObjectByVIView        The object has already been deleted or has not been completely created
At line:1 char:10
+ $vm.Id | Get-VIObjectByVIView
+          ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-VIObjectByVIView], ManagedObjectNotFound
    + FullyQualifiedErrorId : Client20_QueryServiceImpl_RetrievePropertiesEx_ViError,VMware.VimAutomation.ViCore.Cmdlets.Commands.DotNetInterop.GetVIObjectByV
   IViewCommand

Name                 PowerState Num CPUs MemoryGB
----                 ---------- -------- --------
storage-test         PoweredOn  1        4,000

[alanrenouf]

Thanks Robert.

[dmilov]

Hi Robert,

The error you've seen doesn't seem to be PS3.0 specific, it is an server error.

I've just tried to reproduce it with PS3.0 in STA mode and I didn't.

Here is the output:

PowerCLI C:\Windows\system32> $host.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
3      0      -1     -1

PowerCLI C:\Windows\system32> [threading.thread]::CurrentThread.ApartmentState
STA

PowerCLI C:\Windows\system32> $vm = get-vm

PowerCLI C:\Windows\system32> $vm.id | Get-VIObjectByVIView

Name             PowerState  Num CPUs MemoryGB
----                 ------------------ --------
TestVM          PoweredOff  1        0.004

Dimitar Milov,

PowerCLI Team.

[LucD]

For what it's worth, I had a similar message, but not with this cmdlet, in the past (PowerShell v2).

For me KB1039326 was the solution.

[RvdNieuwendijk]

Hi Dimitar and Luc,

thanks for your answers.

I did some further investigation and discovered that it is indeed not a PowerShell v3 problem.

The problem is that I have three vCenter servers connected in PowerCLI when I run these commands. The Get-VIObjectByVIView cmdlet generates errors for every vCenter server on which it can not find the MoRef. That also explains why I get the same error twice.

If I connect only one vCenter server in PowerCLI the command runs fine.

I would expect that the Get-VIObjectByVIView cmdlet would not generate an error if it could find the MoRef on at least one server. But that is of course a design decision. I wonder if this is by design or that you can consider to change the way the cmdlet works like I expected it would do?

Kind regards,

Robert van den Nieuwendijk

[Pavel_Dimitrov · Accepted solution]

Hi Robert,

We discussed the behavior of Get-VIObjectByVIView cmdlet with the team and we agree that it will be better not throwing an error if an object is found on some of the connected servers. I'll log a bug, but I cannot promise you the fix at this moment. Currently you can workaround this, specifying the server explicitly.

Thank you for the feedback and sorry for the inconvenience,

Pavel Dimitrov,

PowerCLI Team.

[RvdNieuwendijk]

Hi Pavel,

thanks for your answer and logging a bug. For now the workaround is fine. I am glad this problem will be fixed in the future.

Kind regards,

Robert van den Nieuwendijk