When a plug-in includes auxiliary servers, the auxiliary servers must be registered with vCenter Server, in the same Extension record as the primary server. When the plug-in user interface sends a request to an auxiliary server, the request passes through the vCenter Server reverse proxy, so that the browser treats it as having the same origin as the primary server.

The following illustration shows a hypothetical use of auxiliary plug-in servers that provide specific services supplemental to the functions of the primary server. The primary server provides the overall plug-in configuration in the manifest file, as well as the HTML components for the plug-in user interface. Separate concerns are handled by the auxiliary servers.

Figure 1. Auxiliary Server Data Paths
This diagram shows a plug-in with two auxiliary servers and the communications between them and their environment.

This hypothetical plug-in implements a Chassis abstraction, which represents a physical enclosure that contains a number of blade servers. The blades run instances of vCenter Server. The plug-in user interface presents a Chassis and its vCenter Server instances as related objects in the inventory.

Auxiliary server 1 (P1A1, in orange) interfaces with the vCenter Server instances and data centers encompassed by the plug-in. The auxiliary server uses the Web Services API to collect data from the vCenter Server instances, which it returns to the plug-in user interface. The plug-in user interface uses instance-specific data to supplement graphic and tabular displays in the UI.

Auxiliary server 2 (P1A2, in orange) maintains a high-performance interface to a database of Chassis objects and links to related objects that represent the physical blades and VMware products that run on them. The plug-in uses this data to fill out a display of Chassis objects with related blades, vCenter Server instances, and other managed entities that populate VMware data centers.