Bug 419019 / panic querying vfiler-specific resources

[iwhoskin]

Had my first run in with powershell cmdlts and vfilers, it panic'd a box.  Here is the details from NetApp.
Is there anything that can be done powershell side without having to go to a GA release?

Problem Summary:

The Multistore feature of Data ONTAP provides logical "vfiler" entities, each of which encapsulates a set of storage resources.  When an external management agent wants to interrogate Data ONTAP about the operations of a vfiler, it sends an ONTAPI-protocol message over the network to the physical storage controller, which interprets the message and internally dispatches the query or command to the correct logical vfiler.

The username associated with the message may be mishandled, and a null username is passed to the vfiler.  The missing data triggers an illegal address fault and causes an interruption of service.

Recommended Solution:
Bug 419019 is fixed. Data ONTAP 7.3.5RC1 (First Fixed) - Fixed
or  Data ONTAP 7.3.5.1 (GA) - Fixed

Workaround:

A customer can avoid the panic by preventing external management agents from querying vfiler-specific resources.

[cknight]

Hello, iwhoskin, sorry for the trouble.  This is a known ONTAP issue whereby a controller can panic if a system-cli API call is made in a vfiler tunneling context.  As you note, it is possible to trigger this issue with the PowerShell Toolkit.  We learned of this issue sometime after the Toolkit 1.3 release, and we will be providing a workaround in Toolkit 1.4.  In the meantime, the best workarounds are to connect directly to the vfiler context rather than using tunneling via vfiler0, or to temporarily avoid those cmdlets that rely on system-cli.  Here is the list:

Get-NaHelp | ? {$_.Api -Contains "system-cli" } | select Name

Name
----
Get-NaDomainUser
Get-NaSnapshotReserve
New-NaNetVif
New-NaSnapshot
Remove-NaNetVif
Remove-NaSnapshot
Rename-NaSnapshot
Set-NaNetInterface
Set-NaNetVif
Set-NaNetVlan
Set-NaQtree
Set-NaSnapshotReserve
Set-NaSnmpContact
Set-NaSnmpLocation

A few bits of the provider are also affected.  Toolkit 1.4 will address those as well.

[iwhoskin]

so when i connect to the context i usually do connect-nacontroller 'controller' -vfiler 'context' ... is that considered tunneling via vfiler0, if so can i connect-nacontroller 'context' instead?

[cknight]

Yes and yes.  Note that like CLI commands, there are APIs that aren't supported by vfilers, so some administrative tasks must be done via the physical filer (such as creating aggregates or assigning storage resources to vfilers).

The workaround in Toolkit 1.4 requires detecting whether current session is pfiler, vfiler direct or vfiler tunneling; in the last case we issue the CLI command to the physical filer using the 'vfiler run' mechanism.  That may be yet another alternative for you to use.