Home > Blogs > VMware {code} > Category Archives: How to

VMware {code}

Learn. Code. Connect.

Category Archives: How to

VMware Cloud on AWS Integrations with CloudFormation

The latest update to VMware Cloud on AWS has some real gems in it for developers and automation engineers. As well as the introduction of the Developer Center (which is amazing). It’s such a terrific resource, I’m finding myself using it all the time! The other big news was the addition of an Open Sourced Github repository to showcase VMware Cloud on AWS integrations written by both VMware and the community at large.

The first of these integrations is the support for CloudFormation and Terraform integrations.

In this blog post we’re going to walk through how easy it is to create a software defined data center (SDDC) using the CloudFormation template available in the VMware Cloud on AWS Integration Examples repository. Please note, this will require an AWS account and may incur AWS charges.

First things first, we need to get access to the template. We can clone the repository locally with the following command:

git clone https://github.com/vmwaresamples/vmware-cloud-on-aws-integration-examples.git

1	git clone https://github.com/vmwaresamples/vmware-cloud-on-aws-integration-examples.git

CloudFormation Stack Creation

In order to deploy our SDDC with CloudFormation, we’ll need to start by logging into the AWS Console and checking to make sure we’re in the Oregon region. If you’re not in that region, there is a drop-down box towards the top right-hand side with a site name that’s located between your user account and the “Support” drop-down. Click on the drop-down and select “US West (Oregon)”.

We’ll now want to go to the CloudFormation service. We can find the service by clicking on the “Services” drop-down and locating it in the “Management Tools” section. Alternatively, just type “CloudFormation” in the AWS services search box on the main screen of the console.

Once in the CloudFormation service, we will want to create a new stack by clicking on the “Create New Stack” button. This stack will be used to deploy our SDDC that will be based on the template we’ll import on the next screen.

As part of the stack creation process, we’ll need to either create a new template or select an existing template. We can upload the template we retrieved from the GitHub repo by choosing “Upload a template to Amazon S3” then clicking on “Choose File”. Browse to the location the repo was cloned to, select the “vmc-aws-cloud-cf-template.txt”, and click “Next”.

On the next screen we will need to specify a stack name. In this case, I used “VMWonAWS-CF” as the stack name.

For the “Options” screen, there is nothing to update, so we can click “Next”. On the last screen, review the details and check the box that you “acknowledge that AWS CloudFormation might create IAM resources”. We’re now ready to create our stack by clicking the “Create” button!

After few moments, we should see a screen like the following indicating that the stack creation has been successfully completed.

SDDC Creation

We’ve now laid out the groundwork to deploy our new SDDC. One piece of which is the result of the stack creation, in the form of a new Lambda function. We’ll use this function to input our SDDC criteria and then ultimately deploy our new SDDC.

While we’re still in the CloudFormation service, we’ll want to click on our newly created stack to retrieve the details. Once on the “Stack Detail” page, expand the “Resources” section. There we see the IAM Role and Lambda function. Click on the physical ID of the Lambda function, which will take us to the function’s page.

Once on the newly created Lamda function page, scroll down to the “Environmental variables” section. This section is where we need to input the criteria for the SDDC variables:

connected_account_id: Enter the AWS account this SDDC should be connected to.
Note: This is the ID for the account which can be pulled from the API with the following:
Method: GET /orgs/{org}/account-link/connected-accounts
Property: ID
email: Enter an email address which you would like notified when the process has completed.
name: Enter the desired name of the SDDC
numOfHosts: Enter the number of desired hosts. (Minimum is 4)
orgId: Enter the Org ID for which the SDDC will be assigned. (This is available in the VMware Cloud Console in the “Support Info” tab)
region: Enter the desired region. (Case sensitive format: US_WEST_2)
customer_subnet_ids: Enter the desired subnet ID for VPC traffic.
Note: This is the ID for the VPC subnet which can be pulled from the API with the following:

Method: GET /orgs/{org}/account-link/compatible-subnets
Property: subnet_id
user_refresh_token: Enter the creating user’s OAuth Refresh Token.
Note: This is available in the VMware Cloud Console by clicking your username then “OAuth Refresh Token”.
vpc_cidr: Enter the desired subnet to use that corresponds with preferred management subnet. (Default is 10.2.0.0/16)

With all of our variables now input, we’re ready to save and run our function. First, click “Save” then click “Test”. On the “Configure test event” pop out, give the test event a name and click “Create”.

Next to the “Test” button is a drop-down list of events. Make sure that list is set to our previously created test event and then click “Test” again. If everything was set properly, we should see a response like the following:

We can note from the above image that the response is a task. If we source out the ID, we can then follow along using the tasks API until the creation is complete. Alternatively, we can also watch the deployment process on the SDDCs tab of our Cloud Console.

Summary

The latest update to VMware Cloud on AWS introduced a couple great features for developers and automation specialists as well as a way for you to share your integrations. This blog covered the newly released integrations with CloudFormation. We showed how to access the CloudFormation template in the VMware Cloud on AWS Integration Examples repository. We then walked through how to easily get started deploying SDDCs in VMware Cloud on AWS using the CloudFormation template.

