Chapter 9. Managing the vSphere API

So far, we have discussed how to configure and manage different aspects of ESXi and vCenter Server and its peripheral services. We used the cmdlets available in PowerCLI, but the real fun begins now. In this chapter, we will dive into the deep end of the pool and work directly with .NET objects and the vSphere API. It is an amazing way to manage the vSphere world. As we move into the chapter, we will discuss the following topics:

• Using the Get-View cmdlet to return .NET View objects

• Using the ExtensionData property to return .NET View objects

• Using the vSphere API

• Creating a vSphere scheduled task

• Configuring Distributed Power Management

• Configuring Fault Tolerance

• Managing Content Libraries

• Managing SRM advanced configurations

• Generating PowerCLI code using Onyx

• PowerActions for the vSphere Web client

So, let's start the discussion on how we can use the Get-View cmdlet to get .NET View objects.

Using the Get-View cmdlet to return .NET View objects

When we use any cmdlet, it does a lot of background work and provides us nice, formatted output. This has the positive effect of making our life easier and we can be blissfully ignorant of the underlying complexities. But, due to the same reason, it also runs a bit slower and hides a lot of information. If we want to get more information about objects, then we need to use the Get-View cmdlet. For example, let's look at the output of the following two cmdlets:

PS C:\> Get-VMHost -Name ESXi1.lab.com
PS C:\> Get-VMHost -Name ESXi1.lab.com | Get-View

The results of the preceding commands are shown in the following screenshot:

As you can see from the preceding screenshot, Get-View provides much more detailed information than the simple Get-VMHost cmdlet. We can further pinpoint the data that we are looking for by using the –ViewType and –Filter parameters. The ViewType parameter lets us select the data for a particular type of object...

Using the ExtensionData property to return .NET View objects

In the previous section, we saw how to access minute details of the objects using the Get-View cmdlet. We can do the same without using the Get-View cmdlet as well. The magic property is ExtensionData. By using this property, we can access the details of an object. Let's examine this in more detail. First, we will get the information of a host and store it in a variable:

PS C:\> $hostInfo = Get-VMHost -Name ESXi1.lab.com

The result of the preceding command is shown in the following screenshot:

Now, let's add the ExtensionData parameter to the variable $hostInfo:

As we can see, it provides the exact same information that we got earlier by using the Get-View cmdlet.

PS C:\> $hostInfo.ExtensionData.Hardware.CpuInfo

NumCpuPackages NumCpuCores NumCpuThreads         Hz
-------------- ----------- -------------         --
             4           4             4 3392312000

For rest of the operations, we can do what we did earlier...

Using the vSphere API

Before we move ahead and talk about performing various tasks using vSphere APIs, let's first see how we can utilize them to our advantage. The vSphere API reference is available at vSphere 6.0 Documentation Center (http://pubs.vmware.com/vsphere-60/index.jsp). On the documentation page, you need to go to vSphere API/SDK Documentation | vSphere Management SDK | vSphere Web Services SDK Documentation | VMware vSphere API Reference:

If you look closely, you will see that there are different types of Object categories available:

• Managed Object types: This is a core data structure of the server-side object model. Instances of various managed object types are referred to generically as managed objects.

• Data Object types: This is a core data structure of the server-side object model. Data objects are similar to abstract data types (in Java) and the struct data type (in C++). The VMware vSphere management object model uses basic object-oriented features, such as composition...

Creating a vSphere scheduled task

In this section, we will discuss ways in which we can create a vSphere scheduled task using the vSphere API through PowerCLI. For this, we will use the ServiceInstance managed object. This is the singleton root object in the inventory.

Note

For more details, please check the vSphere API documentation at Managed Object Types | ServiceInstance (http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.wssdk.apiref.doc/vim.ServiceInstance.html).

To create a scheduled task, we will use the CreateScheduledTask method. If we examine the method, we can see that this method takes two inputs: an entity (MoRef) and a specification (ScheduledTaskSpec).

To create a task, we need to create a scheduled task specification. This in turn takes six different inputs:

The rest of the values are static but notice action and scheduler. These need to be defined as objects. Note that we defined an Action, which in turn calls the CreateSnapshot_Task method to create the snapshot. As the...

Configuring Distributed Power Management

Next, we will configure Distributed Power Management using the vSphere API and PowerCLI. To achieve this, we will use the ReconfigureComputeResource_Task method, which is defined under the All Methods section in VMware vSphere API documentation.

On further inspection, we can see that this method takes two inputs. First, a set of configuration changes to apply to the compute resource in the form of ComputeResourceConfigSpec specification. If we check ComputeResourceConfigSpec, further we can see that we can extend its use to the ClusterConfigSpecEx data object that has the properties that can configure the services listed here:

• High Availability (HA)

• Distributed Resource Scheduling (DRS)

• Distributed Power Management (DPM)

• VSAN

We can see that we can use the following properties:

• dasConfig

• dasVmConfigSpec

• dpmConfig

• dpmHostConfigSpec

• drsConfig

• drsVmConfigSpec

