In this blog post, I will show all of the steps required to operationalize vCloud Usage Meter 4.3, or UM, within your data center. With the end of availability of Usage Meter 3.6.1, it is imperative that all VMware Cloud Providers start a plan of action to migrate to the 4.3 codebase.
Moreover, I’ll provide the full context on how UM works with Usage Insight and the VMware Commerce Portal.
While this is a long blog post, it’s important we highlight all of the necessary steps within the VMware consumption operational model for VMware Cloud Providers.
- Usage Meter 4.3 Architecture
- VMware Cloud Provider Terms
- Usage Meter 4.3 Operating Modes
- Initial Usage Meter 4.3 Deployment
- In-Place Upgrade from Usage Meter 4.2
- VMware Commerce Portal Registration
- Usage Meter 4.3 Endpoint Configuration
- Typical Monthly Activity
Usage Meter 4.3 Architecture
To start, let’s look at a drawing that shows the fundamental differences between 3.6.x and 4.3.
Usage Meter 4.x is a Photon-based appliance that focuses on several key capabilities:
- Hardened platform that aligns to our other VMware appliance solutions
- Minimize operational overhead – aligns the UM Operator and Billing Contact to specific responsibility sets
- Cloud Report Generation – since we are moving the report generation to VMware, we can introduce new products and/or pricing changes in a more dynamic fashion.
The key delineation is the last point. Previously with 3.6.x, metering and reporting happened in an encapsulated environment. Moreover, this operating model was prone to human error and requires a high-level of effort when introducing new products or pricing changes. By moving the report generation responsibility to VMware, this provides everyone with less operational overhead on a monthly basis.
Usage Meter 4.3 Considerations
- VMware does not receive any personally identifiable information (PII). The metric data is stored in a one-way hash that is generated by the Usage Meter appliance and cannot be decoded by VMware.
- Quite frankly, all we are looking for is vRAM configuration, runtime, and the product features used during this state.
- This can all be verified by looking at the metric data within the appliance CLI and/or viewing the VM History Report within Usage Insight.
- It does not matter if you have 1 or 100 Usage Meter instances. Usage Insight will auto-aggregate all metric data and display this at the beginning of the calendar month. No more need to manually pull reports, bust out Excel formulas, and so forth.
- Using 4.x requires the use of the new Flex bundle model. Please note that you will need to adopt this if you are an existing provider.
Our goal is to decrease the monthly operational burden of a VMware Cloud Provider. Usage Meter 4.x is on that path. I have seen how the use of Usage Insight has removed close to 85 to 90% of the monthly burden for a provider.
Before, we get started, let’s cover a few terms if you’re new to the VMware Cloud Provider Program.
VMware Cloud Provider Terms
If you’re new to the VMware Cloud Provider Program (VCPP), you might be overwhelmed by the different terms and solutions we use. Let me try to boil these concepts down.
Usage Meter is just a VMware virtual appliance that resides within your vSphere environment. This will be metering the VMware solutions you utilize within the VCPP model. Here’s a screenshot of what the appliance looks like (from my lab environment):
Usage Meter can connect to multiple vCenter instances, along with a multitude of other VMware solutions (NSX-v, NSX-T, vRNI, VCD, etc.). This table goes over many of the new products added. We can also deploy several Usage Meter appliance based on availability zones, network segmentation, and so forth.
The VMware Configuration Maximums lists out the tested guidelines for Usage Meter 4.3
VMware Commerce Portal
Once you are part of VCPP, you will receive access to the VMware Commerce Portal. This is where you report all consumption data. Authenticated users (based on roles/permissions) can see the contract, authenticated users, along with providing monthly reporting information.
From a contract perspective, one can see the identifiable information –
However, as stated prior, this is where we register our Usage Meter instances for automatic reporting –
Last of all, the point of contact can add new users that have specific rights to the VMware Commerce Portal –
VMware vCloud Usage Insight
Usage Insight is the service that aggregates all registered UM instances for automatic reporting. At the beginning of every calendar month, Usage Insight processes the final metric data and sends it over to the VMware Commerce Portal for validation and acceptance.
However, a provider operator can view the Monthly Usage Report along with the VM History Report from Usage Insight –
Provider UM Operator
The UM Operator is responsible for deploying and managing the Usage Meter virtual appliances. Typically, they will have access to the VMware Commerce Portal and also established the Usage Insight organization. They would work with the Provider Billing Contact for any manually metered products that are not in scope of Usage Meter.
Provider Billing Contact
The Provider Billing Contact is typically responsible for the VMware Cloud Provider contract and monthly billing usage. They would verify the usage within the VMware Commerce Portal and submit accordingly to the aggregator for approval.
Usage Meter 4.3 Operating Modes
As of today, there are two modes of operation for Usage Meter 4.3. While Mode A is generally available, Mode B is only approved upon request from GSS.
Mode A, or the normal mode of operation, is what majority of our VMware Cloud Providers use today. This is the least amount of effort as all metric data (in one-way hashed form) is continually sent securely to Usage Insight for processing.
Once the final data transfer happens, Usage Insight processes a final report and sends it over to the VMware Commerce Portal. The Billing Contact then confirms the aggregated results and appends/revises if required. Once submitted, they work with their aggregator on payment.
UM Operator Monthly Level of Effort: Low to None
Billing Contact Monthly Level of Effort: Low
Mode B operation allows for a provider to meter in a disconnected/air-gapped environment. In essence, the UM Operator downloads a Usage Bundle from each UM appliance and manually uploads it to Usage Insight. The UM Operator can do this throughout the month or execute this once a full calendar month has been completed.
As stated prior, Mode B operation must be approved by VMware GSS.
The UM Operator will see different results based on the selected month of data. For example, I am writing this blog post with a few hours left in November. If I select the November reporting month, I will see a message that states this will not be a full month of data –
However, selecting October 2020 does not show this message –
Once all data has been uploaded (and must be done before the 3rd of the month), Usage Insight will generate and aggregate the final report and send it to Commerce Portal. From there, the Billing Contact processes it accordingly.
UM Operator Monthly Level of Effort: Low to Medium (depending on how many appliances)
Billing Contact Monthly Level of Effort: Low
Initial Usage Meter 4.3 Deployment
I’ve covered the typical Usage Meter 4.x deployment in my previous post. However, I am going to reiterate a few items and important steps.
In either deployment use case (net new or replacing an existing 3.6.1 instance), we must deploy a net new Usage Meter 4.3 appliance and register it to the VMware Commerce Portal.
From there, we can establish our products for metering or use the “migrateum” tool to migrate the existing configuration set to this new 4.3 instance. More information is posted on the migration process within the official documentation.
Our Tech Product Manager, Galina Slavova, did a great job with showing how the migration tool works from 3.6.1 to 4.3 –
A few best practices for deploying and migrating existing UM instances:
- You will want to run both UM instances simultaneously for at least one full calendar month. The reason is a migration could happen at any time of the month. This migration tool does not move over reported data.
- During this simultaneous month, put the new UM 4.3 instance into “Test” mode. When selecting Test, it does not aggregate this data over to the Commerce Portal.
- At the beginning of the new calendar month, the Provider Operator can switch the new UM 4.3 instance to “Production” and use this instance going forward. You must archive the previous UM 3.6.1 instance for compliance purposes (or extract three years of reports).
In-Place Upgrade from Usage Meter 4.2
One of the great things about the new Usage Meter 4.x architecture is in-place upgrades.
One can download the 4.3 SHAR file from MyVMware and upload to the existing 4.2 instance –
Once SCP’d to the UM appliance, we can just run “bash ums-system-upgrade_to_4.3.shar” while logged in as the root user –
This is upgrading all packages and takes just a few moments…
It will do a final upload to Usage Insight –
Once complete, we reboot –
Upon restarting, the Usage Meter is now running 4.3 code –
VMware Commerce Portal Registration
Registration in the VMware Commerce Portal is fairly straight forward.
We log into the Commerce Portal, navigate to Contracts -> Select your contract -> Usage Meter Instances, and select Register New.
When registering the new Usage Meter instance, we can input a friendly name along with the Instance ID which was found on the initial UM wizard screen –
One can select 3.6.x or 4.3 for metering.
To review the modes:
- Production – this will aggregate and push over all reported data to Monthly Billing Order within the VMware Commerce Portal.
- Test – used for evaluation and/or migration (as stated above). Will show reported data within Usage Insight, but will not push over to the Monthly Billing Order within the VMware Commerce Portal.
Once registered, one will see their newly registered instance within this frame –
Usage Meter 4.3 Endpoint Configuration
Once authenticated and registered to the VMware Commerce Portal, we are now ready to configure our solutions for proper metering.
As of today, Usage Meter 4.3 meters the following products –
I am going to go through the typical products configured for metering, but our official documentation goes through the exhaustive list.
vCenter / VMware Cloud Foundation
vCenter and/or Cloud Foundation requires a read-only SSO account with one specific permission: Profile-driven storage > Profile-driven storage view.
When adding a vCenter instance, one must specify the following:
- FQDN/IP Address
- SSO Credentials
- If using an external PSC
- VCF Configuration (if used)
- Tanzu Edition (if used)
Once added, you must accept the certificate. Once authenticated and accepted, we will see a green indicator that everything is healthy.
One can also click on Show Notifications and see all of the previous hourly collections –
vCenter Metering Considerations:
- If you meter based on VCF, everything is metered based on the VCF core or SDDC Manager vRAM add-on. Do not mix non-VCF workloads within the same vCenter.
- SRM and vSAN are now automatically detected and will meter accordingly.
- Tanzu is metered based on vRAM or Cores.
- vRealize Operations is detected based on the vCenter registration.
As stated above, vRealize Operations (vROps) is contingent upon vCenter registration.
Click Edit on the detected vROps instance and input in the vROps credentials (note that we can now use local and domain-based credentials) –
We can also meter a subset of VMs – follow this documentation on establishing this.
NSX-v and NSX-T
NSX endpoints are fairly straight forward with a few considerations.
- You must correlate to a specific vCenter instance for per-VM feature detection. This is a mandatory requirement.
- CLI admin account must be used.
- This just requires the CLI admin account – no correlation to a vCenter instance. Usage Meter will then detect what referenced vCenters are used by this NSX-T instance.
Once completed, we will see our green status.
Cloud Director and Cloud Director Availability
Cloud Director is straight-forward. One adds the FQDN and utilizes the sysadmin credentials for metering.
As for Cloud Director Availability, we use the appliance root credentials for proper metering –
Note that Cloud Director Availability has its own logic on detecting a Usage Meter connection.
vRealize Network Insight
There are a few authentication options for vRNI: local, LDAP, or vIDM. Selecting the radio button for each respective option provides different requirements.
Miscellaneous Usage Meter Functionality
Once can specify if a specific vSphere license is used for Production (Rental), Demo, or Perpetual. I DO NOT recommend co-mingling demo environments with production, but this is an option available –
We can test Usage Insight and Network Connectivity under Settings. This is a great way to verify registration and connectivity to VMware Cloud Services.
Photon CLI Commands
I have a blog post that summarizes many Photon tips. If you run into DNS or network issues, definitely hop into the CLI.
Typical Monthly Activity
Upon the completion of a calendar month, a new Monthly Billing Order Report will be shown within the VMware Commerce Portal.
In my test environment, I can see the Monthly Billing Report for October along with the reported usage data. Auto reporting is also shown from Usage Insight.
Once the Provider Billing Contact reviews the report. They will revise or append any manual reported data and submit it for approval to the aggregator.
In a typical monthly cadence, the UM Operator should have little operational overhead. In the event there is an environmental issue with a UM instance, an email is generated from Usage Insight with the following –
As one can see, Usage Insight will detect any reporting issues and provide guidance on what to do next.
While this was a longer than normal post, this summarizes everything a provider requires to operationalize Usage Meter 4.3. If you have any feedback, please comment below. Thanks!