Get started with it today and let us know how you’re planning on integrating this into your existing workflows in the comments below!

Getting Started Using the vSphere Automation SDK for Python with VMware Cloud on AWS

Leave a reply

The vSphere Automation SDK for Python has recently received some exciting updates. These updates add the ability to easily develop against and automate VMware Cloud on AWS! There are even samples to list organization information, manage SDDCs, and lots of networking functionality!

Let’s take a look at how to easily get started with this SDK on a MacOS 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:

git clone https://github.com/vmware/vsphere-automation-sdk-python.git

1	git clone https://github.com/vmware/vsphere-automation-sdk-python.git

Next, we’ll need to install the package manager, Homebrew. Using Homebrew will allow us to easily download and update additional programs. It can be easily downloaded and installed with the following command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

1	/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Now, we’ll install Python in the recommended version of 3.6. It’s worth noting that MacOS comes with a version of Python already installed. However, it is generally an older version (normally, Python 2.7) and is used for some system related tasks. Due to that, it is best not to modify that version or the defaults.

Utilizing our package manager, we’ll install Python 3.6 with the following command:

brew install python3

1	brew install python3

It’s also recommended to isolate your development environments from each other so, we’ll setup a virtual environment and jump into it. We can do that with the following commands:

python3 -m venv VMWonAWSDemo
source VMWonAWSDemo/bin/activate

1 2	python3 -m venv VMWonAWSDemo source VMWonAWSDemo/bin/activate

Then, we’ll install the SDK requirements. They’re listed within the root of the SDK folder in the file labeled: requirements.txt. After checking out which requirements are necessary, we’ll install those requirements by way of the following command while in the root of the SDK folder:

pip install --upgrade --force-reinstall -r requirements.txt --extra-index-url file:///Users/kyleruddy/GitHub/vsphere-automation-sdk-python/lib/

1	pip install --upgrade --force-reinstall -r requirements.txt --extra-index-url file:///Users/kyleruddy/GitHub/vsphere-automation-sdk-python/lib/

Lastly, we need to update the PYTHONPATH variable. This allows Python to be able to use the SDK helper methods. We can do this with the following command:

export PYTHONPATH=${PWD}:$PYTHONPATH

1	export PYTHONPATH=${PWD}:$PYTHONPATH

One other item worth mentioning is an IDE. This will make editing, running and debugging the code a lot easier to deal with. I generally use Visual Studio Code, which is available here.

Let’s get started using some of the samples that have been included with this SDK.

Obtaining Refresh Token

The VMware Cloud on AWS APIs use an OAuth refresh token for authentication. These have to be created through the Cloud Console. Once logged into the Cloud Console, click the drop-down on the top right-hand corner that’s by your name. From there, click on the ‘OAuth Refresh Token’ button. If you don’t already have a refresh token available, there will be a blue link to create a new token. Afterwards, you’ll have a refresh token and be ready to authenticate into the VMware Cloud on AWS APIs.

Obtaining Organization Information

The most important thing you can do when getting started is making your Organization (Org) ID easily accessible. This ID is referenced in almost every API method VMware Cloud on AWS has. If we browse through the SDK folder structure, we’ll see there’s an example we can use to retrieve information about the Orgs. There is a Python package named ‘organization_operations.py’ in the ‘samples/vmc/orgs’ directory.

Example:

export refreshtoken='0073c5b2-xxxx-xxxx-xxxx-606592f7f070'
python3 ./samples/vmc/orgs/organization_operations.py -r $refreshtoken

1 2	export refreshtoken='0073c5b2-xxxx-xxxx-xxxx-606592f7f070' python3 ./samples/vmc/orgs/organization_operations.py -r $refreshtoken

We can see in the results above this example performs a couple tasks. First, we receive a list of all the Orgs this refresh token is associated with. Second, we get some additional information about the first Org that was returned.

Obtaining SDDC Information

The next most important thing we can obtain is information about the SDDC/s this Org has. However, at the time of this blog release, that functionality wasn’t explicitly available. Let’s see how to do this in the REPL, or Python’s interactive interpreter:

import requests
from vmware.vapi.vmc.client import create_vmc_client
refreshtoken = '0073c5b2-xxxx-xxxx-xxxx-606592f7f070'
orgid = 'eb8f2d0a-xxxx-xxxx-xxxx-a4d6282c5555'
vmc_client = create_vmc_client(refreshtoken)
sddcs = vmc_client.orgs.Sddcs.list(orgid)
sddcs
sddcs[0].name

import requests

from vmware.vapi.vmc.client import create_vmc_client

refreshtoken = '0073c5b2-xxxx-xxxx-xxxx-606592f7f070'

orgid = 'eb8f2d0a-xxxx-xxxx-xxxx-a4d6282c5555'

vmc_client = create_vmc_client(refreshtoken)

