Home > Blogs > VMware PowerCLI Blog > Monthly Archives: December 2018

Monthly Archives: December 2018

Getting Started with Desired State Configuration Resources for VMware

Today, we are happy to announce a brand-new and open-sourced way to manage your vSphere environment. The Desired State Configuration (DSC) Resources for VMware allows partners, automation engineers, DevOps teams, and system administrators a new way to apply standard configuration management processes through PowerShell DSC and PowerCLI!

Let’s take a walk through how we can get started using these DSC resources and apply our first configuration!

Desired State Configuration Resources for VMware Overview

PowerShell DSC has been out for a while, since Windows Server 2012 R2 as a matter of fact. To summarize in a single sentence: PowerShell DSC can manage and monitor a system’s configuration based on what’s known as configuration files, which happen to be written as PowerShell code. This is all made possible thanks to the Local Configuration Manager (LCM). LCM is the “engine” running locally on each of the target nodes that takes the configuration file, interprets it, and applies all the configured parts. These parts include a system’s configuration, in what manner the configuration is refreshed, and how often it is refreshed, just to name a few.

The above is important because the DSC Resources for VMware operate a little differently than a standard DSC configuration. The DSC Resources for VMware make use of a proxy LCM host. This is because the LCM cannot run on the VCSA (both vCenter and PSC based appliances) nor can it run on ESXi hosts. An important note about this proxy LCM host, it has to be Windows PowerShell based. Furthermore, only PowerShell 5.1 and PowerCLI 10.1.1 or newer will be supported.

Desired State Configuration Resources for VMware

This first release of the DSC Resources for VMware will be able to manage a couple different areas for both vCenter and ESXi hosts. They are as follows:

  • vCenterStatistics
    • Level
    • PeriodLength
  • vCenterSettings
    • EventMaxAge
    • TaskMaxAge
    • Logging Level
  • VMHostNtpSettings
    • NTP Server
    • NTPD Service Policy
  • VMHostDnsSettings
    • HostName
    • DomainName
    • Address
  • VMHostSatpClaimRule
    • RuleName
    • Transport
    • Description
  • VMHostTpsSettings
    • ShareScanTime
    • ShareForceSalting

Installation Overview

We now know what it is and what it can do, how about the installation? On the designated proxy LCM system, we will want to download the module from GitHub and make it available in one of our designated PSModulePath directories. The zip file is available through the following link: Desired State Configuration Resources for VMware

Here’s some code that can streamline the download and initialization process:

After we have installed the module we should be able to list the newly acquired module and import it into our active PowerShell Session:

Example: Importing the VMware.vSphereDSC Module

We can also verify the DSC resources we have available:

Example: Output of available DSC Resources

Next, we need to make sure the proxy LCM system can understand the DSC configuration files. This is done through the Windows Remote Management service. We can setup the WinRM service or verify that the WinRM service is setup with the following code:

In my environment, this system already had WinRM setup so I received the following message:
Example: Windows Remote Management Configuration

We should now be all set to start setting up DSC resources in our environment!

Managing an ESXi Host’s NTP

The DSC Resources for VMware repository has some pre-created configuration files which can be sourced to create the MOF file. The MOF file, which stands for Managed Object Format, is the output from a configuration file which has been compiled by the LCM. These configuration files are located in the repo at the following location: \Source\VMware.vSphereDSC\Configurations In my environment, I’ve created my own fork of the repository and cloned it to my local system where I’ll be referencing the files.

In our example, we’re going to setup DSC to manage an ESXi host’s NTP configuration. We can see some parameters and some settings by opening the VMHostNtpSettings_Config.ps1 file that’s located in the ESXiConfigs directory.

Input Type Input Name Input Description
Parameter Name Resource Name
Server Server Host Name
User ESXi host username
Password ESXi host password
Setting NtpServer NTP server/s the host will use
NtpServicePolicy Status for the NTPD service

For my lab environment, I’m going to update the NtpServer values and accept the service policy setting of ‘automatic’. I’m also going to apply this configuration at the ESXi host level, so my host name and server name will match.

We can do this with the following commands:

As part of the output, we should see the following MOF file having been created:
Example: Configuring and creating MOF file

We can then test the MOF file against our host with the following command:

Added to the output, I have also included another PowerShell session which is polling the host for the current NTP server/s and service policy:
Example: Pre-DSC Configuration

In the above example, notice the ‘InDesiredState’ property with a value of False.

Now, we’re ready to start applying our configuration. We do this with the following command:

After a few moments, we’re ready to check the current DSC configuration with the following command:

