Scripting with Nuage VSPK – Part 2 – Advanced concepts & examples

Scripting with Nuage VSPK – Part 2 – Advanced concepts & examples

Last week we introduced the basic installation and usage of the Nuage VSPK using some script examples.

This week we will continue our dive into this subject by introducing some advanced concepts and again we will use some example scripts to explain these concepts in detail:

  • Creating ACLs policies and rules with Jobs
  • Gathering Statistics with Query Parameters
  • Asynchronous calls
  • Push notifications
  • Set Policy Groups on a VM depending on its name in vCenter by combining the Nuage VSPK with the vCenter SDK

Happy reading!

Jobs

A Job is a task the VSD has to execute on an entity under its control. For instance if you use the GUI to export a domain template, in the background a Job is created on that specific domain template and the GUI will check the status of that job until it is finished. Once it is finished, the GUI will gather the job result, which in this case is the JSON export of the chosen Domain Template.

To create a job on an entity, you first create the Job object with the correct command (for a list, check the API docs) and create it as a child of the entity:

Once your job is created, the VSD will execute the job, you can check the status of the job by first using the fetch()  method to get the latest information from the VSD and then checking the status  property.

In the above example, we check the status of the job every second and if the status is either SUCCESS or FAILED we break the loop. In the latter case we also inform the user of this.

To get the result, you just need to get the result property of a successfully finished job.

Job commands with input

There are also job commands which requires you to provide some input. The most interesting is the IMPORT  command, which is used to import previously exported, and possibly edited, entities like ACL policies, domains or domain templates. This can be accomplished with the parameters parameter which will take different types of input depending on the command.

For an import, it would look like the following example:

This will have copied the Main VSPK Domain from the VSPK Enterprise to a new enterprise called VSPK Import Enterprise.

Creating ACL policies and rules with Jobs

If you have ever used the VSD GUI to create ACL policies and rules, you will have noticed the commit/rollback system that was introduced in Nuage VSP 3.2. This system allows you to make changes to your ACL policies and rules without impacting traffic until you are sure everything is configured correctly, at which point you can commit the changes and they are applied immediately.

This whole process uses jobs to change the state of the domain into policy editing mode and to commit these changes. The following script illustrates how this is done.

The above script will create a new middle ACL ingress policy inside the domain and will then create two rules inside that ingress policy. Let’s look at it in a bit more detail.

Entering the policy edit mode

Lines 2 and 3 show how you can create a job which will enter the domain in the policy edit mode. This will allow you to make changes to the ACLs without impacting the live environment before you are finished.

For this, the BEGIN_POLICY_CHANGES command is used.

In a normal case, you should always check for the job to be finished before starting to create ACLs. To limit the length of the code, we skipped that part. In the previous section we have shown an example of how to implement this check.

Creating the ingress ACL policy

Lines 6 to 15 show how an ingress ACL policy is created. At first it might be confusing that you use the  NUIngressACLTemplate object as this is not a template. In the VSD, a policy is always a template even if it is placed on an active domain. This template (and the other ACLs) is then used to compile a list of rules for each VM. This list of rules is used by the VRS to manage the traffic of the VM.

In this example we create a middle ACL policy which blocks all traffic and mac spoofing by default. We also make sure to activate the policy so that the rules will be applied when we commit the changes.

Creating the first ingress ACL rule

Lines 19 to 34 show how we first find the two entities between which the rule will be applied. In this case we want to create a rule which allows all traffic on port 3306 from the Web-Tier zone to the DB-Tier zone.

Next, we create a new  NUIngressACLEntryTemplate with the appropriate values. The first property we define is the action property. This can be two values: FORWARD or DROP. In this case we want to allow the traffic, so we use FORWARD.

We specify the ether_type and protocol to be IPv4 and TCP. By setting the source_port and destination_port  to appropriate values, we will allow traffic for the Web-Tier VMs to access the databases in the DB-Tier.

