QueryNetConfig bug?

[jasonrobinson]

Hey guys,

I am calling the QueryNetConfig method on a HostSystem object to determine which vNic is assigned to the mgmt. network. If I connect with my account to vCenter and run the command it works fine. If I connect with a different account (service account in my testing with the exact same privileges and access) I get an error "Permission to perform this operation was denied."

Here is the sample of code I am executing:

(Get-View -Id $VMHost.ConfigManager.VirtualNicManager).QueryNetConfig('management').SelectedVnic

Response: management.key-vim.host.VirtualNic-vmk0

Here are the error details when running the code with different account.

PSMessageDetails :

Exception : System.Management.Automation.MethodInvocationException: Exception calling "QueryNetConfig" with "1" argument(s): "Permission

to perform this operation was denied." ---> VMware.Vim.VimException: Permission to perform this operation was denied. --->

System.ServiceModel.FaultException: Permission to perform this operation was denied.

Server stack trace:

at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)

at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation,

Object[] ins, Object[] outs, TimeSpan timeout)

at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime

operation)

at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at VimApi_65.VimPortType.QueryNetConfig(QueryNetConfigRequest request)

at VMware.Vim.HostVirtualNicManager.QueryNetConfig(String nicType)

--- End of inner exception stack trace ---

at VMware.Vim.HostVirtualNicManager.QueryNetConfig(String nicType)

at CallSite.Target(Closure , CallSite , Object , String )

--- End of inner exception stack trace ---

at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type

typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo)

at CallSite.Target(Closure , CallSite , Object , String )

at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)

at System.Management.Automation.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame)

at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

TargetObject :

CategoryInfo : NotSpecified: (:) [], MethodInvocationException

FullyQualifiedErrorId : VimException

ErrorDetails :

InvocationInfo : System.Management.Automation.InvocationInfo

ScriptStackTrace : at <ScriptBlock>, <No file>: line 1

PipelineIterationInfo : {}

Here are the version details.

C:\temp> get-module vmware* | Select Name, Version

Name Version

---- -------

1. VMware.VimAutomation.Cis.Core 10.0.0.7893915
2. VMware.VimAutomation.Common 10.0.0.7893906
3. VMware.VimAutomation.Core 10.0.0.7893909
4. VMware.VimAutomation.Sdk 10.0.0.7893910

C:\temp> $host

Name : ConsoleHost

Version : 5.1.16299.611

It is occurring on both ESXi 5.5 and 6.0 hosts.

Thanks for any help with this issue.

[LucD · Accepted solution]

Just to make sure, can you run the following to check that the privileges for both accounts are indeed identical?

$esxName = 'MyEsx'

$account1 = 'account1'

$account2 = 'account2'

$vmHost = Get-View -ViewType HostSystem -Filter @{'Name'=$esxName} -Server $global:DefaultVIServer

$si = Get-View ServiceInstance -Server $global:DefaultVIServer

$authMgr = Get-View -Id $si.Content.AuthorizationManager -Server $global:DefaultVIServer

$p1 = $authMgr.FetchUserPrivilegeOnEntities($vmHost.MoRef,$account1)

$p2 = $authMgr.FetchUserPrivilegeOnEntities($vmHost.MoRef,$account2)

Compare-Object -ReferenceObject $p1[0].Privileges -DifferenceObject $p2[0].Privileges

[jasonrobinson]

These are 6.0 vCenters so I don't have the FetchUserPrivilegeOnEntities method available to me. However I was able to use the RetrieveEntityPermissions method and discovered another vCenter role my secondary account was in that was more restrictive. Once I removed it from that role that addressed most of the problem. Sigh...

Thanks for the help Luc!

[LucD]

Oops, I missed that API 6.5 note for the method.

But glad you found the issue.