I just came across a possible issue with Get-NADisk from PowerShell Toolkit Version 3.2. I think the property Status and RaidType do not contain correct data. As a result, I cannot determine spare disks with Get-NADisk anymore
Example 1: PowerShell Toolkit 3.0.1 Get-NaDisk 0d.03.11| fl name,status,raidstate,raidtype Name : 0d.03.11 Status : spare RaidState : spare RaidType : pending
PowerShell Toolkit 3.2 Get-NaDisk 0d.03.11| fl name,status,raidstate,raidtype Name : 0d.03.11 Status : present RaidState : RaidType : present
Example 2: PowerShell Toolkit 3.0.1 Get-NaDisk | Group-Object status -NoElement Count Name ----- ---- 3 dparity 35 partner 29 data 14 spare 3 parity
PowerShell Toolkit 3.2 Get-NaDisk | Group-Object status -NoElement Count Name ----- ---- 49 present 29 data 3 dparity 3 parity
Needless to mention that all commands were executed on the same host.
I had the same problem. This is the best compromise I came up with. As both filer spares and partner disks were showing as PRESENT instead of SPARE and PARTNER, the solution for me was to only capture disks from one filer at a time. That way, any PRESENT disks have to be spare disks. I dd this by combining the Get-NaDiskOwner and Get-NaDisk commands and exploiting the common denominator of the two commands, which is the disk name.
Here is an example of it in action, which connects to a filer called netapp01 and uses the IF command to only display the PRESENT (spare) disks.
This was introduced because we upgraded Get-NaDisk to take advantage of newer Data ONTAP APIs (which return more information about the disks), but unfortunately the new APIs do not return the RaidState. So as a compromise this parameter was introduced to allow users to force use of the old API in case they are unhappy with the new output.
Thanks for the update. It perfectly solves the problem. I guess you work together with Rajesh? I sent a message to him as he announced the latest version of the toolkit and I noticed that the assumed "bug" was still there. Rajesh also explained that this behavior is not a bug but can be circumvented by using the -old switch when using older Ontap versions.