For the location_type (the source of the connection) the ZONE type is specified. We do the same for the network_type (the destination of the connection).  To define which zone to define as source and destination, we use the unique IDs of the two entities we gathered on lines 19 and 20 and insert them as the values for location_id  and network_id .

Finally, we tell the Ingress ACL policy to create a child from the defined Ingress ACL rule.

Creating the second ingress ACL rule

For the second ingress ACL rule, we will do something similar to the first, but we will define this rule to allow traffic on port 80 within the Web-Net subnet. This will allow the separate VMs in the Web-Net subnet to send HTTP requests to each other.

Lines 38 to 52 are very similar to the previous section. The major difference here is that the location_type and the network_type are now set to be of type SUBNET, of course the corresponding ID properties are also adapted.

Applying the changes

At this point, none of these ACL rules or the ACL policy is actually active, even tho we did define the policy to be active when we created it. It is created in a DRAFT  status:

This is because the domain is still in a state of changing the policies. To commit these changes and make them active, we have to tell the domain to apply the changes. This is done with another job, this time we use the APPLY_POLICY_CHANGES command on lines 55 and 56.

Best practice is of course to check if the job has finished successfully before continuing.

Background process

It is interesting to know what happens when entering the policy changes mode and how this might impact your scripts and tools. So we want to dedicate a short section on this.

Once you execute the job with the BEGIN_POLICY_CHANGES command, for each existing ACL policy, including its rules, a copy is made in the DRAFT status. These are different objects with different unique IDs than their active counterparts. It is important to make changes to these duplicate policies and rules instead of the actual live policies and rules.

At times, this can be confusing, when you are in the edit policy mode it is not allowed to edit the LIVE ACL policies or rules. The major consequence is that you need to get the correct ACL policy before editing it, being the one with the correct name and the policy_state set to DRAFT.

Below you can find a short example using iPython and its output to demonstrate this concept.

Some interesting things to note here:

  • The Bottom-AllowAll policy does not get duplicated

This policy is set on the domain template as a BOTTOM type of policy, which can not be changed in the domain context. It can only be changed on the domain template.

  • After entering the policy change mode, the Middle Ingress ACL appears twice, in different states. It is the one in the DRAFT state that can be changed.
  • Even without making any changes, if you apply the policy changes, the LIVE ACL policy gets deleted and the DRAFT one is changed to LIVE (the ID stays the same).

Query Parameters

For some objects to be gathered, special GET parameters have to be used in the HTTP request to the API. As the Nuage VSPK takes care of all the HTTP calls, we need another way of specifying these special parameters.

Enter query parameters! This is a new parameter called query_parameters which can be used with the get() and get_first() methods of fetchers. The content of this parameter is a dict which contains the appropriate key and value pairs. These get translated to GET parameters in the HTTP call to the API.

Gathering Statistics with Query Parameters

To demonstrate the query parameters, we will be investigating a script which gathers the statistics for a specified entity type. You can find the gather_statistics.py script on the Nuage Networks vspk-examples Github repository.

The script is called with a set of command line arguments which will specify for which type of entity it needs to gather certain statistics and for what time period.

We will only focus on a few interesting areas, feel free to investigate the rest of the script, of course.

Determining the correct fetcher and getting the matching entities

To demonstrate some of the quick flexible calls that can be made with the Nuage VSPK, you can look at line 189.

Here, with one simple call, we get all the entities matching the search criteria defined by the entity type and name (if defined).

Determining the number of data points

To get the right amount of data from the statistics, it is important to request the correct amount of data points. The number of data points depends on the collection frequency and the time frame for which the statistics need to be gathered.

By default the collection frequency is set to 60 seconds, which means you get a statistics value every 60 seconds. When you request more data points (for instance 10 in per minute), you’ll either get 0 values, or you will get strange results.

A way to change a collection frequency is to create a statistics policy on a given entity. Lines 235 to 242 first determines if the entity has a statistics policy defined. If it has, it will get the collection frequency.

Using either that collection frequency or the default (set on line 226), it will calculate the number of data points to gather.

