Are you connecting to the controller and vfiler before listing the qtrees? Note from the cmdlet help for get-naqtree
-Controller <NaController> The Data ONTAP controller object, embodied by an NaController object. This parameter is returned by the Connec t-NaController cmdlet. If not specified, the value in the global variable CurrentNaController is used.
If you connect to the controller and vfiler using the "connect-nacontroller" cmdlet the vfiler context is set then the "get-naqtree" cmdlet will only list qtrees assigned to that vfiler. For example:
Import-Module DataONTAP $controllername = "testns01" $vfilerName = "testnv01" $username = "root" $password = Read-Host "Please enter the password for user ""$username""" -AsSecureString $credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $username, $password Connect-NaController -Name $controllername -Vfiler $vfilerName -HTTPS -Credential $credentials Get-NaQtree
If you connect to the controller (without specifying the vfiler) then it will list all qtrees...however i see your point about the "OwningVfiler" property as it is "vFiler0" for all qtrees.
A workaround would be to use:
Invoke-NaSsh -Command "qtree status -v"
as this will report the "owning vfiler" field.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
thanks for the reply. Looks like I expected a little too much from it - thought it would give me the same thing like the CLI.
I connect to the physical box and wanted to have the OwningvFiler field correctly populated. Of course I could go and iterate through all vfilers (if existing), or parse the CLI output myself.
However, I also notice that the culprit is obviously not the cmdlet, but Ontapi itself. When I try an "qtree list" API call (e.g. through ZEDI), the filer returns the same "incorrect" (at least unexpected) field.