Get-VM throws error if inside Try function

[zenivox]

Hello, I'm experiencing a weird issue but most likely due to lack of knowledge on my side. See the few lines below:

$test1 = $true
Try {Get-VM -Name $computer​​}
Catch {$test1 = $false}
Finally {
if ($test1){
Write-Host "OK"
}
}

If I run just the Get-VM -Name $computer I get the right output. If I run the whole thing I get:

Get-VM : 12/23/2020 3:39:37 PM Get-VM VM with name 'testVM​​' was not found using the specified filter(s).
At line:3 char:10
+ Try {Get-VM -Name $computer​​}
+ ~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (:) [Get-VM], VimException
+ FullyQualifiedErrorId : Core_OutputHelper_WriteNotFoundError,VMware.VimAutomation.ViCore.Cmdlets.Commands.GetVM

OK

 

there must be something with the Try function that I don't know. However if I use the $computer variable inside other functions it works. Also... shouldn't the Catch set $test1 to false and then the "OK" message should not come out?

My environment:

PS v.5.1

PowerCLI Version
----------------
VMware PowerCLI 12.1.0 build 17009493
---------------
Component Versions
---------------
VMware Common PowerCLI Component 12.1 build 16997174
VMware Cis Core PowerCLI Component PowerCLI Component 12.1 build 16997582
VMware VimAutomation VICore Commands PowerCLI Component PowerCLI Component 12.1 build 16997984

[LucD]

It is a matter of scope of the variable inside the Try-Catch code blocks.
By using the Global scope, you assign a value to a variable that is outside the block.

$computer = 'MyVM'
$global:test1 = $true

Try {
    Get-VM -Name $computer -ErrorAction Stop | Out-Null
} 
Catch {
    $global:test1 = $false
}
Finally {
    if ($global:test1){
        Write-Host "OK"
    }
    else{
        Write-Host "NOK"
    }
}

[zenivox]

many thanks Luc! As soon as I get back to this I'll check and revert. You are right about the boolean variable that should be declared as global before the Try/Catch. But by adding the 

-ErrorAction Stop | Out-Null

after the Get-VM command you are bypassing the problem. I know it sounds absurd but that is why I asked for help. The VM exists for sure but the Get-VM fails in the Try block and succeeds outside. I will get back to this very soon..  meanwhile many thanks!  

[LucD]

No, I'm not bypassing the problem with the Out-Null, I just didn't want the OK/NOK output cluttered by that VM object.
The Get-VM works in the try block, and if the VM does not exist I get the "NOK"

The following is that exact code in a .ps1 file, without the Out-Null.
1st run with an existing VM, 2nd run with a non-existing VM

[LucD]

And the -ErrorAction Stop is required because otherwise the script would never get into the Catch block.
A Get-VM for a non-existing VM is not a terminating error.

[zenivox]

Ok, I see.. I'll check how it goes and revert! Meanwhile I'll take the opportunity to wish you a great 2021 Luc!! All the best and again a big THANK YOU for all help provided! 

[LucD]

Thanks, same to you, a Happy(ier) 2021 

[zenivox]

Ok, I'm back. Apologies I accepted your post as a solution but it was by accident. So basically by declaring the global variable the Catch block is fixed and the loop flows fine. However, as reported in the original post it is the Get-VM that behaves dodgy. Look screenshot below:

 

 

first run is from command prompt and the second from the panel. Same behavior in VS Code. If I run the whole block I get NOK which is wrong because the VM exists:

 

[LucD]

So basically, there never was a question about Try-Catch 

You have a Get-VM for a specific VM that works one minute and doesn't work the next minute.
I would first look at the reliability of the VCSA connection.

You could also check if the Get-View shows the same behavior.

Get-View -ViewType VirtualMachine -Filter @{'Name'=$computer}

[zenivox]

well... the initial question has two queries, one for the Get-VM and the second for the Try/Catch. My bad for not using the global assignment and thank you for that!

On the other side, if I use the Get-View the output is consistent and positive on each run. Regardless if run alone or inside Try/Catch..  if run together the Get-VM keeps getting NOK while Get-View works..

 

Frankly I have no idea... I'll leave it and use the Get-View. Later I'll see on another machine but this one is THE scripts host for managing the VI. Thanks Luc..  I'll accept your workaround as a solution for now

