I’ve been working along side the compliance team from VCPP for almost a year now and there are some situations that have come up often enough that it begs to be written about. I want to make sure that partners are informed and understand their options when licensing their cloud environments.

Some background, the VMware Cloud Provider Program is a rental based licensing model of VMware Technologies specifically created for service providers. In short, its OpEx VMware Licensing. This program has been around for awhile in multiple names such as VMware Service Provider Program (VSPP), vCloud Air Network (vCAN, not to be confused with vCloud Air) and now the VMware Cloud Provider Program (VCPP). The program provides bundles for vSphere and additional technologies so that Cloud Providers can build pricing and packaging based around features and VMware products. Its extremely flexible and allows our partners to use or move off of add-on technologies without paying an upfront CapEx. These technologies are monitored by a virtual appliance called vCloud Usage Meter which produces a report of usage for the month, which you submit to the business portal (iAsset). Our partners are required to run only supported version of UM (today that is 3.5 and 3.6.x)

In the past year, there have been several situations around license keys and product usage as it relates to the reports that Usage Meter creates. If you found yourself talking with one of the compliance team members from VCPP, the common statement you would hear is:

Partners are expected (i.e. – required) to accurately report the usage from the Usage Meter “Monthly Usage Report” to the Business Portal each and every month.

What this means is that partners are responsible for configuring their environments correctly to make sure they are licensing VMware products correctly. When you incorrectly license your environment, you are still consuming the capabilities of the licenses you use and thus are responsible for the out of Usage Meter reports.

So let’s talk about some scenarios:

Scenario 1: Standard vs Advanced Bundle in Reports

IMPORTANT NOTE: The Standard bundle (5 points per unit) is no longer available, please see the Product Usage Guide for more details.

Issue:
Partner wants to run the lowest cost bundle, the Standard bundle. They go to my.vmware.com to get the license key to use and see a series of vSphere keys. Since all bundles include Distributed Switch (vSphere Ent+ feature), they use the Enterprise Plus license key to license their hosts but does not use other Enterprise Plus features like VM Encryption, Auto-Deploy, etc… Later on, the partner sees that in their report, their usage comes up as Advanced Bundle instead of Standard.

What I have seen:
“Well Usage Meter is obviously WRONG, so I will take the usage numbers and just report it as Standard bundle because I’m not using those Enterprise Plus features.” Other times, I’ve been told by partners that they were not given keys for the Standard bundle (which is NEVER true).

Cause:
There is a specific license key used for the Standard Bundle. In vSphere 5, it’s the “vSphere 5 for Cloud Service Provider“. In vSphere 6 its “vSphere 6 Enterprise with Distributed Network Switch“. If you are only deploying vSphere and vCenter Server and you use the Enterprise Plus key, Usage Meter will correctly meter you as Advanced Bundle (7 points per unit).

What NOT to do:
Do not assume you can place the usage in a different bundle. Partners are responsible for what shows up in the report. Do not just walk away from this. If you continue to take you usage, which is metered as one bundle and report it in the business portal as a different bundle, you are actively choosing each month to ignore the issue. If compliance reaches out to you for a review, you will be required to provide your proof of usage (Monthly Usage Reports). If you under-reported, you will be asked to pay back the delta, with the addition of a 25% Recovery Penalty.