sddcs = vmc_client.orgs.Sddcs.list(orgid)

sddcs

sddcs[0].name

I think this ability is something that will be quite helpful as part of the example SDDC package. Adding it is as easy as adding the following to the ‘create_delete_sddc.py’ file:

def list_sddc(self):
    sddcs = self.vmc_client.orgs.Sddcs.list(self.org_id)
    if not sddcs:
        raise ValueError('The sample requires at least one SDDC associated'
                            'with the calling user')
    print("\n# Example: List SDDCs")
    table = []
    for sddc in sddcs:
        table.append([sddc.id, sddc.name, sddc.resource_config.region])
    print(tabulate(table, ['ID', 'Name', 'AWS Region']))

def list_sddc(self):

sddcs = self.vmc_client.orgs.Sddcs.list(self.org_id)

if not sddcs:

raise ValueError('The sample requires at least one SDDC associated'

'with the calling user')

print("\n# Example: List SDDCs")

table = []

for sddc in sddcs:

table.append([sddc.id, sddc.name, sddc.resource_config.region])

print(tabulate(table, ['ID', 'Name', 'AWS Region']))

However, you won’t need to do that. This SDK is open-sourced and I was able to submit a pull request to get it added in already! As part of the PR, we updated the file name to be ‘sddc_crud.py’ and it is available in the ‘samples/vmc/sddc’ directory.

Logical Network Tasks

Last example, let’s run through some tasks for logical network administration. There’s a sample for this as well. The ‘logical_network_crud.py’ package will create a new logical network, list all of the logical networks, list only the newly created logical network, and then delete the newly created logical network. This file is available in the ‘samples/vmc/networks/’ directory.

Example:

export orgid='eb8f2d0a-xxxx-xxxx-xxxx-a4d6282c5555'
export sddcid='584e8cc8-xxxx-xxxx-xxxx-733871f9f0a6'
python3 ./samples/vmc/networks/logical_network_crud.py -r $refreshtoken -o $orgid -s $sddcid --network-name 'Python-SDK-LogicalNetwork' -c

export orgid='eb8f2d0a-xxxx-xxxx-xxxx-a4d6282c5555'

export sddcid='584e8cc8-xxxx-xxxx-xxxx-733871f9f0a6'

python3 ./samples/vmc/networks/logical_network_crud.py -r $refreshtoken -o $orgid -s $sddcid --network-name 'Python-SDK-LogicalNetwork' -c

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Python with VMware Cloud on AWS. 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.

If you’ve missed any of the prior posts, here are the others in this ‘Getting Started’ series with our open-sourced SDKs:

Getting Started with the vSphere Automation SDK for Perl

Leave a reply

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 the SDK for Perl.

If you’ve missed any of the prior posts, here are the others in the series:

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:

git clone https://github.com/vmware/vsphere-automation-sdk-perl.git

1	git clone https://github.com/vmware/vsphere-automation-sdk-perl.git

We also want to make sure Perl is available on the local system. The supported versions are Active Perl 5.14+ or Stawberry Perl 5.24.1.1+. For these examples, I’ll be using Active Perl which can be downloaded directly from their site: Active Perl

We will then need to make sure a couple Perl packages are installed and available. These can be installed with the following commands:

ppm install XML::LibXML
ppm install UUID::Random
ppm install Crypt::OpenSSL::RSA
ppm install Exception::Class
ppm install Crypt::X509
ppm install Data::Compare

ppm install XML::LibXML

ppm install UUID::Random

ppm install Crypt::OpenSSL::RSA

ppm install Exception::Class

ppm install Crypt::X509

ppm install Data::Compare

Next, this SDK also depends on some capabilities from the vSphere Perl SDK. We will need to login to the My VMware portal, download the executable, then install it from the following link: vSphere Perl SDK

We have one more step concerning the vSphere Perl SDK install. We also need to make sure the ‘python27.dll’ file is available in the vSphere Perl SDK’s folder as follows: ..\Perl\lib\VMware

The following code can be used to easily copy that file to the proper location:

cp 'C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\python27.dll' 'C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\lib\VMware\'

1	cp 'C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\python27.dll' 'C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\lib\VMware\'

Last part of the prerequisites is to configure the environmental variable PERL5LIB to look for modules in the newly cloned SDK directory. The following directories need to be specified:

..\lib\runtime
..\lib\sdk
..\samples

The following code was used to configure the PERL5LIB environmental variable for my lab:

set PERL5LIB=%PERL5LIB%;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\lib\runtime;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\lib\sdk;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\samples

1	set PERL5LIB=%PERL5LIB%;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\lib\runtime;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\lib\sdk;C:\Users\Kyle Ruddy\Documents\GitHub\vsphere-automation-sdk-perl\samples

We are now all setup to start using the vSphere Automation SDK for Perl!

Running Samples

There are a handful of samples that are already included with this SDK. The samples are separated by the API namespaces into different directories and then presented as scripts. We’ll be looking at running some of the samples from the vCenter directory.

