Everyone cheered when we released an updated Onyx fling that allowed users to finally record their actions in the vSphere Web Client. (you can read about what Onyx for the Web Client is, and how to install it here: https://blogs.vmware.com/PowerCLI/2015/07/new-fling-onyx-web-client.html).
Category Archives: Extensions
VMware Instant Clone is now at your fingertips with the updated PowerCLI Extensions fling!
At VMware we are pleased to announce the publishing of a new fling: PowerCLI Extensions! PowerCLI Extensions gives PowerCLI users access to early access functionality by extending the core PowerCLI cmdlets to include new experimental features and gives PowerCLI customers the ability to provide early feedback. So what is included in this fling? Read on…
New Fling: Onyx for the Web Client
I am pleased to announce that we have just released Onyx for the Web Client! Continue reading
Get-View Part 3: Peformance Impact – Is it really THAT much different?
In Get-View Part 1: Introduction I introduced the advanced feature Get-View and a little bit about what it does. In Get-View Part 2: Views and Extension Data I talked about how we can interact with the data found in Get-View and the ways we can grab that information. In Part 3, we discuss performance and speed…
Continue reading
Good News! PowerActions 1.5.0 is now available for vSphere 6.0 Web Client
I am happy to announce that the very popular fling ‘PowerActions for vSphere Web Client’ is now available for vSphere 6!
What’s New Continue reading
New VMware Fling: Introducing PowerActions for vSphere Web Client
I am happy to announce a new fling ‘PowerActions for vSphere Web Client’ PowerActions integrates the vSphere Web Client and PowerCLI to provide complex automation solutions from within the standard vSphere management client. In short, we can now run PowerShell/PowerCLI scripts from the Web Client!
How does it work?
PowerActions is a Continue reading
VSAN and vSphere Flash Read Cache cmdlets
Today a new VMware fling has been released, and it’s fantastic! By now I am sure you have probably heard all the buzz from VMworld and with the 5.5 release and announced betas. Two of the most talked about technologies are vSphere Flash Read Cache (vFRC) released in the new vSphere 5.5 version and also VSAN which was announced as a beta.
Today a new VMware fling was added to the site called “PowerCLI Extensions” here which allows you to use both VSAN and vFRC from PowerCLI, this gives you the added cmdlets needed in your PowerCLI session to automate two of the latest and greatest features from VMware.
Continue reading
Retrieving vCloud Director VM Hard Disk size
I was asked recently if we were able to retrieve the disk space of a VM in vCloud Director through PowerCLI, on checking this I found that it is not currently part of the CIVM object and also there is currently no Get-HardDisk cmdlet equivalent like in the vSphere snapin.
After looking through the REST API Reference Documentation –> User Operations I found an entry for the VM VirtualHardwareSection and specifically the disks which can be found as can be seen here: GET /vApp/{id}/virtualHardwareSection/disks
The virtualhardwaresection is easily accessed via PowerCLI using the extensiondata property which allows access to the back end API, I could then find my disk properties by filtering on the description of Hard Disk as in the example below:
(Get-VM MyCloudVM).ExtensionData.getvirtualhardwaresection().Item | Where { $_.Description -like “Hard Disk”}
Now I had the hard disk I noticed that part of the information was the capacity as highlighted below:
With this information I could then find the capacity of the disk and add the information I needed into more of a friendly PowerShell property to the Hard Disk object.
So tying this all back together we could easily use the .ExtensionData reference to create our own Advanced PowerShell function to return the hard disk information for any CIVM.
Example
The following shows an example of how to use this new function and the output, this of course can also be used to export into CSV/HTML/Text or any other format PowerShell can be used with, it is also great for reporting on where the disk space in your cloud is being used!
The Code
Function Get-CIVMHardDisk {
Param (
[Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelinebyPropertyName=$True)]
$CIVM
)
Process {
$AllHDD = $CIVM.ExtensionData.getvirtualhardwaresection().Item | Where { $_.Description -like “Hard Disk”}
$HDInfo = @()
Foreach ($HD in $AllHDD) {
$HD | Add-Member -MemberType NoteProperty -Name “Capacity” -Value $HD.HostResource[0].AnyAttr[0].”#text”
$HD | Add-Member -MemberType NoteProperty -Name “VMName” -Value $CIVM.Name
$HDInfo += $HD
}
$HDInfo
}
}
Let’s Make New-VIProperty Easier
New-VIProperty is a powerful PowerCLI cmdlet and it has been a part of the product since PowerCLI version 4.1. Several releases later, we are under the impression that it is still not widely used. If you take a look around the community, it is easy to find scripts which will would be easier to understand and also work faster if they were refactored to use the New-VIProperty cmdlet.
This blog post is not about how New-VIProperty works. There are several great blog posts on the internet which already explain how the cmdlet works and what its benefits are. Some of them are:
- LucD’s blog: Introduction to New-VIProperty – http://www.lucd.info/2010/07/13/powercli-4-1-brings-the-new-viproperty-cmdlet/
- Arnim van Lieshout’s blog: A great blog post about the performance of custom properties created with New-VIProperty – http://www.van-lieshout.com/2010/09/why-new-viproperty-matters/
- Jonathan Medd’s blog: A blog post about New-VIProperty and LucD’s VIProperty module – http://www.jonathanmedd.net/2011/08/using-powercli-viproperties-and-the-viproperty-module.html
- The PowerCLI blog: A blog post which explains in detail what happens under the hood of custom properties – http://blogs.vmware.com/vipowershell/2011/08/ability-to-customize-vi-objects.html
- LucD’s blog (again): A list of useful VI properties (downloadable as a PS module) http://www.lucd.info/viproperties/
We understand that using New-VIProperty is not that easy. There are a lot of things that should be considered when you create a property – the name of the type you want to customize, the name of the API property, etc.
This blog post includes a PS module whose purpose is to make the use of New-VIProperty easier, the module can be downloaded from here.
Once you import this module into your PowerCLI session, you will be able to:
- Benefit from tab-completion for the New-VIProperty cmdlet
- Inspect which types are customizable with New-VIProperty
- Inspect the properties of a particular customizable type in depth
Let’s take a look at the tab-completion feature
We can start creating a new property by entering “New-VIProperty –ObjectType“. Then, if we press the Tab key, we will iterate through the valid values for the ObjectType parameter.
Of course, when we know the first letters of the type we want to customize, we can enter them before pressing the Tab key. In this case, pressing the Tab key will iterate only through the types whose names start with the provided letters.
In the screen above, pressing the Tab key will show types like VirtualMachine, VirtualPortgroup, VirtualSwitch, etc.
If we are creating a value-based property, after the type has been defined, we should specify the API property with the –ValueFromExtensionProperty parameter. Now this is much easier using tab-completion.
So the type is VirtualMachine, and let’s say we want to add ToolsVersion. It is part of the Guest API property. So we can just enter “G” and then press Tab key. This time the tab-completion feature will search for all properties starting with “G” within the VirtualMachine backing API type. The first match is “Guest”.
After that we should add a dot and start pressing Tab until the desired property appears.
The Guest property has several sub-properties and after several hits on the Tab key we will reach the “ToolsVersion” property. The only thing left to do is give our new property a name. We will do this manually.
Tab-completion also works for the –BasedOnExtensionProperty parameter when you are creating a script-based property.
The second enhancement is the ability to retrieve the list of customizable types
The provided PS module exports the Get-VIPropertyValidTypeNames function. By default, it returns the complete list of types which we can customize using New-VIProperty.
Each type is represented by a PSObject with the following properties:
- TypeName – represents the string that New-VIProperty accepts through the ObjectType parameter
- IsManaged – indicates whether the backing API type is managed or not. For more information about managed and data object types, see the vSphere API SDK documentation
- VimTypes – a list of the backing API types. Knowing which is the backing type of a cmdlet type could be useful; for example, we can refer to the vSphere API SDK documentation for a more detailed description of the API type.
The function provides three filter parameters which let you reduce the list of types. Run “Get-Help Get-VIPropertyValidTypeNames” for more information.
The last enhancement is another function named Get-VIPropertyHelperObject.
This function accepts the name of a customizable type and returns a helper PSObject which could be used for:
- Inspecting the backing API type
- Searching API type properties by name
- Creating VI properties easily
Let’s see this in action. Let’s pass VMHost to the function and save the result in the $helper variable.
The structure of the helper object is based on the backing API object. It has the same set of properties, but their purpose is informative. The output of this object looks like this:
At the top we can see the cmdlet type –VMHost – and the backing API type – HostSystem.
The list of all API type properties follows. For each property, the type is also displayed.
A plus symbol in front of the property indicates that it has sub-properties and it is browsable. For example, if you write $helper.Config, you will see all the properties of Config.
The helper object also has a method named SearchProperties. It searches all properties and sub-properties by name.
Let’s assume that we want to add a property to all VMHosts which shows the vendor of the hardware box. We also know that there is a ‘Vendor’ property in the API object, but we are not sure where it is defined, so we can call $helper.SearchProperties(‘Vendor’).
The output contains all properties whose names contain ‘Vendor’. The last one is the property that we’re looking for.
The next step is creating a property and this is really easy with the helper object. The only thing that we have to do is to call this line: $helper.Summary.Hardware.Vendor.CreateValueProperty()
The helper object provides an identical method for each property within the whole structure. This method creates a VI property using the New-VIProperty cmdlet.
We can see that the method first shows the New-VIProperty expression which will be executed. Below this line, you can see the result of running the New-VIProperty cmdlet.
Let’s see the result of our actions:
This method is really useful for an interactive PowerCLI session, but what about if we want to create a VI property within a script. The helper object provides two methods named GetValuePropertyCreationCode and GetScriptPropertyCreationCode.
Both methods build and return a New-VIProperty expression which you can copy, paste and modify in your script.
Three of the methods have a parameter which accepts the name of the new VI property. If it is not specified (as it is not in the examples), a name will be selected automatically.
Summary
In conclusion, this module allows you to:
- Inspect API types easily and search their properties by name
- Create VI properties or generate New-VIProperty expressions to use in a script
- Retrieve the list of customizable types
- Use tab-completion within the New-VIProperty cmdlet
Finally, let’s see where New-VIProperty is applicable and why it is better to use:
- If you have a Select expression using hash table syntax
- Get-X | Select-Object -Property Name,@{Name=”NestedPropertyName”;Expression={<some expression over $_>}}
- If your script needs data from the ExtensionData/View
- foreach ($vm in $vms) { ….. $foo = $vm.ExtensionData.foo …..}
- The code look better
- The scripts are faster
Download
Download the module from here and import it into your session.
What Next?
If you find this module helpful or have any other comments on this feature we would love to hear them, the PowerCLI team at VMware constantly tries to make PowerCLI a better product and a product which is easy to use, let us know what you think of this and if you would like to see things like this backed into the release of PowerCLI.
|
VM Tools and Virtual Hardware Versions
Alan Renouf, Sr Technical Marketing Architect, VMware
After reading Kyle’s post on the ESXi Chronicles blog here (I didn’t know you could do that) I wanted to show how you could gather and also export the Tools and Virtual Hardware Version in PowerCLI, this also allows us to use one of my favorite cmdlets New-VIProperty, a great post on this cmdlet can be found here.
If we look at the object which gets returned back when we use the Get-VM cmdlet you will see that there is a root property for the Name, PowerState, NumCPU and many many more, one of these is the Version, this shows the hardware version so its easy enough to grab each VM’s name and Hardware Version by using:
Get-VM | Select Name, Version
But the returned object doesn’t have a root property for ToolsVersion or ToolsVersionStatus, for this we need to delve into the ExtensionData property and have a look around, once we have found the information it is fairly easy to add these to our object using the New-VIProperty cmdlet as below:
New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine
-ValueFromExtensionProperty 'Config.tools.ToolsVersion'
-Force
New-VIProperty -Name ToolsVersionStatus -ObjectType VirtualMachine
-ValueFromExtensionProperty 'Guest.ToolsVersionStatus'
-Force
Now we have added these as a new property to our object (actually they are PowerShell Code Properties), we can use our old friend Get-VM to retrieve the information easily:
Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus
Of course we can choose which list of VMs to get this information for:
For a Datacenter: Get-Datacenter London | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus
For a cluster: Get-Cluster Production | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus
For a host: Get-VMHost Host1.mydomain.local | Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus
And we can also easily export this information into a csv file:
Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus | Export-Csv -NoTypeInformation -UseCulture -Path C:\Temp\VMHWandToolsInfo.csv