Gathering the statistics with the query parameters

The actual use of the query parameters can be seen on lines 246-251.

Statistics need to be gathered for a certain period, which is defined by the time when the script is started and the time frame the user specifies through the command line (default is 1 hour). You also need to specify a list of statistic metrics you want to get.

All this information is added as a dict to the get_first() methods query_parameters on the entity.

Result

The below output is something you would see if you were to gather the statistics for all VMs for the metrics BYTES_IN and BYTES_OUT for the last 2 minutes.


Asynchronous calls

The whole Nuage VSPK can be used in an asynchronous manner where you do not wait for an action to finish executing before continuing with your script. In this case you can use callback functions which will be called when the action has finished with the result of the action.

To enable an asynchronous action, you need to specify the async=True and the callback  parameters on the action. The create_an_enterprise_asynchronously.py script on the Nuage Networks vspk-examplkes Github repository is an example on how to create an enterprise asynchronously. Be aware this script uses the older format of importing the Nuage VSPK, if you installed your own generated version, you might need to change the import.

The important part of the code exists in two sections:

  • Lines 13 to 19: This represents a callback function, which will be called when the action finishes
  • Lines 28 to 29: Here an enterprise is created. You’ll notice the two extra parameters when calling the create_child() method.

Asynchronous calls can be very useful when working on complex tools and they bring us to the next advanced concept: push notifications.

Push notifications

Push notifications allow you to monitor for certain or all events and trigger actions appropriate to the event. This differs slightly from an asynchronous action: Instead of registering a callback function for a single action, you create a handler which will be called on each event the VSD receives.

The show_pushcenter_notifications.py script in the Nuage Networks vspk-examples Github repository gives a basic example on how to use the push notifications. Be aware this script uses the older format of importing the Nuage VSPK, if you installed your own generated version, you might need to change the import.

Defining a notification handler

It all starts with defining a function which will handle the data from the notification. In the example, on lines 15-20, we create a function which will just print out the data into a pretty format.

Registering the handler

Once we’ve created the handler, we need to register it with the push_center  and start the push_center . This is done through lines 39 to 45.

From now on, the Nuage VSD is aware that for each event it registers, it needs to forward this information to the push_center  of that API connection. The push_center  will then call the handler with the data of the event.

Using push notifications with Jobs

Remember the jobs we talked about before? You have to remember to check if the job has successfully finished before you can continue handling the result of that job.

Jobs also create events which will get pushed as a notification, so potentially, we could create a handler which specifically looks for those events. If we change the handler to the following code, we’ll get a nice message when a job is done.

Let’s test this with an export job on a domain while we run the push notification script:

As you can see, you’ll get regular updates on the status of the job. We could extend the handler to do all sorts of thing with the result of the job.


Combining the Nuage VSPK with other SDKs

We’ve seen a lot of ways to use the Nuage VSPK as a standalone SDK to interact with your Nuage VSP environment and do lots of interesting tasks. Things can get even more interesting when you combine the Nuage VSPK with other systems SDKs.

You could write a script which deploys a full enterprise configuration from scratch in the Nuage VSP and simultaneously populates it with a set of VMs on ESXi or Openstack. Another possibility is to create a script which deploys a VM from a template in vCenter where you can select the enterprise, domain, zone, subnet inside your Nuage VSP, the script can then write those values into the advanced configuration parameters of the VM in vCenter before booting it (this script actually exists).

To demonstrate this functionality, we’ll have a look at a script called vcenter_vm_name_to_nuage_policygroups.py. As the name suggests, this script will look at the name of a VM inside vCenter and depending on a list of regular expressions (specified through a CSV file) will assign one or more Nuage Policy Groups to those VMs in the Nuage VSP. This script combines the Nuage VSPK with the vCenter SDK, using pyvmomi.

Once more we’ll go through the important sections of the script.

Gathering VMs to check and retreive Nuage metadata for each VM

The user can specify for which vCenter clusters the VMs need to be assigned to policy groups. The VMs are gathered through the vCenter API on lines 256 to 259.

