vCloud Director Connector
The vCloud Director connector can retrieve usage from your instance of vCloud Director and convert that usage information into CloudBilling purchases.
Supported versions
The vCloud Director connector supports versions 23.0 through 32.0 of the vCloud Director API. At the time of writing, this means versions 8.2 through 10.3.2 of vCloud Director, but it should work with any vCloud Director version that offers a supported API version.
Conceptual setup and required permissions
The connector runs on the CloudBilling infrastructure and connects to vCloud Director once per day in the evening, to retrieve usage. It does this by using the vCloud Director API which needs to be accessible by CloudBilling. A user needs to be set up on vCloud Director and CloudBilling has to be configured to use this user to connect. The connector uses the adminEvents extension query to retrieve usage information and the user therefore needs “system” permissions to successfully run.
Customer Mapping and Purchase Generation
Each vCloudDirector organization can be mapped to a CloudBilling customer. Meaning that the information contained within a vCloudDirector organization should belong exclusively to a single customer. Multiple organizations can be linked to the same customer, but an organization cannot be split over multiple customers.
For each organization, purchases are generated for every VM inside of every vApp inside of every vDC for the following properties:
vCPU
The vCPU resources are measured in number of cores. Purchases are only generated for vCPU for the periods of time the VM is powered on.
Memory
Memory resources represent the amount of RAM assigned to the VM and is measured in GiB. Purchases are only generated for memory for the periods of time the VM is powered on.
Storage
Storage is measured in the number of GiBs allocated to the VM. Purchases are always charged, regardless of whether or not a VM is powered on or off.
Operating System (OS)
A purchase is generated for the operating system type specified for the VM. This is based on the information configured for the VM, not on the actual contents of the VM. These purchases are always generated, regardless of whether or not a VM is powered on or off. However, the quantity of these purchases will be 1 for the periods of time the VM is powered on and 0 for the periods in which it is powered off.
VM
A purchase is generated for the presence of the VM itself. This purchase is generally used as a basis for things like management fees. These purchases are always generated, regardless of whether or not a VM is powered on or off. However, the quantity of these purchases will be 1 for the periods of time the VM is powered on and 0 for the periods in which it is powered off.
These purchases all have metadata indicating the vDC name, vApp name, VM name, hostname, os type, network info, storage profile name, where applicable.
The connector runs once per day and uses the current state in combination with events to generate a stream of purchases. This means it will generate an accurate representation of the VM over time. For instance, if the last run of the connector saw a VM had 8GB of memory, and now it sees that same VM has 12GB of memory the events will be used to see when this changes occurred. Purchases will then be generated to show 8GB from the last reading till the change event and 12GB from the change event till now. More complicated changes with multiple events or reverted changes to properties are also detected and proper streams of purchases generated. This allows for accurate pro-ration to be performed inside of CloudBilling to ensure invoices are properly calculated.