The first example we’ll run is the List VMs sample. This sample can be found in the ‘..\samples\Vcenter\Vm’ directory. There are a couple sample scripts here, which also include deleting a VM and performing some power actions.

If we run the ‘list_vms.pl’ sample as is, we will receive back the appropriate parameters to successfully complete the call. Those parameters would be username, password, and server name.

Performing the List VMs sample in my environment, with all of the required parameters, looks like the following:

perl list_vms.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local

1	perl list_vms.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local

There’s another example in the VM folder which allows us to modify the power state for a given VM. However, this sample will take a given VM through all of the available power states. Again, running the sample without any parameters will give us the required parameters. We can see that we’ll need to also add parameters for the VM name and cleanup. The cleanup parameter is used to return the VM to the last state it was in.

Performing the List VMs sample in my environment, with all of the required parameters, looks like the following:

perl power_life_cycle.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local --vmname svc02 --cleanup false

1	perl power_life_cycle.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local --vmname svc02 --cleanup false

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. 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’. This can be found on line 71 of the ‘default_vm.pl’ script. Additional Guest OS types can be found in the API documentation: Guest_OS Types

We’ll start by moving to the following directory: ..\samples\Vcenter\Vm\Create\DefaultVM Running the ‘default_vm.pl’ script will show us a number of parameters we’ll need to specify. These parameters include names for the following: VM, Datacenter, Cluster, VM folder, datastore. There’s also the authentication and cleanup parameters. In this case, giving the cleanup parameter a ‘True’ value will remove the newly created VM.

Performing the Create New Default VM sample in my environment, with all of the required parameters, looks like the following:

perl default_vm.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local --vmname demovm01 --datacenter DemoDC --clustername Demo --vmfolder Dev --datastore vsanDatastore --cleanup False

1	perl default_vm.pl --username kruddy@corp.local --password VMware1! --server vcsa01.corp.local --vmname demovm01 --datacenter DemoDC --clustername Demo --vmfolder Dev --datastore vsanDatastore --cleanup False

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Perl. 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.

Getting Started with the vSphere Automation SDK for .NET

Leave a reply

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:

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:

git clone https://github.com/vmware/vsphere-automation-sdk-.net.git

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:

.\vmware\samples\vcenter\vm\list\ListVMs\bin\Debug\ListVMs.exe --server vcsa01.corp.local --username kruddy@corp.local --password 'VMware1!' --skip-server-verification

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:

.\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

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:

.\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

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.

Getting Started with the vSphere Automation SDK for Java

Leave a reply

There has been another exciting open-sourced release in the vSphere Automation SDK lineup. This time, it is the vSphere Automation SDK for Java!

That means it’s time for another blog post in our series on ‘Getting Started with the vSphere Automation SDKs’. The posts available in the series so far are as follows:

We’ll be taking a look at how to easily get started with this SDK on a Mac. Before diving in, 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:

git clone https://github.com/vmware/vsphere-automation-sdk-java.git

1	git clone https://github.com/vmware/vsphere-automation-sdk-java.git

Next, we’ll want to make sure we have the appropriate Java Development Kit (JDK) installed and available. The vSphere Automation SDK for Java has been developed to work with JDK 1.8. We can verify which version of Java is available by the following command:

java -version

1	java -version

In this situation, my system doesn’t have Java installed at all. I’ll need to head out to the JDK8 download page to download and install the appropriate version. Once complete, repeat the last command to ensure JDK 1.8 is installed. Verifying and/or updating the JAVA_HOME and PATH variables is the last step to the install process. We’ll start by finding the current value for the JAVA_HOME variable, then updating it, if necessary, to the Home directory of the newly installed JDK. We’ll then repeat that process for the PATH variable as well. This can be done with the following commands:

echo $JAVA_HOME
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home
echo $PATH
export PATH=$JAVA_HOME/bin:$PATH

echo $JAVA_HOME

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home

echo $PATH

export PATH=$JAVA_HOME/bin:$PATH

We will also need to ensure Maven, a build automation tool, is installed. We will use Maven to build out the SDK and the samples from source so we can start using it. My system doesn’t have Maven installed yet, so we’ll go to the download page and install it according to the instructions on Maven’s site. Alternatively, we can do it with the following commands:

curl -o apache-maven-3.5.2-bin.tar.gz -k http://apache.mirror.globo.tech/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz
tar -xzf apache-maven-3.5.2-bin.tar.gz
sudo mv apache-maven-3.5.2 /opt/
rm apache-maven-3.5.2-bin.tar.gz
export PATH=/opt/apache-maven-3.5.2/bin:$PATH

curl -o apache-maven-3.5.2-bin.tar.gz -k http://apache.mirror.globo.tech/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz

tar -xzf apache-maven-3.5.2-bin.tar.gz

sudo mv apache-maven-3.5.2 /opt/

rm apache-maven-3.5.2-bin.tar.gz

export PATH=/opt/apache-maven-3.5.2/bin:$PATH

