vElemental

Before I begin this post I want to make sure there is a pretty sharp warning attached.  What I am going to be discussing is a method in which you can programmatically adjust the members of VMware View Pools.  As far as I know this functionality does not exist via Powershell cmdlets or via a published API.  The methods in which I accomplish this task should serve solely as an example and for lab use only.  As always I hope the concept in practice can drive open some doors that previously were closed.  However, consider this method a complete divergence to existing VMware View managed desktops.

Now to continue the post.  The use cases here are interesting.  I have my own personal reasons for creating this functionality and you might have your own, so I am interested to hear your feedback since it would make the case stronger to release this through a published API. 

One of the first use cases I can provide would have to do with leveraging array based snapshots (NFS or block) and publish these new desktops to a specific pool.  This use case is very similar to what VMware View accomplishes today with composer and desktop refreshes/recomposes.  However, instead of linked clones we would be off-loading these tasks to the storage array for creating efficient linked virtual disks that serve as fresh desktops.  There are other things that Composer brings to the table which I am ignoring for this post (more to come).

A second use case I can think of would fall in the domain of Deskop as a Service offerings.  In order to keep efficient levels of desktops of certain types available at all times the current option is to over-provision and add desktops manually when the time comes for their demand.  Leveraging automation to dynamically adjust types of desktops would allow for the most efficient DaaS environment.

The third use case I can highlight I need to be a bit silent about since it is something that is an ongoing project.  I’m afraid you are going to have to wait for this one, but no doubt it will be worth it.  Let’s just say I am able to link VMware View with another VMware product using this method which traditionally would require some complicated databases to track the relationships.

Ok, so enough of the use cases, let’s dive into the details. 

We will be splitting the post up as follows.

• VMware View 5.0 Configuration Database (LDAP)
• Script in Action (custom_vmware_view.ps1)

VMware View Configuration Database (LDAP)

Before diving into the details it is important to understand some of the basics behind how the View Connection brokers maintain their configuration.  As far as I can tell there is only one area that I have found that holds configuration information.  This being an LDAP database on the View Connection brokers.  I hadn’t leveraged LDAP as a replicated database prior but after digging deeply into how LDAP here is used it is a very simple and cool use case.  One of the big benefits of using LDAP is the ability to leverage Microsoft ADAM to perform synchronization among multiple connection brokers to allow for front end redundancy. 

One of the great things about this approach is also the simplicity behind the user interface and the possibilities of manipulating this data.  Before the scripted manipulation portion, let’s dig into the manual methods to see and possibly manipulate the database. 

*Again, what you are seeing below is absolutely not supported by EMC or VMware.  I do not condone the use of what you are going to see other than for informational and educational purposes.*

This method is highly documented across the internet, so nothing new here.  Let’s start by opening an LDAP browser that comes with Microsoft Server 2008.  Go to Start –> Run and type “ADSI edit”.  It should show up in the top left corner of the start menu as follows.

In order to open the connection you need to specify a “Distinguished Name” and a Computer as a target.  The distinguished name should be exactly as follows “dc=vdi,dc=vmware,dc=int”.  The domain or server should be the IP or hostname of the connection broker.  If there are problems connecting, make sure you are opening the ADSI Edit application with administrator access to the VIew Connection broker server. 

Once you connect you should see the following screen with “Default naming context” appear.  Go ahead and double click this item, and then the “DC=vdi,DC=vmware,DC=int” should appear.  From there you should be able to expand this and start diggging through the Computer Names and Organizational Units.  Some of the important ones that we will be working with are “Servers” which are the desktops, and “Server Groups” which are the Desktop Pools.  You will find that navigating through the information and finding what you’re looking for under servers might be a bit complex due to how this is organized.

Just for quick reference, one thing that I’ve found in trying to automate the install of the VMware View agent is that it is easy to verify whether the agent is configured correctly or not by viewing the Agent’s registry settings from the desktop.  Go ahead and open up a desktop and open regedit to the following key HKEY_LOCAL_MACHINE –> Software –> VMware, Inc. –> VMware VDM –> Node Manager.  Notice the Server DN, and the Server Pool DN.  These link directly to what you see in the View LDAP database above.

Ok, so as you can see we have a working database via LDAP for the View Connection Broker.  In order to start populating pools dynamically there is a attribute under the “Server Groups” (pools) OU that specifies which desktops Computer Names are a part of the pool.  This is the attribute that we will be manipulating to dynamically bring in and remove desktops from pools.

The Script in Action

Now let’s start digging into the script and what we are achieving with it.  From what you saw above and what I experienced in digging into this topic it was pretty clear that we needed a script to assist in browsing the View LDAP database which then helps us manipulate it as well. 

Before getting too deep, here is the script..  By downloading you agree that this script is for educational and non-production environments and that the use of scripts will most likely lead to support problems.

In order to leverage the different built in functionality you can leverage the different actions that we have created functions for.

Action – View-Get-Objects – Get all objects from a specified OU or CN

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -cn roles

As you can see we are adding a “ | select -first 1” on the end of the first example above which returns only the first desktop.  One of the great things about the script is that we are outputting all of the information as properly formatted Powershell objects which means we can leverage native cmdlets like Group and Sort.

The following example will show you the amount of desktops in each type of pool.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers | select “pae-DisplayName”,”pae-MemberDnOf” | group “pae-MemberDNof”

The following will show the desktops within the first pool.  You can switch out the “select –first 1”, with “where {$_.name -match “poolname”}” to pick a certain lab.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action view-get-objects -ou servers | select “pae-DisplayName”,”pae-MemberDnOf” | group “pae-MemberDNof” | select –first 1 | %{ $_.group | select “pae-DisplayName” }

As you can see below, we substituted the “servers” for “server groups” as the OU parameter and got the desktop pools.  This will work for anything you see in ADSI edit that shows up as an OU, and you can specify CN as a parameter for things in the top level that show up as a CN.

Action – View-Get-Object – Get a specific object

This action is actually called by the next action we are going to specify.  There are three parameters which I can try and write out here to have it make more sense.  In order to get an object we specify the OU in which it lives, we then specify a where clause based on a field and the value is what is contained in that field.

Action – View-Get-Desktop – Get a specific desktop

We call the View-Get-Object here with the following parameters ($ou = “servers”, $field=”pae-DisplayName”,$value=”desktop name”).  The parameter you specify with this action is the “name”. 

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Get-Desktop –name desktopName | fl *

Action – View-Remove-Desktop – Remove Desktop from Pool

In order to get the desktop out of a pool we actually execute the above actions behind the scenes.  First we get the desktop CN you are looking for, then we find the pool CN.  This is followed by manipulating the pae-MemberDNof to exlude the CN of the desktop specified.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Remove-Desktop -name desktopName

Action – View-Add-Desktop – Add Desktop to Pool

This action behind the scenes is very similar to the remove.  However, instead of removing from the pae-MemberDNof, we add it to groups of desktop CNs in that attribute.

.\custom_vmware_view_ps.ps1 -username username -password passsword -viewConnBroker viewConnBroker -action View-Add-Desktop -name desktopName -pool poolName

That’s all for now!  I am interested to hear some use cases so we can fully understand the usefulness of this type of functionality.  Feel free to add comments.

Download the script here.  By downloading you agree that this script is for educational and non-production environments and that the use of scripts will most likely lead to support problems.