Created by c_shanklin 
The attached script allows you to register a plugin with VirtualCenter using the VI Toolkit (for Windows).
You can either paste it into your PowerShell session window or you can "source" it into your environment using the . operator (i.e. ". .\registerExtension.ps1").
The script provides 3 functions,
After registering a plug-in, log out of the VI Client (if you are logged into VirtualCenter) and log back in, and you should see your plug-in registered under the Plugins tab.
You can either paste it into your PowerShell session window or you can "source" it into your environment using the . operator (i.e. ". .\registerExtension.ps1").
The script provides 3 functions,
- Get-Plugin: List all installed plug-ins.
- Remove-Plugin: Remove an installed plug-in.
- New-Plugin: Define a new plug-in.
After registering a plug-in, log out of the VI Client (if you are logged into VirtualCenter) and log back in, and you should see your plug-in registered under the Plugins tab.
Average User Rating
(0 ratings)
Comments |
More by c_shanklin
Developer SDKs & APIs
- vCloud API
- vNetwork APIs
- vSphere Web Services SDK
- vSphere SNMP MIB
- VMware Studio
- vSphere Client Plug-ins
- Virtual Disk Development Kit
- VIX API
- vSphere Guest SDK
- vCenter Orchestrator
- CIM SDK (SMASH, SMI-S)
- vSphere SDK for Perl
- vCenter Lab Manager API
- VProbes
- vSphere SDK for Java
- Open Virtualization Format Tool
- Automation Tools
- vSphere PowerCLI
- vSphere CLI
- vSphere Management Assistant
VI Client plug in registration problem:
This script fills in a description object ($desc) and sets its label and summary variables. It then passes the description object to 1) the extension 2) the extension's client info object and 3) the extension's server info object.
This is how it appears it should be done based on the documentation, however the problem is that the client and server children objects do not receive a proper description. The result of this is the VI Client displays 'viClientScripts' as the description which looks ugly. You can verify using the managed object browser, navigating to the ExtensionManager object.
I've reproduced this with a C# application as well, so the bug is probably in the VISDK itself. How can I go about getting this fixed?