The tool from VMware: PowerShell Integration with VMware View -- a PowerShell snapin provided with VMware View.
Some problems:
- must be used on the Broker server on which VMware View Connection Server software is running (local or via PSRemoting)
- slow
- has not been updated since View 4.5 release
- slow!
LDAP and Quest's AD cmdlets? Sounds good.
Overview: by using Quest's Get-QAD* cmdlets and querying the local ADAM database on a Connection Server, most any VMware View info can be had. As for speed -- with the proper planning, the reporting we are doing is far faster than using the standard View cmdlets on a Connection server -- in some cases, an order of magnitude faster, in some cases, an even greater increase! A quick example of the amount of time for getting pools, their template, and their description for an environment with about 75 pools by each method:
using standard View cmdlets on the Broker | about 70 seconds |
querying LDAP to grab the desired info | less than one (1) second! |
Obviously, some serious speed gains to be had. More on those results later.
To dig in: A couple of key organizational units ("OUs") and basic object types/properties that help along the way to being able to mine this info:
Description | Value |
pool objects' OU distinguished name | OU=Applications,DC=vdi,DC=vmware,DC=int |
pool objectClass | pae-DesktopApplication |
pool property that specifies the pae-ServerPool object which contains additional pool settings | <poolObject>.{pae-Servers} |
pool property that specifies the pool's display name | <poolObject>.{pae-DisplayName} |
Further info about row three -- the "pae-ServerPool" LDAP objects hold further info about the actual View pool with which they are associated.
And, so as to show the ADAM DB object types and OUs for some items, I labeled a snippet of a screenshot from the View Admin console:
So, to get some pool info (display name, description, template/parent VM name) for VDI pools using Get-QADObject:
## some juicy properties to retrieve with the pae-ServerPool (Pool additional info) objects $arrIncludedProperties = "pae-DisplayName,description,pae-VmTemplateName,pae-SVIVmParentVM,Name".Split(",") ## use Get-QADObject to connect to the given ADAM instance (on the given Connection Server), retrieve objects and return info Get-QADObject -Service myConnectionServer.domain.com -DontUseDefaultIncludedProperties -IncludedProperties $arrIncludedProperties -LdapFilter "(objectClass=pae-ServerPool)" -SizeLimit 0 | Sort-Object "pae-DisplayName" | Select-Object Name, "pae-SVIVmParentVM"
which returns some info like:
... Name pae-SVIVmParentVM ---- ----------------- testPool /datacenter2/vm/XP/Imgs/templV101 testPool2 /datacenter2/vm/XP/Imgs/4v101 test-2011 /datacenter0/vm/XP/Imgs/hangarV101 jamPool /datacenter0/vm/XP/Imgs/slaughterv101 ...Note: "pae-SVIVmParentVM" is the path to the parent VM for a linked-clone pool
If you are not quite following the -LdapFilter parameter in the code above, it is, as the parameter name suggests, a way to filter the objects returned in the query. In this case, it helps to return just the items that are the "additional info about pools and their settings" objects. A quick but good bit about LDAP query syntax is available in the Search and Compare section about LDAP at wikipedia.org.
Ok, good start. Now, put that into a function, and try a few other calls:
## Script purpose: function to get pool info (display name, description, template/parent VM name) for VDI pools ## Author: vNugglets.com -- Feb 2012 function Get-VNVDIPoolTemplateInfo { #Requires –PsSnapIn Quest.ActiveRoles.ADManagement param ( ## one of the connection servers of the given VDI environment [string]$connectionServerName_str = "someBroker.domain.com" ) ## end param $arrIncludedProperties = "pae-DisplayName,description,pae-VmTemplateName,pae-SVIVmParentVM,Name".Split(",") Get-QADObject -Service $connectionServerName_str -DontUseDefaultIncludedProperties -IncludedProperties $arrIncludedProperties -LdapFilter "(objectClass=pae-ServerPool)" -SizeLimit 0 | Sort-Object "pae-DisplayName" | Select-Object $arrIncludedProperties } ## end fnSome sample usage:
## Gets template-based pools and their description and template info PS C:\> Get-VNVDIPoolTemplateInfo -connectionServer someBroker.domain.com | ?{$_."pae-VmTemplateName"} | select pae-DisplayName,pae-VmTemplateName pae-DisplayName pae-VmTemplateName --------------- ------------------ Sharepoint Crew /datacenter0/vm/XP/Templates/myOldTemplate0 Developer POC /datacenter0/vm/XP/Templates/myTemplate1 ...
## gets VDI pools whose linked clone "parent" property is like "*v101", gives pool ID and the linked clone parent VM info PS C:\> Get-VNVDIPoolTemplateInfo -connectionServer someBroker.domain.com | ?{$_."pae-SVIVmParentVM" -like "*v101"} | select Name,pae-SVIVmParentVM,description Name pae-SVIVmParentVM Description ---- ----------------- ----------- testPool /datacenter2/vm/XP/Imgs/templV101 Temporary testing pool... testPool2 /datacenter2/vm/XP/Imgs/4v101 Old "next-gen" pool for.. ...
As for those speed gains reported above -- part of why querying the LDAP directory (ADAM DB) is soo much faster than the standard View cmdlets is the focus/scope of the queries. Using the View cmdlets pulls back a prescribed amount of data about the objects in question, pools in this example. Cheers to VMware for providing the cmdlets. But, there is some work to be done with them, still. Meanwhile, specifying just the necessary properties/objects/attributes to get the desired info helps keep things fast (FaF). The actual results of the speed tests performed:
## on broker console, native cmdlet PS C:\> Measure-Command {Get-Pool | select pool_id,parentVMPath,description} ... TotalSeconds : 72.4010917 ...
## on remote machine using vNugglets function PS C:\> Measure-Command {Get-VNVDIPoolTemplateInfo -connectionServerName connectionServer.somedomain.com | select Name,pae-SVIVmParentVM,description} ... TotalSeconds : 0.6809141 ...
What's that? 100+ times faster? Nice. Again, the speed gain is thanks to the planning and the upfront cost of writing the specific ADAM queries -- it is not pure magic (just only a little).
And, some of the other places on the web that talk about alternative ways to mine View data (mostly without using [slow] cmdlets local to the View Broker) that may be of interest:
- vElemental: Automating VMware View Pool Membership -- native LDAP
- vElemental: Unofficial Advanced VMware View Powershell Cmdlets -- advanced functions using PowerShell and Adobe AMF ("action message format") messaging; pretty serious
- Clearpath Solutions: Disable VMware View Pool using Powershell PowerCLI -- native LDAP to disable a pool
- vPeeling: Check VMware View pool provisioning status -- native LDAP
- myVirtualCloud: Remote use of VMware.View.Broker PowerCLI -- PSRemoting to a Broker server to use those View cmdlets