Developing your first VCenter plugin

In a massive data-center deployment, often there are different groups of system administrators who manage different components of a data center. As the concept of cloud emerges, these management silos are inefficient and a single panel management is a need.

VMWare VCenter virtualization management platform helps to monitor, provision and manage a virtual data center from a single console. VCenter plugins provide a way to integrate OEM product or storage management capabilities in to the VCenter management console. Leading vendors like Dell, NetApp, and EMC provide plugins that tightly integrate their hardware management with VCenter.

The below describes the preliminary aspects to consider while developing the plugin.

1. Level of plugin integration

There are two levels of integration possible:

Loose Integration or Tight Integration

A loose integration can be a simple script (jsp,, CGI ,html pages) integrated in to the VCenter management console. The look and feel of the plugin User Interface components may not be the same as the standard VCenter console say wizards, data grids etc may be difficult to achieve using scripts. However the development effort is less if there is an existing web application to manage the OEM or the storage product under consideration.

The solution will be hosted on the Gujarat State Datacenter GSDC, one of the best of the breed data centers with VCE(Virtual Cloud Environment)/VPC (Virtual Private Cloud) solutions.

Right from the VCenter libraries used to develop, to the deployment strategy, these two integration types differ a lot.

Choosing between these two integration types is the first step towards developing a plugin.

This link suggests the level of integration based on:

  1. Availability of the web application
  2. Development Effort
  3. Investment/Maintenance Window

2. VCenter User Interface Extension points

Short list the features of the OEM or the storage product under consideration that has to be exposed in the VCenter and decide the user interface references within the VCenter console.

Use this guide to convert these User Interface references in to VCenter extension points.

3. Run time data vs data across sessions

The real challenge of developing a plugin starts with designing the data model & deciding where this data has to be stored in the VCenter’s Virtual Infrastructure (VI) Object model. VCenter maintains its Virtual Infrastructure(VI) data model in the form of managed entities & managed objects.

Managed Entities include

  1. Folder
  2. HostSystem
  3. ResourcePool
  4. Datacenter
  5. ComputeResource
  6. VirtualMachine

Managed Objects include:

  1. VirtualMachineSnapshot
  2. Datastore
  3. Alarm
  4. Network

For more information on VI Object model, refer to: VMware vSphere Blog: Introduction to the vSphere API Part 2: Object Model

While it is possible to store inventory specific information in one of the standard managed object fields, we might encounter a situation where the data cannot fit in to these standard fields. In such a case, dynamic fields can be used. However, these fields are not persisted.

Custom fields can be set for the managed entities and can be selectively displayed in the User Interface. But it is possible to set custom fields for managed objects and hence the below mentioned alternatives might be handy in those situations:

a. Use hidden Tags property/methods of a VI Object

Tags property of a VI object can be used to classify a set of VI objects or persist data related to a VI object across client sessions. Method to update this property is hidden as of now. This link gives a way to add/update/delete this hidden property.

b. Use a repository outside VI Data model

Data can be stored in the VCenter database or in a flat file that can be accessed via a web application. With the former approach, based on the VCenter database server, the authentication methods on the database server has to be configured for the remote access. In the later approach, if the VCenter web application is installed, then the same container can be used to deploy a web application that synchronizes the access to the flat file.

4. Scalability & VCenter Maximums

Review the maximums allowed in a VCenter/VSphere/ESX(i) environment and decide how the data has to be structure.

5. Replication & disaster recovery of the plugin components

While the VCenter server software, license server and the database can be backed up and recovered by following the VMWare redundancy guidelines, the back up & recovery of any plugin data outside the VCenter environment has to be paid attention.

6. Storage profiles & VASA

Storage profiles help to group the datastores and provide compatibility suggestions while creating the VM disks. There are two types of storage capabilities available today: System defined and user defined. The user defined capabilities/profiles can be set in the VCenter Console. System defined capabilities/profiles are defined by the underlying hardware providers. It is possible to set the system host capabilities for hosts using SDKs and scripts whereas for storage there are no direct VI APIs available. The storage providers have to expose their hardware capabilities using VASA specification.

7. Packaging & Licensing

In case of a script based plugin, the plugin can be deployed as a WAR file under the VCenter server application. In case of a C# application, the plugin bin folder has to be placed VCenter client installation path. In order to simplify the plugin installation, the C# bin folder can be converted to a self-extracting bin folder and placed under the VCenter server web application. A reference to the plugin exe can be provided in the VCenter web application index page.

The client systems can open the web based VCenter application and download the plugin.


The above stated considerations are preliminary and the complexity of the development can vary across different plugins.

Be the first to comment

Leave a Reply

Your email address will not be published.