The standard ways described elsewhere on the web are to use esxtop on a VMHost or resxtop from somewhere with the vCLI installed (press "n" once in [r]esxtop). But, wouldn't it be nice if there was a way without having to enable SSH on a host, or SSH'ing to a vMA appliance (if you do not already have the vCLI installed). Maybe, say, with PowerCLI, which everybody has installed (right?). Oh, wait -- there is: Get-EsxTop.
Here is a function that uses Get-EsxTop to get, for VMs on a VMHost, their vSwitch and vmnic uplink information:
<# .Description Function to retrieve Netports' (portgroup ports') client, uplink info, vSwitch, etc. info. Includes things like VMKernel ports and Management uplinks. Author: vNugglets.com -- Nov 2012 .Outputs PSObject #> function Get-VNUplinkNic { param( ## the VMHost DNS name whose VMs' uplink info to get (not VMHost object name -- so, do not use wildcards) [parameter(Mandatory=$true)][string]$VMHostToCheck_str, ## PSCredential to use for connecting to VMHost; will prompt for credentials if not passed in here [System.Management.Automation.PSCredential]$CredentialForVMHost_cred ) ## end param $strThisVMHostName = $VMHostToCheck_str ## check if VMHost name given is responsive on the network; if not, exit if (-not (Test-Connection -Quiet -Count 3 -ComputerName $strThisVMHostName)) { Write-Warning "VMHost '$strThisVMHostName' not responding on network -- not proceeding"; exit} ## set/get the credential to use for connecting to the VMHost (get if not already passed as param) $credToUseForVMHost = if ($CredentialForVMHost_cred) {$CredentialForVMHost_cred} else {$host.ui.PromptForCredential("Need credentials to connect to VMHost", "Please enter credentials for '$strThisVMHostName'", $null, $null)} ## connect to the given VIServer (VMHost, here) $oVIServer = Connect-VIServer $strThisVMHostName -Credential $credToUseForVMHost ## if connecting to VMHost failed, write warning and exit if (-not $oVIServer) {Write-Warning "Did not connect to VMHost '$strThisVMHostName' -- not proceeding"; exit} ## array with PortID to vSwitch info, for determining vSwitch name from PortID ## get vSwitch ("PortsetName") and PortID info, not grouped $arrNetPortEntries = (Get-EsxTop -Server $strThisVMHostName -TopologyInfo NetPort).Entries ## calculated property for vSwitch name $hshVSwitchInfo = @{n="vSwitch"; e={$oNetportCounterValue = $_; ($arrNetPortEntries | ?{$_.PortId -eq $oNetportCounterValue.PortId}).PortsetName}} ## get the VM, uplink NIC, vSwitch, and VMHost info Get-EsxTop -Server $strThisVMHostName -CounterName NetPort | select @{n="VMName"; e={$_.ClientName}},TeamUplink,$hshVSwitchInfo,@{n="VMHostName"; e={$_.Server.Name}} Disconnect-VIServer $strThisVMHostName -Confirm:$false } ## end function
The comments should pretty much explain what is happening, if it is not already clear. Once you have defined the function, you can use it like:
PS vNuggs:\> Get-VNUplinkNic -VMHostToCheck somehost Need credentials to connect to VMHost Please enter credentials for 'somehost' User: root Password for user root: ************* VMName TeamUplink vSwitch VMHostName ---------- ---------- ------- ---------- Management n/a vSwitch0 somehost vmk1 vmnic0 vSwitch0 somehost vmk0 vmnic0 vSwitch0 somehost dev0-vm0 vmnic0 vSwitch0 somehost dev0-vm12323 vmnic5 vSwitch0 somehost dev0-vm2 vmnic5 vSwitch0 somehost dev0-vm32237 vmnic4 vSwitch1 somehost dev0-vm9 vmnic8 vSwitch1 somehost ...
Pretty handy. And, it does not meet up with the same limitation that you might face with [r]esxtop -- that you can only get uplink info for the top X number of VMs on a host, where X is the number of rows available for display in your console session. So, you can get the uplink info for all VMs on the host. Then, you can sort/filter as needed -- VMs on a given uplink is a nice to know, for example.
There you go: another tasty vNugglet.
Postscript: After writing this function, and in the process of composing this post, I found a VMware Communities thread (http://communities.vmware.com/thread/341604) that does also provide a portion of this goodness, but that thread did not include the cool sauce for getting the vSwitch info -- so, at least that part is new -- yeah-hooey.