• groupSpec

• rulesSpec

• vsanConfig

• vsanHostConfigSpec

The property that we need to use and...

Configuring Fault Tolerance

In this section, we will discuss how we can use vSphere API's to configure FT through PowerCLI. For this, let's explore the methods and properties that we need to access.

If we access the APIs, we can see that there are two methods, CreateSecondaryVMEx_Task and CreateSecondaryVM_Task, which we can use to configure Fault Tolerance (FT). If we check, we can see that CreateSecondaryVM_Task is the deprecated method. So for this example, we will use the CreateSecondaryVMEx_Task method.

If we check the CreateSecondaryVMEX_Task method, we can see that it takes two different parameters, host and spec. The host parameter is for specifying a host system where the secondary VM should be placed, and spec is a Data Object of type FaultToleranceVMConfigSpec and is used for specifying the values for fault tolerance VM configuration. If we check, we can see that it takes two parameters: disks of type FaultToleranceDiskSpec and vmConfig of type ManagedObjectReference to a datastore...

Managing Content Libraries

In this section, we will discuss how we can utilize the vCloud Suite SDK and combine it with the vCenter Server APIs to manage a content library in vCenter Server. To do this, first we need to import the module VMware.VimAutomation.Cis.Core. We can check the cmdlets available with this module by running the following command:

PS C:\> Get-Command -Module VMware.VimAutomation.Cis.Core | Select Name

Name                
----                
Connect-CisServer   
Disconnect-CisServer
Get-CisService

So let's first connect to the vCloud Suite SDK server:

To get a list of all the services available and their description, run the cmdlet Get-CisService:

$Library = Get-CisService com.vmware.content.local_library

The result of the preceding command is shown in the following screenshot:

As you can see from the description in the screenshot, this service manages the local libraries. So, we will use this service to manage the content library.

To get a list of available libraries...

Managing SRM advanced configurations

In this section, we will discuss how to manage SRM through APIs. To manage a SRM server, we first need to connect to vCenter Server. Once we are connected to vCenter Server, we can connect to the SRM server using the following cmdlet:

PS C:\ $SrmServer = Connect-SrmServer

To access the SRM APIs, we can use the following command:

PS C:\ $SrmApi = $SrmServer.ExtensionData
PS C:\ > $SrmApi |FL

Content    : VMware.VimAutomation.Srm.Views.SrmServiceInstanceContent
Recovery   : VMware.VimAutomation.Srm.Views.SrmRecovery
Protection : VMware.VimAutomation.Srm.Views.SrmProtection
MoRef      : SrmServiceInstance-SrmServiceInstance

As you can see from the preceding example, the SRM APIs are divided into three groups: Content, Recovery, and Protection.

To check what is available under Protection, we can use the following command:

PS C:\Users\administrator.SPWSVCD1> $SrmApi.Protection | Get-Member | Select Name

Name                           
----         ...

Generating PowerCLI code using Onyx

Onyx is a very useful fling that we could use with the C# client to record the actions taken in the client and generate equivalent PowerCLI .NET code. It is a script recorder that sits between vSphere Client and vCenter Server, and it records what scripts were called whenever you do something within the C# Client. It can output the scripts as raw SOAP messages, C#, and vCO (or vRO) JavaScript code.

vSphere 5.5 Web Client has become the main focus for managing vSphere environment and supports many features that are not available in C# client. Now, we have an updated fling, Onyx for the Web Client, that supports Web Client operations. This version translates actions taken in the vSphere Web Client to PowerCLI .NET code. The resulting code can then be used to understand how VMware performs an action in the API and also better define functions. You can download the fling from https://labs.vmware.com/flings/onyx-for-the-web-client.

There's an excellent blog written...

PowerActions for vSphere Web Client

The last topic of this chapter is PowerActions for vSphere Web Client. This is an amazing fling that integrates the vSphere Web Client and PowerCLI to provide complex automation solutions from within the standard vSphere Web Client.

This is actually deployed as a plugin for the vSphere Web Client and allows the end users access to PowerCLI commands and scripts in the vSphere Web Client integrated PowerShell Console. In addition to that, this enables the users to right-click on entity in Web Client and run a script against that entity. Sounds amazing, right? Also, Mac and Linux users get the PowerShell console from their environment directly.

The fling can be installed from https://labs.vmware.com/flings/poweractions-for-vsphere-web-client. The prerequisites for this fling installation are as follows:

• VMware vSphere 5.1 to 6.0 (earlier than 5.1 has not been tested)

• PowerShell host machine

• Windows 2003 Server or newer

• .NET 4.0 or 4.5

• PowerShell v1, v2, v3, or v4...

Summary

In this chapter, we discussed vSphere APIs and how we can utilize those APIs through PowerCLI to achieve tasks for which there are no direct cmdlets. It is an amazing tool and needs further exploration to achieve tasks which are not possible in the normal way.

In the next chapter, we will discuss REST APIs and how we can utilize them to achieve different tasks in the VMware environment, specifically in vRealize Automation environments.