[LucD]

There are a few things you could try:

- stop/start your PowerShell/PowerCLI session

- remove and reinstall PowerCLI completely

- try on another station

[zenivox]

Thanks Luc.. I did initiate a different session on VS code and it behaves the same.. I'll look into the third point you suggested, which will eventually lead to the second point! Many thanks again!

[zenivox]

Hi Luc, I am really really sorry to bother with this again. I certainly can go via the Get-View on newer scripts but I have plenty of other scripts that now won't work when executed from the IDE panel. Yes, I need to stress that if script runs execution works fine, it is just when executed from the IDE panel that the line Get-VM can either fail or succeed. It's just very annoying... because I'm working on orchestration kind of scripts and are rather long and intricated. So testing from panel is essential for me!  From what I searched on Google I don't see similar cases so it "seems" this is a problem I'm experiencing. I tried your advice and installed latest powercli on 3 different machines (one of which freshly installed) with the following PS versions:

Name Value
---- -----
PSVersion 5.1.19041.610
PSEdition Desktop

Name Value
---- -----
PSVersion 5.1.17763.1490
PSEdition Desktop

Name Value
---- -----
PSVersion 5.1.14393.3866
PSEdition Desktop

The PowerCLI modules all go to the C:\Program Files\ path. The three hosts give the same result. If I select Get-VM $computer and click on F8 I get a response that can be positive or negative and if I keep pressing F8 the response is always the same. If I stop and simply select again the same line and run F8 again I get the same or opposite response. I tried this on ISE and VS Code..  any other suggestion??  My apologies again for persisting with this... 

 

 

[LucD]

No problem.
What is that IDE?
Is that VS Code editor?

[zenivox]

I used VS Code 1.52 (user setup) and the old ISE available on any Windows

[LucD]

And both (VS Code and ISE) have the Get-VM issue?

[zenivox]

yes, correct. On the freshly installed Windows 2019 I didn't install VS Code.. I just used the ISE:

 

 

[zenivox]

these the modules installed:

 

[LucD]

Those are currently the latest versions of the PowerCLI modules.

Since the issue does not happen when using Get-View, I think we can eliminate an issue with your vSphere environment.
So all observations seem to point to an issue with Get-VM.

One more thing you could try is to install an older PowerCLI version and check if the problem pops up again.

In any case, I have not experienced or heard of that issue with that PowerCLI version.

I would definitely suggest opening an SR for this issue.
And contrary to what GSS might claim, you don't need a Devleoper Support contract for PowerCLI issues.
Point them to PowerCLI Support Breakdown

[zenivox]

Thanks Luc, really appreciated! Tried version 11.5 and it's the same. I'll see to contact support... Cheers!

[zenivox]

I'll add that the 3 machines where I tested are on different vlans

[LucD]

I just taled with someone from the PowerCLI Dev team.
We all tried to reproduce what you are seeing but to no avail.

It would help if you could capture the error with the Get-ErrorReport function., and attach that to your SR.

That function is documented in Improving PowerCLI Support with Get-ErrorReport

One way to capture the error is by running Get-VM in a ForEach loop x number of times.
Perhaps something like this (but make sure the error occurred at least once in that loop)

$errorCode = {
    $computer = '<VM-Name>'
    1..10 | ForEach-Object -Process {
        Get-VM -Name $computer
    }
  }
Get-ErrorReport -ProblemScript $errorCode -Destination . -ProblemDescription "Intermittent Get-VM issue"

 

[zenivox]

MANY THANKS AGAIN Luc! I captured the error with the GetErrorReport function. However I've uploaded a small video that shows how it happens... just for the sake of seeing this weird thing  

[zenivox]

also in the GSS web I can't find the PowerCLI listed in the products.. am I in the wrong place?

https://my.vmware.com/group/vmware/get-help?p_p_id=getHelp_WAR_itsupport&p_p_lifecycle=0&_getHelp_WAR_itsupport_execution=e3s2 

I followed the vmware support breakdown for PowerCLI but I have no choice to select from, and the Next button is greyed out as a consequence... 

 

[LucD]

The  PowerCLI Support Breakdown post states

• Open a support request for the product area where the failure is occurring

so in your case, that would be System Management I guess.