The last prerequisite, before starting to user the SDK, is instructing Maven to build out all the samples with Maven. We’ll first use the initialize command, within the cloned repository directory, to pre-stage any dependencies that are not available publicly. We’ll then follow that with install command. This can be done with the following commands:

mvn initialize
mvn clean install

1 2	mvn initialize mvn clean install

We are now all setup to start using the vSphere Automation SDK for Java!

Running Samples

There are quite a few samples which are included with the SDK. Each sample can be run by using its fully qualified class name.

The first example we’ll take a look at is the ListVMs sample. In terminal, from the root of the SDK directory, we’ll call java, enabling assertions with the ‘ea’ parameter, using the ‘cp’ parameter to call the class path of ‘target/vsphere-samples-6.5.0.jar’, then the fully qualified class name. An example of this command is as follows:

java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs

1	java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs

Based on the output, we see quite a few parameters that still need to be referenced in order to authenticate and run the sample. The required parameters are server, username, and password. However, there are also some considerations needed around the handling of the vCenter’s certificate. I’m using a lab environment that still has the vCenter’s self-signed certificate in use, so I’ll be using the ‘skip-server-verification’ parameter. Lastly, there are the optional paramaters, most of which are straight forward, but the config-file parameter is a convenient one. For now, we’ll keep it simple and call each parameter as part of the command. I’ll discuss using a configuration file later in this post.

Performing the ListVMs sample in my environment, with all of the required parameters, looks like the following:

java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification

1	java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification

There’s another sample which takes a VM through the lifecycle of power states. This sample can be discovered in the ‘../vmware/samples/vcenter/vm/power’ directory. The public class we’ll be using is ‘PowerLifeCyle’. If we run that without any parameters, we can see that we’ll need to add the ‘vmname’ parameter and call a specific VM by name. Running this sample can be done with the following command:

java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.power.PowerLifeCycle --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification --vmname web01

1	java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.power.PowerLifeCycle --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification --vmname web01

The last example we’ll look at is the modifying the memory configured for a VM. This sample can be found in the ‘../vmware/samples/vcenter/vm/hardware/memory’ directory. The public class we’ll be using is ‘MemoryConfiguration’. If we run that without any parameters, we can see that we will again need to add the ‘vmname’ parameter and call a specific VM by name.

This sample will set the RAM to 8GB then enables hot-add. We can go execute this sample with the following command:

java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.hardware.memory.MemoryConfiguration --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification --vmname svc01

1	java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.hardware.memory.MemoryConfiguration --server vcsa01.corp.local --username administrator@vsphere.local --password VMware1! --skip-server-verification --vmname svc01

One last thing before wrapping this up, let’s walk through using the configuration file. The configuration file can be any text-based file which contains lines that begin with the parameter names. In the following example, we create a new file and modify the file to include the following lines:

server=vcsa01.corp.local
username=administrator@vsphere.local
password=VMware1!

server=vcsa01.corp.local

username=administrator@vsphere.local

password=VMware1!

We can now reference this config file in any of the examples to authenticate against a vCenter server. Reusing the ‘ListVMs’ sample, the command to run that again but instead using a configuration file will look like the following:

java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs --config-file config.file --skip-server-verification

1	java -ea -cp target/vsphere-samples-6.6.1.jar vmware.samples.vcenter.vm.list.ListVMs --config-file config.file --skip-server-verification

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Java. 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.

VMware Cloud Certification Services: A Journey to SaaS Transformation

Leave a reply

VMware delivers a pre-configured cloud based certification test bed in the cloud for a fixed duration of time to it’s partners to certify their products. Partners with access to the program can log-in using a URL provided by VMware and access the test bed without any VPN.

Continue reading →

Getting Started with the vSphere Automation SDK for Ruby

Leave a reply

There has been another exciting open-sourced release in the vSphere Automation SDK lineup. This time, it is the vSphere Automation SDK for Ruby!

That means it’s time for another blog post in our series on ‘Getting Started with the vSphere Automation SDKs’. The posts already available in the series so far are as follows:

We’ll be taking a look at how to easily get started with this SDK on Mac OS. Before diving in, there are a couple prerequisites we’ll need to download and install.

Note: If you’re using this SDK on any other OS, check out the ‘Quick Start Guide‘ section of the GitHub repository for guidance.

Prerequisites

The first thing we’ll want to do before getting started with this SDK is to clone the repo to the local system. We can do that with the following command:
git clone https://github.com/vmware/vsphere-automation-sdk-ruby.git

We will then need Ruby to be at version 2.3.1 or better. On this particular system, which is currently running Mac OS Sierra (10.12), we see that it’s currently running Ruby 2.0.0.

In order to obtain the newer version of Ruby, we will need to install the package manager, Homebrew. If you don’t have it already, it can be easily downloaded and installed with the following command:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Next, we will install the latest version of Ruby available. We will do this, through Homebrew, with the following command:
brew install ruby

This SDK also has a couple dependencies which will also need to be installed. These dependencies are called out in the Gem specification file which is located in the root of our cloned repo directory. The Gem spec file is named: vsphere-automation-sdk-ruby.gemspec