Again, I’ve added a second PowerShell session to show the current status of the host:
Example: Post DSC Configuration Status

For reference, this is the code I’m running to show the current status of the host’s NTP configuration:

In some later blog posts, we’ll take a look at some of the other areas of this module including applying configurations to multiple hosts, applying vCenter settings, applying values to multiple hosts in a vCenter, and some ways to apply better security practices to both the credentials and the MOF.

Summary

PowerCLI is back with a brand-new feature, Desired State Configuration Resources for VMware! These resources allow PowerCLI to make use of PowerShell DSC to define the configuration of a desired node. The DSC Resources for VMware can define ESXi host settings such as NTP servers, DNS servers, and TPS share scan times. We can also define vCenter settings such as statistics level and logging level. As an additional benefit, these resources are also open-source and community contributions are absolutely welcome!

Check out the Desired State Configuration Resources for VMware on GitHub and let us know what you’re looking forward to using DSC on most in your vSphere environment!

Improving PowerCLI Support with Get-ErrorReport

I am always surprised at the shock some people have when it comes to PowerCLI being supported by VMware! We highlighted this in a prior blog post: PowerCLI Support Breakdown However, in that blog post, there was one item that wasn’t covered which can really help streamline the process of receiving support. This item is a cmdlet by the name of Get-ErrorReport and it received a big update as part of PowerCLI 11.

Let’s walk through an example of creating a PowerCLI support bundle using Get-ErrorReport.

Receiving an Error

The first thing we need to do is receive an error! In this case, I’ll be using a known issue with the Move-VM cmdlet which occurs when attempting to move a VM into a vApp.

Example: Generating an error

The error we received was:

This is a pretty straightforward issue where the Move-VM cmdlet is not operating in the way which was been documented. We can now open a support request!

PowerCLI Support Bundle

Normally, when you open a support request, the first ask is for a support bundle from either the vCenter, an ESXi host/s, or even all of the above. Since this is a PowerCLI issue, those standard support bundles may not help. Plus, some of the more advanced PowerCLI troubleshooting options are not easy, or not readily available, in most environments. One example of which would be to use a tool like Fiddler or Wireshark to sniff the network traffic in order to determine what API methods are being used under the covers and hopefully identify the issue.

Instead of going through the process of installing Fiddler or Wireshare, we can retrieve all the required information by making use of the Get-ErrorReport cmdlet!

The Get-ErrorReport cmdlet has a couple important parameters we’re going to be making use of:
Note: If you’ve used Get-ErrorReport before, these parameters have changed

Destination Location of where the PowerCLI support bundle will be placed
IncludeServerLogs Specify whether we want to pull logs from the connected server
ProblemDescription Provide a description and/or support number
ProblemScript Scriptblock which contains the cmdlet causing the error

Continuing with our Move-VM example, we can use the following code to create our support bundle:

Example: Get-ErrorReport command being run

We can now take that output and upload it to our support request!

Support Bundle Examination

If you happen to be curious about what information is contained within the support bundle, like I was, we can unzip the bundle and read through the contents fairly easy. Note: this section is purely educational as the support engineer will handle the actual diagnosis.

The support bundle contains the following files:

  • PowerCLI-Main-Log.svclog
  • Powershell-Debug-Stream.txt
  • Powershell-Error-Stream.txt
  • Powershell-Info-Stream.txt
  • Powershell-Verbose-Stream.txt
  • Powershell-Warning-Stream.txt

The contents of those files should be fairly straight forward, with the exception of the first one. The PowerCLI-Main-Log.svclog is a collection of diagnostic traces. These traces contain all of the pertinent information about the cmdlets being used, how it is being interpreted by PowerShell, and then the underlying call to the vCenter. The svclog file can be opened with the Microsoft Service Stack Trace Viewer. This application is available as part of the Windows SDK, available here: Windows SDK Archive

The following screenshot is a look at the actual exception being returned by the API service:
Example: Reading the svclog exception

We can see the server response was an internal server error, which has a status code of 500. We can then further read through the individual trace to see the properties and methods being used. We also have the option to look at the traces before and after the call happened to see each of the steps being performed as part of the code entered in our $errorCode scriptblock.

Summary

PowerCLI is supported by VMware and the Get-ErrorReport cmdlet was recently improved in PowerCLI 11. The upgrade helps to streamline the support experience by creating a PowerCLI support bundle which can be provided to VMware support. This support bundle includes all of the required environmental information that VMware support will need to start troubleshooting the issue being reported.

The next time you need to open a support ticket on PowerCLI, make sure to use Get-ErrorReport and let us know your feedback!