We are going to keep the ‘Getting Started’ series going on using the vSphere Automation SDKs. This time, we will be taking a look at this SDK for .NET.
If you’ve missed any of the prior posts, here are the others in the series:
- vSphere Automation SDK for REST
- vSphere Automation SDK for REST Part 2
- vSphere Automation SDK for Python
- vSphere Automation SDK for Ruby
Let’s take a look at how to easily get started with this SDK on a Windows 10 system. Before diving in though, there are a couple prerequisites we’ll need to download and install.
Prerequisites
The first thing we’ll want to do before getting started with this SDK is to clone the repository to the local system. We can do that with the following command:
1 |
git clone https://github.com/vmware/vsphere-automation-sdk-.net.git |
The other things we’ll need is .NET Framework 4.5 and Visual Studio 2015 or newer. I’ll be using Visual Studio 2017. On Windows 10, .NET Framework 4.5 should already be available. If it’s not, you can download it directly from Microsoft at the following link: Microsoft .NET Framework 4.5. If you don’t already have Visual Studio, it can be downloaded through the following link: Visual Studio
The next thing we need to do is build out the samples in Visual Studio. We start this process by opening Visual Studio. Now we can click on “File”, “Open”, then click “Project/Solution”. From the new Explorer window, browse to the root directory of where the SDK repo was cloned, then select and open the ‘vSphere-Samples.sln’ file.
Note: This process may take some time and if there are any missing dependencies found in the Visual Studio install, it will prompt to install those items.
We will be ready to finish building out the samples once the vSphere-Samples solution has been presented in the Solution Explorer. We’ll then right click on “Solution ‘vSphere-Samples’ (17 projects)” and select “Build Solution”. After a few moments there should be a message on the bottom information bar indicating “Build succeeded”.
We are now all setup to start using the vSphere Automation SDK for .NET!
Running Samples
There are a handful of samples already included with this SDK. The samples are separated by the API namespace into different directories and presented as projects. We’ll be looking at running some of the samples from the vCenter directory.
The first example we’ll take a look at is the ‘ListVMs’ sample. We start in the Solution Explorer, expanding ‘vcenter’, ‘vm’, and finally the ‘list’ directory. We can now see a ‘ListVMs’ project. We will want to right click the project and click ‘Set as StartUp Project’.
Prior to running the sample, we need to populate the sample with some properties such as which vCenter Server to connect to and with what credentials. We can find what the available properties are by clicking on the ‘Debug’ menu and then selecting ‘Start Without Debugging’.
We should receive a command prompt window that gives us the available properties.
In order to pass those parameters, we’ll need to open up the properties of the project. Once open, select the ‘Debug’ tab and look for the ‘Start options’ section. The ‘Command line arguments’ text box is where we’ll be specifying the parameter values. The parameters for my environment end up looking like the following:
With the parameters now laid out, we’re ready to actually run the sample!
Example results after hitting the ‘Start’ button:
Alternatively, we can also run the built executable for the ListVMs sample. It is located in the following directory: ..\vmware\samples\vcenter\vm\list\ListVMs\bin\Debug
Example code:
1 |
.\vmware\samples\vcenter\vm\list\ListVMs\bin\Debug\ListVMs.exe --server vcsa01.corp.local --username kruddy@corp.local --password 'VMware1!' --skip-server-verification |
We can also make modifications to an existing VM’s configuration. One example would be to update a VM’s CPU configuration, so let’s take a look at the CpuConfiguration sample. This project is under ‘vm’ then ‘hardware’. This sample is already configured to increase the CPU count to 2 and to enable CPU Hot Add. These options can be modified in the source code (CpuConfiguration.cs) at line 71 and 81, respectively.
This time we’ll run the sample directly from the executable. The first time we run it, without adding any parameters, we can see that we need our standard authentication parameters but we also need to specify the VM name. Running this sample in my environment looks like the following:
1 |
.\vmware\samples\vcenter\vm\hardware\CpuConfiguration\bin\Debug\CpuConfiguration.exe --server vcsa01.corp.local --username kruddy@corp.local --password 'VMware1!' --vmname svc02 --skip-server-verification |
The last example we’ll take a look at is the creation of a new VM. We’ll take advantage of one of this new API’s features and create a new VM using defaults by using the CreateDefaultVM project. This means the API fills in any parameters we do not specify with values based on what Guest OS has been specified. It’s also import to note that the Guest OS has been hardcoded in the sample to be ‘Windows_9_64’ on line 38 of the source code (CreateDefaultVm.cs). Additional Guest OS types can be found in the API documentation: Guest_OS Types
The project for this sample is located under ‘vm’ then ‘create’. However, we will again be running this sample directly from the executable. Running the executable without any parameters shows that we will need some additional parameters specified. These parameters include names for the following items: datacenter, cluster, vmfolder, and datastore.
Performing the Create Default VM sample in my environment, with all of the required parameters, looks like the following:
1 |
.\vmware\samples\vcenter\vm\create\CreateDefaultVm\bin\Debug\CreateDefaultVm.exe --server vcsa01.corp.local --username kruddy@corp.local --password 'VMware1!' --datacenter DemoDC --cluster Demo --vmfolder Dev --datastore vsanDatastore --skip-server-verification |
Summary
This post shows you how to easily get started with the vSphere Automation SDK for .NET. It takes you through the setup of your local development environment, as well as running some of the individual samples. You can then take whichever is most relevant to you and apply to your environment or, pull parts of this code out and use it to automate or integrate as needed.
With our SDKs now being open sourced, we are intent on making sure these samples are of a high quality. If you notice areas of improvement, or come up with some new samples, please feel free to raise issues or pull requests on our GitHub repository.