Microsoft Virtualization Discussions

Get-NaQtree shows wrong OwningVfiler

mark_schuren
3,732 Views

Not sure if anyone else has seen this:

 

When using "qtree status -v" CLI on a 7-mode system I see correct information of which vFiler a specific qtree is belonging to.

 

When using "Get-NaQtree" from the ONTAP PS Toolkit, it does not correctly reflect this, shows "vfiler0" as OwningVfiler for all my qtrees.

 

I've tried with ONTAP PS Toolkit 3.2.0 and 3.2.1 with DOT 8.1.4P8 7-mode and DOT 8.2.3P1 7-mode. Get-NcQtree (cDOT) is showing the vserver properly, but Get-NaQtree does not show correct vFiler!

 

Can anyone confirm this is a bug?

 

Regards,

Mark

1 ACCEPTED SOLUTION

mbeattie
3,705 Views

Hi Mark,

 

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.

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

View solution in original post

2 REPLIES 2

mbeattie
3,706 Views

Hi Mark,

 

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.

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

mark_schuren
3,690 Views

Hi Matt,

 

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.

 

Thanks again,

Mark

 

Public