Create snapshot with ExtensionData.CreateSnapshot runs for a long time

[MarCork]

I have a script that creates exact copies of a vmware lab environment to new environments on a daily basis. Part of the process is I create snapshots of the Master VMs then create clones from the snapshots. The step that creates the snapshot when run in the script takes anywhere from 5 to 45 minutes on a single VM. This is the code to create the snapshot:

<code>

$SnapExists = Get-VM $SourceVM.Name | Get-SnapShot -Name $SnapName -EA SilentlyContinue -WA SilentlyContinue;
If(-Not $SnapExists){
$thisSnapshot = $SourceVM.ExtensionData.CreateSnapshot($SnapName, $SnapDesc, $False, $True);
}

</code>

When I run this from command line, it creates the snapshot in seconds. Any ideas as to why the same command behave differently in my script and the command line?

[LucD]

Do the generated tasks you see in the Web console confirm this difference in execution time?

PS: where is that Get-CommandRuntime cmdlet coming from?

[MarCork]

Yes, the generated tasks from the web console confirm the difference in execution. When I watch the tasks, they'd quickly get to like 40-50% then just seem to pause for a really long time before advancing.

Get-CommandRuntime is a function I wrote that times the execution of a script or command.

[LucD · Accepted solution]

Since you are using the API method, this doesn't seem to be a PowerCLI issue.
You could monitor the PS process in which yu run the script to check if that waiting for one reason or another.
Another option is to check the vpxd log on the VCSA, which shows how the method is called and any potential issues.

[MarCork]

It turns out my issue was each VM having numerous snapshots from previous failed running of the script. Once I remove the old snapshots, the script started running as expected with no long wait. I updated my script to remove any old snapshots; if they exist; before creating a new one and that is working fine. I am still not sure why when done on the command line I wasn't having the same behavior but the issue seems resolved now.