VMware Cloud Community
zenivox
Hot Shot
Hot Shot
Jump to solution

Get-VM throws error if inside Try function

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

0 Kudos
1 Solution

Accepted Solutions
LucD
Leadership
Leadership
Jump to solution

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}


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

0 Kudos
24 Replies
LucD
Leadership
Leadership
Jump to solution

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"
    }
}


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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!  

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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

try-catch.png


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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! 

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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:

 

zenivox_0-1609753662219.png

 

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:


zenivox_1-1609754196862.png

 

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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}


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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..

zenivox_0-1609758600074.png

 

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

0 Kudos
LucD
Leadership
Leadership
Jump to solution

There are a few things you could try:

- stop/start your PowerShell/PowerCLI session

- remove and reinstall PowerCLI completely

- try on another station


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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!

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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... 

 

zenivox_0-1609842919482.png

 

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

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

 

zenivox_0-1609843677062.png

 

0 Kudos
zenivox
Hot Shot
Hot Shot
Jump to solution

these the modules installed:

zenivox_0-1609843794256.png

 

0 Kudos
LucD
Leadership
Leadership
Jump to solution

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


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos