Category Archives: PowerCLI

Retrieve CDP/LLDP info

Search for an easy way to get CDP/LLDP info for any given ESXi physical port (vmnic)? Here it is!
It relies on ObnTransformation from my previous post and also depends on PowerShell Community Extensions for ?? alias (Invoke-NullCoalescing). You can replace the latter with the simple if in case you don’t have PSCX installed.
Keep in mind that (some) devices return MAC instead of the management IP in LLDP info.
By default all vmnics are queried.


OBN (Object By Name) transformation

You might have known that most of PowerCLI cmdlets parameters accept objects or object names (with wildcard characters allowed). Take a look at New-VM cmdlet: you can pass strings to VMHost, ResourcePool, Datastore, etc. parameters as well as the objects itself. Or maybe you’ve even never noticed this since it just works!
Want the same behavior for your own functions? No problem! Use the function below to perform transparent transformation from any eligible object to the object you need (View or Impl). The neat feature it has is limiting the retrieved properties for view object, what considerably improves performance in some cases.

This is how to integrate it to your own function:

The one thing you should be aware of is that it accepts wildcards, while you may think the regular expressions are more powerful tool (and I completely agree with you). The reason I had in mind was to not to confuse users who got used to the default PowerCLI behavior. It’s up to you to remove ConvertTo-Regex part from -Filter parameter in Get-View call. But in this case sometimes you might be puzzled when the script can’t find an object with the name you are hundred percent sure exists. Doh! Any braces in the name? Use [regex]::Escape() to escape them.

Restarting managements agents

You know the situation when the host stops reporting its performance counters, do you? CPU and RAM load are showing nils.. A simple two-liner to fix the issue at your disposal:


The power of Get-View

Today we’re going to discover very useful Get-View cmdlet. I’m sure most of you have seen it in many scripts found across the web. This cmdlet returns .NET view objects thus exposing API methods and properties to PowerShell environment. This is crucial in advanced manipulating with vSphere infrastructure.

First it’s worth mentioning that getting implementation objects (those produced by Get-VM, Get-VMHost, etc) takes more time than getting view objects, though in the last versions I found the gap decreased significantly. In fact impl objects are composed of the properties of corresponding view objects.

Let’s discover the available parameters that need to be discussed:

-VIObject, -Id
View object can be retrieved by MoRef (-Id) or by passing the impl object (-VIObject) to cmdlet. Don’t forget to use -Server parameter when retrieving objects by MoRef if you are working with multiple default vCenter servers since MoRef are not unique across different vCenter servers.

This parameter allows you to limit the object properties to be retrieved that can significantly speed up the query execution. Going ahead, one interesting thing you may wonder while using this parameter together with -Filter: does the property that objects are filtered by need to be specified here? The answer is no, they don’t.

This parameter accepts the hash table:
@{Name='^TestVM[1-9]$'; 'Config.Version'='7'; 'Snapshot'=''}
where both keys and values represent the strings and imply that for any object returned every specified key must match the corresponding value. The key can be any nested property but not the property of linked object – for linked objects use -SearchRoot parameter (more on that later). You can use the power of regular expressions for value strings. You may wonder how to test whether the property exists for the object? Just specify this property with the empty value. The example above will filter all vms with name matching ‘TestVM’, hardware version equal to ‘vmx-07’ and for which at least one snapshot exists.
Filtering on the server side prevents the objects that don’t satisfy the specified criteria to be transfered to the client thus it again increases the performance.

Unfortunately cmdlet implementation is missing the list of possible values for this parameter (any reason this can’t be implemented?). You can find out accepted viewtypes by calling Get-View with any incorrect string. Having the list it’s easy to understand which type to use in a query. To learn more about types, inheritance and so on go to API reference guide.

Another really useful objects that can be retrieved by Get-View are different types of managers. The full list can be obtained with ‘(Get-View ServiceInstance).Content’ call.
One can use them to manipulate alarms (Get-View AlarmManager), tasks (Get-View TaskManager), files and so on. So it’s very useful stuff too.