Once there is a list of VMs to check, the Nuage metadata of the VM is checked and verified on lines 281 to 293.

Finding the appropriate vPort for each VM

Policy groups are set on vPorts, so for each VM we need to get the vPort. For this, we first get the MAC address of the virtual network interface on the VMware VM on line 319 through the vCenter API.

Using this MAC address, we retreive the VM Interface from inside the Nuage VSP on line 328. From the VM Interface we can easily get the vPort, which is shown on lines 334-336.

Matching VM name to Policy Groups

On lines 344 to 350 we match the VM name using regular expressions to the specifications CSV file. This CSV file specifies that VMs which match a certain regular expression should get a certain Policy Group assigned. A VM can have multiple matches.

The structure of this CSV is pretty simple:

An example which we’ll use later on:

Assigning the Policy Groups to the VM interface

On line 354 we call the update_nuage_policy_group() function which is responsible of assigning the correct Policy Groups to the VM interface.

This function is defined on lines 88 to 132 and contains the following interesting sections:

  • Lines 104 to 109: If the existing policy groups need to be kept on the VM interface, we need to add them to the list of Policy Groups of the VM interface first.
  • Lines 111 to 124: For each policy group that needs to be assigned, we actually check if it exists in the domain to which the VM interface belongs.
  • Line 127: This is the crucial part where we assign the Policy Groups to the VM interface through the Nuage VSPK.

The Assign method

You are probably wondering what this new assign() method does as this is the first time we encounter this method during this series.

The assign() method is used when you need to create a link between entities which are not in a normal parent-child relationship.

It could be described as a many to many relationship between certain entities. For instance: in this example, we assign Policy Groups to VM interfaces.

A Policy Group is not a child of a VM interface, as this would mean a Policy Group could only be assigned to one VM interface. Neither is a VM Interface a child of a Policy Group, because a VM interface could only have one Policy Group, and it would lose its connection to the VM owning that interface.

So the assign() method was introduced to create the relationship between these kind of entities.

It needs two arguments: a list of objects and the class of objects the list contains.

In our example the list of objects is the list of Policy Groups to assign and the class of object is the NUPolicyGroup class.

An important note on the workings of the assign() method: It will replace the existing links, not add. So if you want to add a link, you first need to get the existing objects as a list, and append the new one to that list before handing it over to the assign() method.

Another example of entities that use this method, is users in a group. You assign NUUser objects to a NUGroup.

Result

By using the CSV file that was mentioned before and by running the script on all our VMs in our compute cluster, the VMs with ‘PRD’ in their name will get the Policy Group ‘Production’ assigned, VMs with ‘DEV’ in their name will get the Policy Group ‘Development’ assigned, and so on.

A VM called ‘PRD-WEB01’ will have two Policy Groups assigned: Production and Web. A VM called ‘DEV-DB01’ will have two different Policy Groups assigned: Development and Database.

These Policy Groups can be used to define ACL policies and rules. This makes it easy to create secure networks where the name of the VM dynamically assures the correct ACLs to be applied.

The future: Support for more languages

As discussed in the previous post in this series, the Nuage VSPK is also available for Go. This will not be the only language that will get support for the Nuage VSPK as just this week, an additional feature has been added to Monolithe to allow for plugins which would generate the Nuage VSPK for different languages.

Other than that, with the continuous developments and improvements from the Nuage R&D, VSPK team and especially yourself, the Nuage Networks vspk-examples Github repository will be filled and extended with new cool tools and script to use with Nuage VSP!

Enjoy your scripting freedom!

Scripting with Nuage VSPK – Part 1 – Introduction & basic examples

Scripting with Nuage VSPK – Part 1 – Introduction & basic examples

Today i want to talk about a Nuage VSP feature which allows you to create your own tools to interact with your Nuage VSP environment: The Nuage VSPK. The Nuage VSPK uses the Nuage VSD REST API to do all its actions, so if you are familiar with the REST API, you will quickly grasp the use of the Nuage VSPK.

