#Get-NcDisk not working via ONTAPI on new arrays

1 messages · Page 1 of 1 (latest)

sinful fog
#

We've encountered a unique issue recently on some new arrays being setup (that we downgraded from 9.15) where Get-NcDisk with the ONTAPI controller object times out, but works via REST, albeit still slowly.
Error message "Get-NcDisk: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."

The larger curiosity is all other ONTAPI cmdlets tried worked without issue and all of our existing arrays do not have this issue with Get-NcDisk at all.

Array is on 9.13.P9 and Powershell Toolkit 9.14.1.2401 (also tried 9.15.1.2410 with no real difference).

While this on its own is a fairly innocuous and minor issue where I've already identified a workaround, it leaves doubt as to if other ONTAPI cmdlets we haven't tested yet will work or suffer a similar timeout. And it would be best to not find that out during an emergency.

flint ingot
#

ONTAPI is not a great place to spend troubleshooting effort.

From other conversations, I believe the ONTAP Powershell Module removed all ONTAPI/ZAPI in version 9.14. I know because it broke some of my tools as there’s not yet a rest equivalent.

#
sinful fog
#

ONTAPI is not a great place to spend troubleshooting effort.

I understand this, but it is a lot more of an effort to update all of our codebase to the REST equivalents, as it isn't truly a drop-in replacement (things without a REST equivalent aside). We've been using REST for new things, but conversion of existing code will not be a quick or pain-free process.

We are currently using the ONTAPI functionality still in 9.14 everywhere in our existing environment without issue. Including the command I listed as having an issue. Figuring out why these new arrays are not behaving the same way as the rest of our fleet when we are using the same ontap version and same powershell toolkit version, raises doubt in general about how much we should trust these arrays to work with any code. They're already aberrant in behavior.

Debug logging also gave no extra details, as it sends the request to the array and then hangs as before, eventually returning that the connection was forcibly closed by the remote host. This reinforces to me that either the request is being formatted incorrectly or the array doesn't know how to handle it. And based upon our ability to use this everywhere else in our environment, the array seems to be the more likely culprit.

flint ingot
#

If you do the API “manually” using CURL or powershell’s ‘Invoke-RestMethod’ and the result is the same, that’s a formal case against ONTAP and you should open a case with support.