Ok, this part is done. Now let’s explore the base view object.
We have an interesting liaison here: UpdateViewData method and LinkedView property.
Until UpdateViewData is invoked the LinkedView property is empty. Parameters of UpdateViewData invocation are the (multiple) properties of current or linked object you want to obtain. Together with the property name we can specify the property object type. In some cases it’s quite useful to restrict the possible values if the property is the list of object of different types. Let’s see an example because the code is better than thousand words. Consider navigating through inventory folders: every time you want to get the child objects but only those of type ‘Folder’:

The type restriction is neccessary when you specify the property path that include containers and this property doesn’t belong to all entities container can include. Thus
won’t work because folder can include vm objects for which ChildEntity property isn’t defined.

Got it? Then another example of digging even deeper:

So, instead of calling Get-View multiple times leverage UpdateViewData method call. It really accelerates your scripts where you need to get nested view objects.

Now you are aware of the foundation of advanced PowerCLI scripting. Use Get-View in your scripts when processing the bulk of data and the speed is a vital factor.
When operating few objects stay with common impl-getting cmdlets not to loose the simplicity of your scripts.

There is another batch of interesting information I’m ready to share.
Stay tuned!

Fast Suspend/Resume

Have you ever come across the term in subj? It’s time to reveal what it stands for.
First, three examples when this action can be performed.
To enable CBT for virtual machine in addition to make vm reconfiguration one need to perform so called stun/unstun cycle for vm. This could be power on/off, suspend/resume, create/remove snapshot, vm migration.
Another example is changing the build type for running vm (release/debug/stats). This can be done in vm advanced settings tab or via command line utils. In order to BuildType change is applied FSR is performed transparently by the 5.x hypervisor (for ESXi 4.x vm is actually suspended and then resumed).
And the most frequent one is hot-add hardware to vm.
In fact Fast Suspend/Resume equals to migration to the same host – that’s simple.

Below you can find an example of CBT enabling script (most of backup tools enable it automatically).

Esxcli namespace tree

Every time a new ESXi version released I wonder what the functionality was added to esxcli. As you know all available namespaces and commands can be retrieved by typing esxcli command list in the console. To make the output look pretty I’ve written a couple of lines of PoSH code that generates the handy namespaces tree view.

The reason I’ve used the .NET class instead of Add-Content / Out-File cmdlets is that the latter append the new line.
Here is for the latest version 5.5.

VMware UUIDs

Hi everybody! My first post is about UUIDs – identifiers used for virtual machines in vSphere infrastructure. If you ever looked in vm config file (*.vmx) you could see 3 different lines containing 128-bit hex numbers. They are:

  • uuid.bios
  • uuid.location
  • vc.uuid

Because of having some issues with software licensing inside guest OS I decided to explore what the every value is responsible for. Web hasn’t gave me the complete answer about the meaning of all of these parameters so my investigations led me to the following conclusion I’d like to share with you.

uuid.bios – this value acts as GUID analog in physical machine, you should keep it to make the license not to get broken. If you want to export VM, for example using vCenter Converter, and run it in VMware Player/Workstation you should also add the following line to exported vmx file together with copying the source uuid.bios value:
uuid.action = “keep”
It prevents player/workstation from asking whether you moved or copied VM with default answer “I moved it”. If the valid uuid.bios line is present in config file it will be preserved and the software license will be OK. Another option for uuid.action is “change”. In this case VMware will generate the value when you power on VM in new location (host or even folder). You can read this KB article to learn more about it. So the uuid.bios setting is done. Let’s look through others two.

uuid.location is generated every time VM is vMotion’ed to another host/storage. I guess it’s used by vCenter for some internal purposes like ..

vc.uuid is used by vCenter to identify VM together with MoRef ID you’ve seen while working with PowerCLI. It’s unique and is generated when you add VM to inventory (or create VM). If the value is already present in config file (and there is no duplicate in current inventory) it’s left intact.

That’s enough for the first post. In the end – a little piece of PowerShell code to automate the postprocessing of exported VM to ensure its uuid.bios value is the same as source vm’s. It guarantees the persistence of all licenses that depends on GUID.

Hope you’ll find it useful. Stay tuned, keep learning!