Its probably not news to you that VMware have now released View 4.5, just one of the many cool announcements made at VMworld 2010 – San Francisco.
Did you know however that View now has some PowerShell cmdlets ? – Yeah that’s right.
I think its great that VMware are putting so much time and effort into PowerShell and giving windows admins a great tool to manage their VMware infrastructure with, one thing I always tell anyone who will listen is that PowerShell is “the glue” that sits in between your applications to enable a common programmatic interface allowing you to glue all these applications together to give you the end results you need, whether it be deploying a VM and then installing Windows and then installing Exchange and then following on to add the mailboxes and patch the server and even send you an email at the end to say its done or simply just adding an “A host” record to a DNS server for a VMHost after installing ESX and patching the host using the Update manager cmdlets.
The possibilities are endless, well as endless as your imagination !
So yes, the point here is that its a great thing that VMware continue to add PowerShell enablement to their apps giving us the freedom to automate them.
With View 4.5 we are given 45 cmdlets to manage our View environment, these are listed below:
|Adds an automatically provisioned linked-clone pool.
|Adds an automatically provisioned full clone pool.
|Creates a manually provisioned pool of managed desktops.
|Creates a manually provisioned pool of unmanaged machines.
|Entitles one or more users or groups to a pool.
|Creates a pool with Terminal Servers as source.
|Adds a vCenter server to View.
|Returns a list of all View Composer Domains in this View environment.
|Returns a list of Connection Servers and Security Servers in this View environment.
|Returns a list of physical machines suitable for unmanaged pools that have been registered with a connection server in this environment.
|Returns a list of managed Virtual Machines across all vCenter servers that are registered to this View environment.
|Returns a View Event report that consists of a list of Events.
|Returns a list of Event Report names and their descriptions.
|Returns Global View Configuration.
|Returns details of the current View license.
|Returns a list of local desktop sessions.
|Returns a list of infrastructure health monitors and their current contents.
|Returns a list of Pools in this View environment
|Returns a list of user or group entitlements to pools.
|Returns a list of persistent disks.
|Returns a list of active remote sessions.
|Returns a list of terminal servers that have been registered with a connection server in this environment.
|Returns a list of Active Directory users or groups.
|Returns a list of vCenter servers in this View environment.
|Removes a desktop pool from View.
|Unentitles one or more users from a pool.
|Removes any user ownership of a particular desktop.
|Removes a vCenter Server from this View environment
|Rebalances linked-clone desktops in a linked-clone pool.
|Recomposes linked-clone desktops in a linked-clone pool.
|Refreshes linked-clone desktops in a linked-clone pool.
|Rolls back a local desktop session.
|Sends a disconnect request for an active remote session.
|Sends a log off request for an active remote session.
|Sends a reset request for a Virtual Machine.
|Sets the View license key.
|Updates an automatically provisioned linked-clone pool.
|Updates an automatically provisioned, full clone pool.
|Updates settings for a connection server or security server.
|Updates Global View Configuration.
|Updates configuration of a manually provisioned pool.
|Updates a manually provisioned pool.
|Updates a pool which has Terminal Servers as source.
|Assigns a desktop to an Active Directory user.
|Updates settings in View for a vCenter server.
This is great news, as you can see from the above, there are some useful cmdlets in here which will help us manage our pools, desktops and users.
I already have some scripts in mind, a view audit script, a visio diagram of your view infrastructure etc etc.
But its not all good…….
Rant 1 – PowerCLI Integration (or lack of)
When using these cmdlets it has become clear that the PowerCLI team who did such a great job with the PowerCLI cmdlets and the Update manager cmdlets were not responsible for creating these cmdlets, unfortunately a lot of the good work they have put into PowerCLI has not been transferred over to the View cmdlets, for example, take a look at the below example of how to create a pool:
Get-ViewVC | Select -first 1 | Add-AutomaticPool -pool_id SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -namePrefix "salesdesktop" -vmFolderPath "/DC01/vm/VDI/Test" -resourcePoolPath "/DC01/host/CLUSTER01/Resources/VDI" -dataStorePaths "/DC01/host/CLUSTER01/ix2-ISCSI-300GB" -templatePath "/DC01/vm/Templates/2008 STD"
What I would have expected to use if these were integrated with PowerCLI is the following:
Get-ViewVC | Select -first 1 | Add-AutomaticPool -poolid SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -namePrefix "salesdesktop" –vmFolder (Get-Folder “Test”) –resourcePool (Get-ResourcePool "VDI") -dataStore (Get-Datastore “ix2*”) -template (Get-Template “2008 STD”)
Or even in the latest release of PowerCLI you no longer need to use the cmdlets to get the objects in the code, so the code would be shortened to something even easier:
Get-ViewVC | Select -first 1 | Add-AutomaticPool -poolid SalesGroupWin7 -displayName "Sales Windows 7 Desktop" -namePrefix "salesdesktop" –vmFolder “Test” –resourcePool "VDI" -dataStore “ix2*” -template “2008 STD”
Rant 2 – Where is the help ?
Where is the help that we are used to ?
If you do a get-help on a cmdlet in PowerCLI you are given detailed information about what parameters are required for that cmdlet to work, the help files are full and detailed, they contain example code to help you quickly learn and use the cmdlets……what about the View cmdlets ?
You get very basic information, you will not see the same level of detail, only the basic information is in there and there are no examples…… no examples ?! What the heck, I use these all the time, one of the key ways to learn in my mind is to use the Get-Help Get-ViewVC –example and see how it should be done.
Ok, granted there is some examples in the “VMware View Integration Guide” but do I really have to switch to the PDF every time I want help ? – Come on !
Rant 3 – Required Parameters
Normally when you run one of the PowerCLI cmdlets and don’t give it a parameter which is required it will ask you for it, unfortunately this has also not been passed over to the View cmdlets.
One of the great things about PowerCLI is that you can use it anywhere, some of my scripts are quite CPU intensive, analysing the data and manipulating it before using it to perform more actions with it, this is handy as you can run the script on your workstation ensuring you are not causing issues to anyone else, this is not the case if you install PowerCLI on a server, you could accidentally starve the server of resources temporarily whilst you run the script, even more of an issue if the server is a VM !
Unfortunately the View cmdlets can only be used on the View server itself, the cmdlets do not come as a separate MSI file, they are pre-installed as part of View 4.5 and can not be installed on your workstation, there is no Connect-ViewServer cmdlet. Yes you can probably use PowerShell V2’s remoting features to import the session and use the cmdlets that way (I havent tested this but it should work) but this wont take away the resource issues.
I think its great that VMware continue to add PowerShell functionality to their product range and I would love to see more of this, its a great technology and the recent PowerCLI session at VMworld showed how popular it actually is – 3 sessions and over 1000 attendees !
I think its a real shame that the View cmdlets were not integrated into the PowerCLI cmdlets, they PowerCLI team did a great job with these cmdlets, so much so that the creator of PowerShell (Jeffrey Snover) actually visited VMworld this year to find out what all the fuss was about with VMware and Powershell.
Hopefully there will be an update to these cmdlets soon fixing some of these issues and bringing the functionality back to what we are used to from VMware PowerShell products, in the mean time should it really be called View PowerCLI or just plain PowerShell for View ?