In order to easily install all of these dependencies, we will use Bundler. Bundler is used to manage the required gems and which versions of those gems are required. We can install bundler with the following command:
gem install bundler

Lastly, we will need to build and then install our Gem. To perform the build, switch to the directory where the vsphere-automation-sdk-ruby.gemspec file is located and run the following command:
gem build vsphere-automation-sdk-ruby.gemspec

Once complete, we will have the Gem that we’ll need to then install. We can take the Gem filename and run the following command:
gem install vsphere-automation-sdk-2.5.0.gem

We are now all setup to start using the vSphere Automation SDK for Ruby!

One quick item to note, the SDK’s documentation is available locally as part of the cloned repository.
The API docs are available in the following location: /docs/apidocs/vsphereautomation-bindings
The Samples docs are available in the following location: /docs/apidocs/vsphereautomation-samples

Running Samples

There are a couple samples which are included with the SDK, they are:

Connection: Sample framework to successfully connect to the vSphere Automation API endpoint and retrieve the SAML token
Tagging: Create vSphere Tag Category and associated tags
List_VMs: Create a list of available VMs containing the VM Name, Power State, Number of CPUs, and Memory Size in Megabytes

These are made available through the launcher.rb file in the following directory within the repo: /client/samples/bin/launcher.rb

As additional samples are created and/or contributed from the community (such as the ‘list_vms’ sample was), this will be the place to look for them.

To call each of these samples, we’ll need to call the following file: /client/samples/bin/run_sample

If we run that command alone, it will show an example populated command and the available samples matched to their configuration files within the repo.

Each of these samples also offer a help functionality using either the ‘–help’ or ‘-h’ parameter which will display additional parameters for the given sample.

Taking a look at the connection sample, we can run the following command to understand what the sample is looking for in terms of parameters: bin/run_sample connection –help

Now, we can create the full command in order to obtain a SAML token and login to the vSphere Automation API endpoint. The example we’ll use is as follows:
bin/run_sample connection -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' –k

Moving to the tagging sample, we have the ability to create tag categories and their associated tags. Running an example will look like the following:
bin/run_sample tagging -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' -k --category-name 'SDKTagCategory' --tag-name 'SDKTag'

Lastly, we’ll use the ‘list_vms’ sample to create a list of the VMs available in our environment. We can do this with the following command:
bin/run_sample list_vms -l vcsa01.corp.local -u 'administrator@vsphere.local' -p 'VMware1!' –k

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Ruby. It takes you through the setup of an entire 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 SDK 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.

Lightboard Talk: What Is a Container?

Leave a reply

In this lightboard talk from May 2017, Ben Corrie (@bensdoings) explains what a container is for beginners. Enjoy!

For more tutorials like this one, check out the complete Cloud Native Basics series.

Interested in learning more about containers and VIC? Join VMware {code} to get your personal Slack invite and get access to 60+ channels covering a wide range of topics: https://code.vmware.com/join

Getting Started with the vSphere Automation SDK for Python

3 Replies

We’ve been looking at how to get started using the new vSphere Automation SDKs. In the last couple parts of the series we looked at the SDK for REST, which included Postman REST client samples, as well as some JavaScript samples. This time, we’ll be looking at the vSphere Automation SDK for Python!

Prerequisites

There are a handful of ways to install and setup Python on your workstation, I will be walking through a high level configuration for my Mac.

First things first, clone the vSphere Automation SDK for Python from the VMware GitHub repository located here.

Cloning the Python SDK repo

After that’s complete, we’ll need to install the Python prerequisites. These include the GNU Complier Collection (GCC), a C compiler, and HomeBrew, a package management system.

GCC can be installed in multiple ways, but I’ve found it’s easiest to obtain it by installing the Xcode Command Line Tools. This can be done with the following command, then following the prompts:
xcode-select --install

XCode Installation

Next, we’ll need to install the package manager, Homebrew. It can be easily downloaded and installed with the following command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew Installation

Finally, we’ll install Python in the recommended version of 3.6. It’s worth noting here that Mac OS X comes with a version of Python already installed. However, it is generally an older version (normally, Python 2.7) and is used for some system related tasks. Due to that, it is best not to modify that version or the defaults.

Utilizing our package manager, we’ll install Python 3.6 with the following command:
brew install python3

Python 3.6 Installation

It’s also recommended to isolate your development environments from each other so, we’ll setup a virtual environment and jump into it. We can do that with the following commands:
python3 -m venv SDKDemo source SDKDemo/bin/activate

Creating a virtual development environment

Lastly, we’ll install the SDK requirements. They’re listed within the root of the SDK folder in the file labeled: requirements.txt. After checking out which requirements are necessary, we’ll install those requirements by way of the following command:
pip3 install -r requirements.txt

Requirement Installation

One other item worth mentioning is an IDE. This will make editing, running and debugging the code a lot easier to deal with. I’ll be using PyCharm, which is available here.

