Author Archives: Pavel Dimitrov

Optimize the performance of PowerCLI’s views

Until now, UpdateViewData() enabled you to update the whole view or specified view property. If you wanted to retrieve some nested view, you needed to call Get-View again. And if the view you needed was somewhere deeper in the hierarchy, you needed to call Get-View multiple times.

Let’s say for example that you have the VM folder view and you need the VM network of all your virtual machines. What you had to do until now is something like this:

    $vmViewList = Get-View $vmFolderView.ChildEntity | Where {$_ -is [VMWare.Vim.VirtualMachine]}
    $vmNetworkList = Get-View ($vmViewList | % {$_.Network})

Now you can do the same thing in significantly more convenient way:


The above line updates the VM folder view in such way that it contains the desired VM network views. The property path parameter of UpdateViewData states that we request only the virtual machine child entities of the VM folder (VM folder may contain other nested folders) and for all those virtual machines we want their networks. When you browse the VM folder view after this call, you’ll notice that a new property has appeared – LinkedView. Inside this property you’ll see record for each nested view of the VM folder, but only the requested ChildEntity is populated – all virtual machines situated directly in the VM folder are available there. Each ChildEntity also contains LinkedView where only the virtual machine network is populated. In other words, the network of the first virtual machine can be accessed like this:


So what is the big deal with this new feature?

The most obvious answer is that the code is much shorter and readable. The filtering of the folder child entities is specified in the property path parameter of UpdateViewData method, rather than performing it manually.

If you execute both commands against well loaded VC, you’ll also notice the difference in the execution time. Using Measure-Command on my environment with about 500 virtual machines I measured significant difference: about 300 milliseconds for the UpdateViewData call and about 30 seconds, using the multiple Get-View call approach.

There are some more things to mention:

When specifying property paths that include containers, which can hold more than one entity type, and require some property which does not belong to all supported entity types of this container, you should explicitly describe the type of the retrieved container entities. Otherwise you’ll get an error:

    Exception calling "UpdateViewData" with "1" argument(s): "The specified path is not correct. Element 'childEntity' doesn't exist."
    At line:1 char:19
    + $fv.UpdateViewData <<<< ("ChildEntity.ChildEntity.*")
        + CategoryInfo          : NotSpecified: (:) [],     MethodInvocationException
        + FullyQualifiedErrorId : DotNetMethodException

The reason for the error is that the child entity of the folder may be either another folder or virtual machine and the virtual machine does not have ChildEntity property.

There’s no problem to specify more than one property path, populating in such way the needed linked views with a single call:

    $vmFolderView.UpdateViewData(“[VirtualMachine]ChildEntity.Network.*”, "[Folder]ChildEntity.Name")

The same approach can be used directly with Get-View like this:

    $vmFolder | Get-View -Property "[VirtualMachine]ChildEntity.Network.*"


ESXCLI now available through PowerCLI

I’ll illustrate esxcli in PowerCLI with an example of how path selection policy can be set for specific storage array type plugin. As you may know, until now this action could be performed by the esxcli command line tool and the call would look something like:

    esxcli nmp satp setdefaultpsp -psp VMW_PSP_RR -satp VMW_SATP_SYMM

From this release the esxcli functionality is available directly through the PowerCLI. The only thing you have to do is to retrieve an EsxCli instance and then invoke any of its methods. So it will look like:

    $esxCli = Get-EsxCli –Server $myEsxConnection

    $esxCli.nmp.satp.setdefaultpsp(“VMW_PSP_RR”, “VMW_SATP_SYMM”)

Note that you have to be connected directly to your ESX, in order to retrieve EsxCli instance (It won’t work with VMHost instances, retrieved from a VC).

In the esxcli tool you have applications, which are grouped in namespaces. Those applications have commands. The same organization is preserved in PowerCLI – The EsxCli object contains the namespaces as properties. The namespace objects contain the applications as properties and finally the commands are methods of those application objects. It’s quite easy to get help for those methods. What you have to do is to call help method for some application object, specifying the name of the desired command method:


You can also retrieve help for the entire application:


Note that this feature is experimental. This means that in future releases backward compatibility is not guarantied.

If you’d like to take a deeper look in the PowerCLI’s esxcli interface, you can read this article: ESXCLI in PowerCLI – overview

vDS in PowerCLI 4.1

At last vDS features are here with the new PowerCLI . The vSphere PowerCLI 4.1 release is the first touch of PowerCLI with vNetwork distributed switches, so please don’t expect to find fully supported vDS functionality in it. Still as you probably know, the Get-View cmdlet provides an opportunity to add extra functionality to your PowerCLI scripts. What you’re going to find in this post is how to create virtual network adapters on vDS and how to move VMs in and out of a vDS. At the bottom you can find a sample function that creates vDS.

When you have your vDS ready, you can create your virtual network adapters there. What you have to know is the name of the vDS and the name of the port group that you’re going to use. The line below will create VMKernel adapter with DHCP settings on the specified vDS and port group:

New-VMHostNetworkAdapter -VMHost $myHost -VirtualSwitch “myVDS”-PortGroup “dvPortGroup”


You can move VMs in and out of a vDS. Again, the only thing you have to know is the name of the port group:

$vm | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName “vdPortGroup”

On the same principle you can create new network adapters directly on your vDS:

New-NetworkAdapter -VM $vm -NetworkName “vdPortGroup”

And you can directly create VM, specifying its network adapter, to be on vDS network:

New-VM -Name “myVM” -VMHost $myHost -DiskMB 10240 -NetworkName “vdPortGroup”

The sample function below creates vDS, using the vSphere SDK for .Net. First, the function creates DVSCreateSpec, where vDS name and uplink port names are populated (Note that the name of the class matches the previous name of the vDS – “distributed virtual switches”, instead of “vNetwork distributed switches”. So don’t be confused of that ). Then the function creates DistributedVirtualSwitchHostMemberConfigSpec, where it populates the host(s), which will be added to the vDS. For the example I am adding a single ESX host, but you can modify the function to add a collection of hosts. For the added hosts, the function specifies the physical network adapter ID, which will be used for the connection to the vDS, which is done by adding DistributedVirtualSwitchHostMemberPnicSpec. Next, the function creates the vDS using CreateDVS method of the network folder view. Then the function creates DVPortgroupConfigSpec and adds a port group using the AddDVPortgroup method of the vDS view. Finally the function returns the managed object reference of the vDS.




Having the vDS managed object reference, later we can delete the vDS:

$vdsView = Get-View -Id $vdsMoRef


One thing you have to remember is that you won’t be able to remove your vDS until there are virtual adapters available there.

I hope that you’ll find this post somehow helpful and that it will make you feel a little bit more comfortable, when working with vNetwork distributed switches .