What to do:
Change the license key in vCenter Server. If you need assistance, contact VMware Global Support Service (GSS) immediately by opening a ticket on my.vmware or calling the support line (+1 (877) 486-9273. Because GSS tickets are stored and maintained by VMware, we use those as proof to show you actively attempted to resolve the licensing issue.

Why this is important:
If you need assistance, please do not only seek advice from your Aggregator, reach out to VMware support. If you do not attempt to seek help from VMware Support, the creators of the software and licenses, it is hard to make a case in your favor.

Scenario 2: Historical Data for Non-Metered Products

Issue:
VCPP requires that all usage data is recorded and kept for a minimum of 3 years. Usage Meter does not currently meter all products available in the program.

What I have seen:
Partners do not deploy Usage Meter or eyeball the usage and just send it in via a report. They assume that because UM cannot meter and produce data, they are not responsible for collecting and storing anything.

What NOT to do:
Like before, it is NOT advisable to just make assumptions in relations to how you pay for services, or in this case, how you validate your usage.

What to do:
Lets use Site Recovery Manager as an example. If you are a DRaaS Cloud Provider, meaning you only provide the Recovery Site in an SRM topology, then you may not have access to the vCenter on the other end to connect Usage Meter. Well, Usage Meter needs both sides to meter, so now you have to manually meter SRM. In this case, you need to take screenshots of the protection groups as a method of recording your usage and store those screenshots for 3 years.

Why this is important:
You have to have something to prove your usage. This is simply a way to stay compliant with the requirements, while proving that in case of a customer leaving or major outage, that the large drop or rollercoast fluctuations in your reports are true and valid representations of your usage.

Scenario 3: “We are testing Operations Manager but its showing up in the report”

Issue:
The value in VCPP is that you can start and stop using products within the program and your licensing costs will adjust accordingly. Unlike perpetual licenses where you make an investment and then begin deploying it, VCPP allows you to deploy and pay for usage.

In the case of vRealize Operation Manager (vROps), it is automatically detected in Usage Meter by any vCenter Server that Usage Meter is configured with. That means as soon as you connect vROps to production, it will show up in your report.

What I have seen:
On more occasions that I can count, a partner will say they have been testing out vROps in their production environment. Actively using it to validate its place in their infrastructure management. They expect that while testing the product, they are not responsible for any licensing usage.

What NOT to do:
DO NOT connect products you are testing, to your production workloads. Thats just IT common sense. In this case, it makes even more sense, because it will immediately affect your licensing costs. Even if you do not give Usage Meter the credentials, it will show up at the bottom of your Monthly Usage Report under Product Configuration Issues. If this is seen during a compliance review, that means you consumed a product but did not configure it, to potentially use without payment.

What to do:
All partners in VCPP are provided NFR keys as a way to test any of the products in the program. Build an environment for you and your teams to test products before validating them for use in production. THIS is how you do it for free. This way, when working with a product that can actively make changes to VM placement, sizing or other types of actions, it does not directly affect your customers workloads.

Why this is important:
You should always test new products away from production. If this is the first time reading/hearing this, then repeat it in front of the mirror every morning until it sticks. Testing in production is like putting on the cowboy hat. Only this time you don’t just risk the environment, you risk your budget as well.

Scenario 4: Mixed Tech Environments and Editing / Altering reports

Issue:
Some technologies are not metered yet, take Horizon for instance. Partners who mix horizon and production servers in the same vCenter see that Usage Meter collects the usage of the VDI VM’s.

What I have seen:
I have talked with far too many partners that utilize the same vCenter Server for multiple workload types. This means running production and VDI on the same vCenter. It was done to simplify the number of vCenters engineers needed to log into to manage everything.

What NOT to do:
DON’T MIX WORKLOADS! This isn’t recommended by VMware. By utilizing a single vCenter, it will cause Usage Meter to meter the vRAM of the VDI workloads and again, you are responsible to report the usage that appears on the Monthly Usage Report.

What to do:
Separate vCenters for Horizon and Production. Simple. Connect Production to Usage Meter and wait for Horizon integration with UM at a later date. Report your Horizon usage manually as instructed by the Product Usage Guide. Hint: There is a PowerCLI script in the guide to help make this easier for now.

Why this is important:
Because it falls back to correctly deploying and configuring your environment in a way that is best for licensing and compliance, not just for best practices from a product standpoint. Pay less because you are supposed to. Don’t cause extra work for yourself and others down the road. Because you are.

Again, these are just some of the scenario’s that I see when working with our partners. If you would like to discuss licensing further, please reach out to your VMware Rep and talk with them. If you would like myself or compliance involved, just let them know. We want our partners to be successful. Let us know if you have questions, lets mitigate risk together.

 

 

*featured image from epista