Running Sample Setup Script

To really show off the capabilities of the SDK, there’s a sample script which takes an un-configured vSphere environment and performs all of those normal configuration steps. The environment requirements to run the script are as follows:

1 vCenter Server
2 ESXi Hosts
1 NFS Datastore (minimum of 3GB free)

We’ll first need to open up the testbed.py file and populate lines 17 through 29 as follows:

Modification of the Testbed File

We’re now ready to set the environment up with the sample script! However, before running the script we should take a look at what it’s doing. The script is available in the SDK directory at: /bin/run_sample.sh The goal of the script is to do the following actions:

Create 2 Datacenters
Create a Cluster
Create Test Folders for VM Storage
Attach the Hosts
Create a Distributed Switch
Create a Distributed PortGroup
Attach the NFS Datastore (if Selected) to the hosts
Copy the Photon OS ISO image downloaded from VMware’s bintray server to the Datastore
Create directories to add sample ports

One note before running the script, the ISO image being downloaded is roughly 200MB and could take a while depending on your bandwidth. My tests ranged anywhere between 30 seconds and 5 minutes.

The sample script can be run with the following command:
./run_sample.sh ../samples/vsphere/vcenter/setup/main.py –sv

Configuring an environment with the main.py file

Create a VM with Defaults

Now that our environment is setup, let’s take a look at adding a VM to this environment. The easiest way is to create a default VM. This action means the API takes care of all the configuration settings based on the Guest OS version. There are some prerequisites that are required for placement such as desired datacenter, VM folder, and datastore. These are all referenced from the testbed.py configuration file we referenced in the first example.

Updating the Testbed File for VM Tasks

The VM can then be created with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/create/create_default_vm.py –v

Default VM Creation Sample

Notice in the above example how even though we didn’t populate all of the settings, the VM received required items like a CPU, a disk, and so forth.

To verify the VM does indeed exist, we can obtain a list of VMs with the following command:
./run_sample.sh ../samples/vsphere/vcenter/vm/list_vms.py –v

List VMs Sample

VM Power Actions

The next logical step after creating a VM is to power it on. There’s a sample within the vm folder named power.py, which shows off all of the power actions. This file references the ‘VM_NAME_DEFAULT’ input from the testbed.py file.

When running the command as is, the VM will be put through the following power states:

Obtain current power state
Power Off (NOTE: Only if the VM is currently powered on)
Power On
Suspend the VM
Resume the VM
Reset the VM

The command can be run with the following:
./run_sample.sh ../samples/vsphere/vcenter/vm/power.py –v

VM Power State Sample

Summary

This post shows you how to easily get started with the vSphere Automation SDK for Python. It takes you through the setup of an entire environment, as well as using 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.

If you’ve missed any of the prior posts, here are the others in the series:

Common Packaging Pitfalls When Developing vSphere Client HTML Plug-ins

Leave a reply

This post was authored by Ina Uzunova, Product Owner of vSphere Client SDK, and Vladimir Velikov, vSphere Client SDK Engineer.

The official vSphere Web Client SDK Documentation of vSphere 6.5 contains important best practices for developing your HTML based vSphere Client Plug-in which are explained in chapter “Best Practices for Developing Extensions”.

A common source of mistakes when building a vSphere Client plug-in is packaging: the way the final vSphere Client plug-in deliverable is built, released to end users and deployed in production environments.

There has been a number of error-prone techniques that were encountered with previous releases. The goal of this post is to address the most common pitfalls when packaging your plug-in and the negative impact those have on your plug-in’s design and operation.

vSphere Client plug-in structure

Each vSphere Client plug-in consists of the following elements:

Plug-in manifest: the plugin-package.xml file where the plug-in defines its ID, version, general information and compatibility constraints.
Set of plug-in bundles: the plugins/ folder with the plug-in UI bundle (.war), the plug-in Java service bundles (.jar) and all external library bundles (.jar) the plug-in depends on.
These .war and .jar files need to be correctly defined OSGi bundles with a valid MANIFEST.MF.

Common plug-in packaging mistakes

Here are a few common plug-in packaging mistakes with their impact and improvement recommendation:

A) Errors in the plug-in manifest metadata (plugin-package.xml)

