VMware vCloud Usage Meter 3.6.1 – Metering of vCloud Availability 3.x and Logic Review

Last week, the VMware Cloud Provider team released a hot patch for VMware vCloud Usage Meter 3.6.1. Usage Meter can now automatically meter vCloud Availability (vCAv) 3.x instances. This also covers Site Recovery Manager (SRM) virtual appliances along with a few bug fixes.

Prior to this hot patch, a VMware Cloud Provider would need to manually report usage by exporting the vCAv Manager report on a monthly basis. This hot patch mitigates that process by now providing automatic metering of vCAv instances within a Usage Meter appliance.

This is intended for Cloud Providers that are participating in the VMware Cloud Provider Program (VCPP).

In this post, I will review the setup instructions and what needs to be done so proper metering is in place for vCAv 3.0.

Currently, I’ll be applying this to a freshly built Usage Meter 3.6.1 instance that I have running in a new lab environment –

Logic

First, let’s talk about the logic of this vCloud Availability patch.

This will collect any incoming protected workloads to the metered vCAv instance. Essentially, Usage Meter is using the API available from vCAv and executing a report export – see the documentation on that here.

In my lab, I have two sites: Site-A and Site-B. I will be eventually adding both sites and all endpoints to a single Usage Meter appliance. Depending on your configuration, you could utilize a consolidated UM appliance or one per site.

Download and Upload the Patch

First off, download the Hot Patch at the VMware Downloads site here.

Next, utilize your favorite SCP utility to upload it to the Usage Meter appliance.

If you do not have SSH started, ensure it is started via the console by typing

service sshd start

Other Usage Meter tips listed here.

Patch Installation

Once SSH’d in, switch user to root

su -

Next, let’s unzip the file –

unzip vCloudUsageMeter-3.6.1.0-14877528-hot_patch_3.zip

Verify the SHA matches what’s in the file –

sha1sum vCloudUsageMeter-3.6.1.0-14877528-hot_patch_3.rpm

more vCloudUsageMeter-3.6.1.0-14877528-hot_patch_3.rpm.sha1

Now are ready to install the Usage Meter RPM

rpm --install vCloudUsageMeter-3.6.1.0-14877528-hot_patch_3.rpm

All done!

vCloud Availability Metering Configuration

Let’s bring up the UI for Usage Meter and log in. We can now see a new build number listed in the UI –

We can also see vCloud Availability listed in the list –

I need to add NSX and vCD first, so let me go ahead and get that done.

Now I am ready to add in vCloud Availability. Click the Add button to bring up the dialog for input. We need to put in the following:

• Hostname of the vCAv Cloud Replication Manager
• Port (default is 443)
• Username is root – we are using the local root appliance account
• Password that was set on initial login

Once you accept the certs, we should now have it in the list.

Now, I am going to add my primary site, Site-A, to this Usage Meter instance. This is again, because Usage Meter will meter only incoming protections. Therefore, we require capturing both sites. I have two active sites providing ‘Cloud-to-Cloud’ replication.

vCloud Availability Metering Validation

Let’s verify what we see from Usage Meter 3.6.1 and correlate it to the manual reports inside of each respective vCAv CRM instance.

From Site-A, I see three (3) incoming protections: 2 for Daniel and 1 for Acme:

From Site-B, I see one (1) incoming protection for Daniel –

Therefore, we should see a total of four (4) total from the Monthly Usage Report inside of Usage Meter.

Going to Reports -> Browse for Monthly Usage for the current month, and yes, we do see a total of 4 Protected VM’s.

Test Scenario – Removal and Addition of the Same VM throughout a Calendar Month

Scenario

This scenario comes up often: What does a VMware Cloud Provider pay for a workload that is enabled for vCAv protection, then disabled/removed, and then re-added to vCAv later in the same calendar month?

By my understanding, the Cloud Provider would only pay for that workload one time. In this section, we will test this behavior to verify functionality.

Testing

Let’s do a test – let’s remove a protected VM (Daniel-App-2) from vCAv protection, grab the usage data, and then re-add it.

After removal of Daniel-App-2 from vCAv, we can see that it is removed from the local CRM report. At Site-A, we went from 3 previously now to 2.

This is expected as it only grabs current state data of actual usage.

From Usage Meter, it stays at 4. Why? Well, it’s based on unique protections, so this is to be expected.

Now re-adding Daniel-App-2 back to vCAv, we can see that vCAv usage increments up inside of the CRM instance –

After a Usage Meter collection, we can see that we are still have 4 units to report for vCAv. Why? Well, it was the same VM that was previously protected. Therefore, as of this current test, we should only see 4 units.

Additional Workload

Next, let’s go ahead and add another workload, Daniel-App-3, and see how this is reported to vCAv and Usage Meter.

Daniel-App-3 is now protected and powered on, let’s check the Site-A Usage Report. We can see a new addition and a total count of four (4) –

Finally, let’s check Usage Meter. Forcing a collection will kick off a new verification of how many workloads are being protected by vCAv across the two sites.

Excellent! We do see five (5) units to be reported for this calendar month. There are four going to Site-A and we have one incoming to Site-B, for a total of 5.

The logic works as expected and covers the scenario if a tenant disables and re-enables vCAv protection throughout the calendar month.

Conclusion

The hot patch is very simple to install and vCloud Availability adds just like any other endpoint product within Usage Meter. For anyone using vCAv, this is a must to minimize on any manual reporting steps on a monthly basis.

-Daniel