The Nuage VSPK is available in two flavors: a Python flavor and a Go flavor. This last one was released last week, for now, we will cover the usage of the VSPK using the Python flavor.

I will cover this aspect in multiple parts. This post will cover the installation of the VSPK and its structure, before leading up to the write-up of three scripts that:

  • Show the structure of a particular domain
  • Get an overview of all used Floating IPs
  • Gather the events/logs for a particular enterprise

At the end there will also be some pointers on where to find a full API reference and where to find more examples.

In the next posts you can expect some more complex examples that show you how to listen to VSD events or how to combine the VSPK with VMware vCenter API to implement a dynamic policy group mapping.

This post is a copy of a blog post of mine on the Nuage Community.

Happy reading !

Installation

To install the Nuage VSPK, the easiest way is to use pip. Pip allows a user to quickly install a Python package with all its requirements. For the Nuage VSPK, the command is simple:

If you feel a bit more adventurous and would like to use the latest development release, you can also build your own VSPK from scratch using the Github repositories. I will not go into to much details on this, but below is a Shell script that does it all for you:

Apart from some minor improvements, there is one major difference between the current pip release and the latest development release: the way to import the Nuage VSPK package has been simplified. In the next section I will show you this difference. All scripts mentioned in this post will also have a mechanism to import the Nuage VSPK in both situations automatically.

In the future, the pip release will of course be updated and also support the simplified import.

Getting started

General tip: Try using iPython

If you want to follow the examples below, try using iPython. iPython is an interactive Python shell environment with tab completion and loads of other features. This allows you to investigate objects quickly and get a good feel for the structure of the Nuage VSPK and the differnet types of objects it contains.

Importing the Nuage VSPK package

The first thing you need to do to start working with the Python Nuage VSPK is import it into your script. As mentioned before there is a slight difference in how this is achieved depending on the version you are using.

Connecting to the Nuage VSD API

Now that you have the Nuage VSPK package loaded, you need to connect to your Nuage VSP environment. This is done by setting up a connection to the Nuage VSD API. In the example below, i will connect to a VSD with IP 172.16.1.20 and with the csproot credentials.

In the background, the Nuage VSPK will contact the VSD API and request an API key for the user. It will store this API key in its connection object and use it whenever it needs to talk to the API.

Of course, you can also use a different user, possibly one that is only part of one enterprise/organisation. This will limit the Nuage VSPK and as a result the script to only have access to certain objects and actions. For instance, if you initiate the connection with a user that only has access to one enterprise, it will not be able to create other enterprises, or create, read, update or delete objects inside different enterprises from its own.

The structure

The Nuage VSPK has a tree-like structure in which there is a root object which has a set of possible children types. A list of each of those types can be gathered by using the appropriate fetcher. Each child object follows the same concept: It has a set of possible children types which can be gathered by the appropriate fetcher

The root object: user

The root object of this tree is the user object. This object represents the user that is used to log in to the Nuage VSD API and which is used to execute whatever action you want to achieve.

The user object is part over the connection object:

Types of supported children objects

To find out what types of children a certain object supports, you can use the children_rest_names property of a class or an object:

In the above example I’m showing the possible children of a Subnet, some of these types can also be children of other classes or objects. For instance the statistics class can be a child of many different classes or objects.

Fetching children of a certain type

An object will have fetchers to fetch the children of a certain type. These fetchers will have the plural name of the REST name you see in the children_rest_names output. To fetch all the enterprises that the current user has access to, can be done as follows:

This will produce a list of Enterprise objects. If you want to print out the name of all Enterprises for instance, you could use the following code:

It is also possible to apply a simple filter to the get()  method, this filter will then limit the returned list of enterprises to those matching the filter:

The above example also introduces the get_first()  method which allows you to fetch only the first entry. The filter is optional, but advised.

CRUD operations

Creating an object

Creating an object is done using the create_child()  method on a parent object that supports the object you want to create as a child. By using the create_child() method, the object you are creating also gets its properties like the unique ID updated so it can immediately be used.