Using wrong company name – “id” and “vendor” attributes do not refer to the correct company name
1. Error example: <pluginPackage id="com.mycompany1.myplugin" version="1.0" vendor="MyCompany2">
2. Impact: The plug-in is displayed with wrong information on the UI and might clash with the “id” of another plug-in.
3. Recommendation: use your company name for all “id”-s in the plug-in.
Dependency on another plug-in – “pluginPackage” dependency tag refers to a plug-in which is not part of vSphere Client
1. Error example: <dependencies><pluginPackage id="com.mycompany2.plugin2" version="1.0"></dependencies>
2. Impact: The plug-in lacks integrity and autonomy. The target plug-in might not exist in the system but even if it does it now lives in its own dependency scope (in isolation) which makes it inaccessible by your plug-in. As a result your plug-in might fail during deployment or at runtime.
3. Recommendation: Depend only on vSphere Client plug-ins (e.g. “com.vmware.vsphere.client”)
Dependency on plug-in bundles – “pluginPackage” dependency tag refers to a plug-in library or OSGi bundle
1. Error example: <dependencies><pluginPackage id="com.vmware.vim25" version="1.0"></dependencies>
2. Impact: The plug-in will not be deployed by vSphere Client. The plugin-package.xml expects plug-in dependencies, not library/bundle dependencies.
3. Recommendation: Remove any library/bundle dependencies.
Plugin version is incorrectly specified as a tag
1. Error example: <version>1.0</version>
2. Impact: The plug-in manifest will be unreadable by vSphere Client and your plug-in will not be deployed.
3. Recommendation: Specify the plug-in version as attribute (e.g. <pluginPackage version="1.0" ...>)

B) Problems in the plug-in bundles (.jar and .war files in the plugins/ folder)

Split packages – two or more plug-in bundles export the same package id
1. Error example: Two .jar bundles contain com.mycompany1.package1 in the Export-Package section of their MANIFEST.MF.
2. Impact: The plug-in will not be deployed by vSphere Client in isolation (default).
3. Recommendation: If the two packages are part of the same feature move all respective classes to the same bundle to make it explicit. If the two packages represent different features rename one of the packages to indicate this conceptual difference.
Packaging the vSphere Client SDK deliverable
1. Error example: The plug-in contains vsphere-client-lib.jar.
2. Impact: Increased size of your plug-in. This jar is not an OSGi bundle and will be ignored during deployment. It is not intended for being packaged with the plug-in but for building the plug-in against the public set of Java APIs which are anyway available at vSphere Client’s runtime.
3. Recommendation: Remove vsphere-client-lib.jar from the plug-in.
Packaging libraries without OSGi manifest
1. Error example: The plug-in contains a .jar/.war with no MANIFEST.MF.
2. Impact: Increased size of your plug-in. The specified .jar/.war is not an OSGi bundle will be ignored during deployment.
3. Recommendation: If the library is not used remove it from the plug-in. Otherwise, convert the library into an OSGi bundle by adding a MANIFEST.MF.
Importing packages from nested libraries – a plug-in bundle both embeds a library and imports a package from it
1. Error example: A plug-in .jar/.war bundle’s MANIFEST.MF contains Import-Package section with com.mycompany1.package1 and Bundle-Classpath section with my-internal-lib.jar.
2. Impact: The plug-in will not be deployed. The internal library is not an OSGi bundle so it does not export any packages that your bundle can import.
3. iii. Recommendation: Remove the package import. The library is already available for direct use by the bundle because it is part of its classpath.

C) Plug-in interoperability issues with vSphere Client

Delivering one or more plug-in bundles built with a higher Java version than vSphere Client supports.
1. Error example: A plug-in .jar/.war bundle is built with target Java version 8 while target vSphere Client version contains bundles built with Java 7.
2. Impact: The plug-in will not be deployed.
3. Recommendation: Follow the environment requirements from the official documentation. Pay attention to what target Java compiler compliance level should be specified for your plug-in bundles.
Packaging 3rd party libraries which are already delivered by vSphere Client
1. Error example: The plug-in contains a javax.servlet-api.jar bundle.
2. Impact: Increased size of your plug-in and possible plug-in problems if any operations refer to APIs not present in the vSphere Client’s version of the library. At runtime vSphere Client will always deploy its required 3rd party dependencies first and plug-ins will always consume them even if they bring their own version of the library.
3. Recommendation: Remove any 3rd party libraries from your plug-in which have counterparts in the server/repository/usr folder of vSphere Client’s server. Note that you need to check the Bundle-SymbolicName in the MANIFEST.MF of the .jar bundle as the .jar file name is not always sufficient to be sure if the bundle maps to one of your plug-in bundles.
  Common libraries delivered by vSphere Client to watch out for are:
  - Spring libraries
  - Jackson libraries
  - servlet, javax.servlet-api, javax.transaction
  - apache.commons.logging
  - joda-time
The plugin is using the global context class loader.
1. Error example: The plug-in tries to load resources it delivers using the global context ClassLoader.
2. Impact: The plug-in will fail during deployment or at runtime because it is unable to load the required resource. The reason is that plug-ins are now deployed in isolation by default which makes plug-in resources not directly visible to the global context ClassLoader.
3. Recommendation: Use current bundle class loader for loading resources (e.g. temporarily change the context ClassLoader with Thread.currentThread().setContextClassLoader(getClass().getClassLoader())).

Cleaning up the aforementioned drawbacks that might be present in your plug-in would facilitate its smooth deployment, operation and interoperability with vSphere Client. In addition, plug-ins would benefit from better design, smaller zip deliverables and faster deployment times.

For more hints check the Best Practices listed in the official vSphere Web Client SDK Documentation or refer to the other blog posts on Building vSphere Client plug-ins and OSGi-Specific Best Practices