Posted by vele1655 | Posted in Powershell, VDI, View | Posted on 04-02-2012
Who ever said VDI Admins can’t script? Well at this point I can understand why they haven’t even tried. Recently we (EMC vSpecialist rockstars @andreleibovici @chrishorn), and others have been focused on creating a next-gen lab environment and View has been the focal point for what I would term demand management. The core concept that we are working to deliver is essentially “desktop as a service” for lab environments. DaaS in our case is an extreme version where we are second by second removing and adding View desktops into already existing pools linked in a way to an active lab vApp. With this is mind our requirements are pushing the limits of VMware View’s capabilities out of the shoot, so we really had to work overtime on developing methods that allow for the automation of a product with little to no operational hooks.
In previous posts that I have made around VMware View you can see some of this work progressing. The good news is that we have accomplished exactly what we set out for. The bad news is that we have had to go outside the normal acceptable methods that View provides in order to do so. With this as always, what we post if meant for educational purposes and not meant for production environments as it may affect your supportability.
How to Access Windows 2K8 Server via PCoIP with VMware View (@andreleibovici)
Please read on!
The most recent challenge for us has been around how to get proper information for capacity reporting out of View. For example, what we wanted was to be able to see the current desktops in use and available in a certain pool along with the status of agents. Unfortunately, using the current GA VMware View cmdlets there was only information about desktops that hadn’t been added to pools yet. The idea that I sort of got what I wanted provided me some hope so I decided to start digging..
If you are looking for what is currently supported, see Alan Renouf’s site for some previous information that shows the GA cmdlets for View. That native cmdlets have good information, but unfortunately are limited due to lack of remote capabilities (without remoting turned on), don’t receive piped objects in all cases, and are lacking the information we needed.
What I found was very interesting. There are currently three methods that I know of to programatically interface with View. The first being the public supported method of VMware View cmdlets included with a connection server install. The second being an undocumented ability to leverage the message bus locally per VMware View connection server in order to inject commands. And the third being my most favorite undocumented option being leveraging Adobe AMF (action message format) messaging. I continued on this third method and developed a very cool scalable method for anyone to leverage AMF remoting with Powershell.
The AMF method is an awesome way to quickly profile a client GUI and transpose those calls into CLI. See (Powershell and Adobe AMF3). For scripts that I will be linking to at the bottom of this post I used the following method, which you don’t really need to know but cool enough to describe..
- Open Wireshark (configured to sniff SSL)
- Open VMware View Client GUI
- Do an operation
- Grab Hex from Wireshark of HTTP POST (AMF call)
- Deserialize the Hex into a powershell AMF psobject packet (Java Bean, Method, Parameters)
- Export this object as a xml file to be later used (check psobject.xml/ directory)
- Duplicate a generic function in my advanced Powershell functions
- Test and ensure parameters met what was built as expected from template
- Run cmdlet
Anyways, a very cool project that required about 99% of the time in creating an AMF serialization/deserialization process, and the other 1% enjoying the work and creating these “advanced” cmdlets. Consider what is being displayed here as a v1 and a completely read-only version. Who knows, you may see some of this work repeated for other cool things that are Flex/Flash based! And as always hopefully this becomes irrelevant sometimes soon =)
Here are some of the basic specs of what is currently available under the Avanced VMware View Powershell Cmdlets.
- Access View Connection servers remotely (without Powershell remoting)
- Built using Adobe AMF remoting
- All information displayed in View GUI is available
- PowerCLI style connection persistence (Connect-ViewConnServer)
- Currently Read-only access
- Powershell Advanced Functions to create cmdlets (@alanrenouf will be pleased) =)
- Plenty of stuff that isn’t available under the standard VMware View cmdlets
Without further ado, here are the scripts! Most likely the best use case at this point is around generating reports of configuration and reporting on status for services and desktops. Anything is possible since we are now hooked into AMF, but I am still debating outside of the reporting use case what else we need to be able to do via Cmdlets remotely. Making them read-write is all about knowing the java beans, methods, and parameters that are required for posting.
Current Available Cmdlets
Instructions are very simple. Download the zip, unzip ensuring that you keep the xml files in their respective directory, and then run an “import-module uadv_vmware_view.psm1”. From there you have access to all of the cmdlets listed above. You can issue get-help before cmdlets to see the available parameters. For the most part the cmdlets are very bare since we are doing read-only operations and you can manipulate the data after the fact using Powershell standard methods (ft, sort, where, etc).
Begin by issuing a “Connect-ViewConnServer -user administrator -password xx -domain domain -viewConnServer 192.168.1.112” From there you it should look like below, and you should be able to issue a command like “get-Desktops”.
A successful login, and then a get-desktops command formatted as a table.