The above example will create a new Enterprise in the Nuage VSD with the name ‘VSPK Enterprise’. To find out what properties are available for a certain class/object, you can check the Nuage VSPK reference documentation. If you forget to set a mandatory property, the Nuage VSPK will throw an exception. The following example is taken from iPython:

Choosing the parent object

It is mandatory to use the appropriate parent object, to find out what the appropriate parent object is to create a child object in, look at an existing object of the child object type:

As you can see in the above example, even thou i request all domains from the root (which will return all L3 domains from all the Enterprises the user has access to), the domain object will return ‘enterprise’ as its parent_type. This tells you to use the create_child()  method on an enterprise object.

If you create an object on the wrong parent, you will get a ‘409 – Method not allowed’ error.

Reading an object

Once you have created an object, you might come in a situation where the object gets changed through some other means (for instance, through the GUI by a user). The object inside your tool will contain the old information and won’t be updated live when changes are made through other means.

Returning to our Enterprise we created in the previous section, I have changed the name of it to ‘VSPK Enterprise – Changed’ through the GUI. In my script, the name is still presented as the old one. To get the latest information from the Nuage VSD API, the fetch()  method can be used.

Updating an object

After fetching the latest information of an object, you can make changes to the properties. Again, these changes are only happening locally to the object and are not yet synchronized to the Nuage VSD database. To push these changes to the Nuage VSD database, you need to use the save()  method.

Deleting an object

To delete an object, you use the delete()  method on that object. This will immediately remove that object from the Nuage VSD database, unless it has children you need to remove first. For instance: you can not remove a subnet when there are still vPorts present on that subnet.

The object inside your Python environment will still exists. A fetch on the object will fail as it does not exist in the Nuage VSD database anymore.

Bringing it all together

To bring everything together in some basic examples to show how easy it is to gather information from the Nuage environment. In a later post, we will also start creating objects.

Printing out a basic structure of a domain

Let’s go over this script step by step:

  1. Import the required packages: sys & the Nuage VSPK
  2. Setting up a connection to the Nuage VSD API
  3. Find the domain called ‘VSPK Main domain’
  4. Get all the zones of the domain, and for each:
    1. Print the name
    2. Get all the subnets of the zone and for each print the information
  5. Get all the Ingress ACL policies, and for each:
    1. Print the name
    2. Get all the Rules of the policy and for each print the information
  6. Get all the Egress ACL policies, and for each:
    1. Print the name
    2. Get all the Rules of the policy and for each print the information

The output would look like this:

Gathering an overview of all used Floating IPs

Another script we can have a look at, is the fip_overview.py script which can be found on the Nuage Networks VSPK Examples Github repository. This script will provide the user with an overview of all the Floating IPs that are in use in the enterprises the user has access to.

The script contains a lot of code for argument  logging, and argument and output handling, which i will skip over. You can follow along with the mentioned lines in the code located at https://github.com/nuagenetworks/vspk-examples/blob/master/fip_overview.py

  • Lines 32-35: Importing the Nuage VSPK package
  • Lines 100-109: Establish the connection to the Nuage VSD API
  • Lines 119-137: Collect all floating ips for all the enterprises the user has access to and for each:
    • Line 121: Get the associated vPort
    • Line 122: Get the associated VM interface from the vPort
    • Line 123: Get the VM associated with the VM interface.
    • Lines 125-137: Handle the information into the correct output

The basic result should look more or less like:

Gathering the events/log from an enterprise

The Nuage VSP solution will log every event that happens on an enterprise, this includes all creations, updates and deletions of objects. In this section I will discuss a script which will gather these events and provide a nice output.

The script can also be found on the Nuage Networks VSPK Examples Github repository and is called events_overview.py. You can follow my explanation by looking at the code located at https://github.com/nuagenetworks/vspk-examples/blob/master/events_overview.py

Again, I will only go into detail on the important bits from the Nuage VSPK standpoint, as the other sections are less relevant and just focus on argument and output handling.

  • Lines 44-47: Importing the Nuage VSPK package
  • Lines 105-121: Determining the time difference to use
  • Lines 136-145: Establish the connection to the Nuage VSD API
  • Line 157: Set the time after which the events should have happened to be gathered (using the time difference)
  • Lines 160-181: For each enterprise:
    • Lines 162-181: Gather all events that are later than the time determined in line 157 and at the information of each event to the output

The basic result should look more or less like:

API Reference

An extensive overview of the API and all its objects and fetchers can be found in the Nuage VSPK 3.2 API Reference.

If you want some more details on what properties are mandatory for a certain object, you can check the REST API documentation, which can be found on each Nuage VSD using the following format:  https://<VSD-IP>:8443/web/docs/api/V3_2/API.html

Be aware that the Nuage VSPK uses the Python best practices, which means that the camel-case property names of the REST API are replaced by lowercase, underscore-separated property names. For instance, the templateID property of a domain in the REST API is equivalent with the template_id  property in the Nuage VSPK domain class/object.

Nuage VSPK Examples Github repository

Now that you have seen the basics of the usage of the Nuage VSPK, you can start and create your own scripts. Nuage Networks has a public repository full of examples. Feel free to create your own and you can create a pull request on Github to get your cool examples in there!

Next time we will go through a couple of the more complex scripts that are present in that public repository and how you can interact with other systems like the VMware vCenter API to combine information from both systems and create powerful scripts!

Update: Thanks to Antoine Mercadal to provide a faster and improved script to install the Nuage VSPK from the Github repositories.

pyVmomi 6.0.0, vSphere 6.0 and SSL

VMware released a new version of pyVmomi to better integrate with vSphere 6.0. This release introduces a change on the creation of an SSL connection. After struggling with some issues on this change, I wanted to write something down for future reference.

On the GitHub documentation it says pyVmomi 6.0.0 supports python 2.7, but it would be more accurate to say pyVmomi 6.0.0 supports python 2.7.9+, as in python 2.7.9 the ssl.SSLContext object has been introduced. This object allows you to specify a verification mode and a SSL Protocol. This object is needed if you want to connect correctly to the vSphere API.

You can check your python version with  python --version

Workaround for python versions below 2.7.9

To get everything working in python versions below 2.7.9, the easiest way is to downgrade pyvmomi to 5.5.0.2014.1.1. To achieve this, do the following:

This will downgrade your pyvmomi to a workable version. This version also doesn’t force SSL certificate verification, so your code can be very simple:

Working with untrusted SSL connections with pyVmomi 6.0.0 and python 2.7.9+

If you want to connect to a vSphere 6.0 API without certificate verification using pyVmomi 6.0.0 and python 2.7.9+, you will have to create a new SSLContext which disables the certificate verification. Using pyVmomi’s  SmartConnect() , there is now a new attribute you can pass, called  sslContext . Below is an example on how to achieve this.

Support for both versions

If you write scripts which can run on different python and pyVmomi versions and you want to keep supporting both, you could do so by looking at the following example:

I have updated all my pyVmomi scripts on my GitHub repository to start working with both version with the above fix.

 

 

Upgrading vCenter Server Appliance 5.5 to 6.0 using CLI

Upgrading vCenter Server Appliance 5.5 to 6.0 using CLI

In 6.0 the standard installation and upgrade of the vCenter Server Appliance has changed to an ISO which you can mount in Windows. This ISO provides a web interface. This interfaces asks you to install the Client Integration Plugin 6.0, after which you can use the web interface to install or upgrade your vCenter Server Appliance.

Of course, this gives us Unix users another hurdle to overcome with installing the vSphere environment. Also, the Client Integration Plugin has some issues working with the latest versions of Chrome and Firefox. Lastly, hardly anybody likes using a web interface for this kind of installations.

Luckily, VMware has been kind enough to provide us with a CLI installer as well! I’ve seen a couple of blog posts about using the CLI installer to install a new VCSA, but not as much about upgrading an existing VCSA. So i decided to do a little write-up providing some examples.

Overview of the upgrade

The tool will use a json template file containing all the information to perform the upgrade. It uses the information to first deploy a new VCSA VM on a target host. This new VCSA VM is provisioned with a temporary network. It will then migrate all the data from the existing VCSA to the new one. Once this is done, it will shut down the existing VCSA and reconfigure the network on the new VCSA to take all the settings from the old VCSA.

JSON template

Below is an example of a JSON template file that can be used to upgrade a 5.5 VCSA to a 6.0 VCSA. There are more templates inside the ISO (folder vcsa-cli-installer/templates) which you can use, but i’ve noticed some issues with these templates missing important sections.

Of course I kept some values to the default, but i’m sure you can figure out what to change where. There are a couple of important mentions I would like to mention:

  • username and password in your source.vc > vc.vcsa section have to be the SSO administrator user and password (default user = administrator@vsphere.local, default pass = vmware)
  • target.vcsa > appliance > name value is the name the VM will get, this has to be unique in your environment, so it can not be the same as your current VCSA, it has no impact on the hostname
  • target.vcsa > sso > site-name value is just for your SSO, it has to be filled in, but just do something simple (‘First-Default-Site’ should be fine)
  • target.vcsa > temporary.network: This is just temporary for during the upgrade/migration. After the migration, all the network sections are taken from the old VCSA.
  • target.vcsa > esx : This is the info of the ESXi where you want to place the new VCSA VM, can be the same as the source, can be a different one. Just make sure the info is correct (if confused with the POD43 file: my local datastores have been named the same as the ESXi IP, to easily differentiate.)

Running the CLI installer

I will run this installer directly from the ISO mounted on  /mnt/vcsa  on a Linux machine.

I would first suggest to do a dry run, you can do so with the following command:

This command will verify the configuration and all the connectivity. It will return a list of warnings and errors. Some of the more common warnings and errors you might encounter:

  • Warnings about Postgresql password that will be the same as the root password of the new VCSA, this can be safely ignored.
  • Warnings about port 22, this can also be safely ignored, just make sure the old and new VCSA’s can communicate through SSH
  • Errors about SSO and certificates: This will prevent any upgrade, so this is something you will have to look at. Most of the time it’s an indication that your certificates were generated with a different hostname or IP than currently used. You can rectify this by going to the 5.5 VCSA’s administration web interface check that the hostname, IP and DNS settings are all correct and regenerate the certificates if needed (this requires a reboot).

After you fixed any errors, you can run the command without the  --verify-only option:

This will start the upgrade and migration, just follow along with what is happening, you get some good info on the progress. It can take a while to finish (half an hour to an hour, easily. If you have a slow connection between the machine you are running the command and the appliances & esxi’s, it might take longer for the data transfers)

Nuage Networks releases its Virtual Service Platform SDK

Nuage Networks releases its Virtual Service Platform SDK

About five months ago, I decided to make a big change in my professional career and join Nuage Networks (a wholly owned subsidiary of Alcatel-Lucent) as a New Product Introduction Engineer. In the past four months, I realised that this might have been one of the best decisions i made in my life. I’ve been working with extremely intelligent and hard working people who are all very friendly and understanding of the new guy. I learned a lot, and still have a whole lot more to learn!

On thursday, Nuage Networks CEO Sunil Khandekar announced the release of the VSPK or Virtual Service Platform SDK at Network Field Day 10. This SDK allows anybody to access the full Nuage Virtual Service Platform using Python.

As it stands, the Nuage VSP already had a rich set of management tools, including a great web interface and an OpenStack integration. This however opens the doors to a completely new set of possibilities. It makes it easy to integrate your own Cloud Management System with Nuage VSP, or build your toolset to automate certain tasks in your datacenter, or write your own reporting tool which gathers information, or …

Take a look at the great documentation and the examples!

(And no, i had nothing to do with this, these are all those intelligent and hard working people I was talking about earlier ;))