VMware vCloud Usage Meter – BND to Bundle Translation Technical Discussion

Recently, we received a post on VMware Communities forum for vCloud Usage Meter requesting clarification on the “BND” column on the Virtual Machine History Report. I’d like to spend a little more time discussing this further for others and some of the logic under the covers.

Moreover, I’m going to review a sanitized customer collection and discuss something I even learned.

Luis Ayuso and I spend a lot of time with Usage Meter, so over time, we’ve come intimately close to the inner workings of UM logic (more Luis, follow him for further updates and direction!). While UM has its quirks, it has quite a bit of logic and intelligence integrated for billing purposes.

First, here’s the BND mapping to current VCPP bundles –

Items that I want to point out:

  1. The BND identifier does not reflect the actual bundle point value. This is by design due to the variances of past bundles.
  2. The Standard Bundle is being retired, but will still show up in any existing or previous Usage Meter instances.
  3. While we have a unique ID for the Standard SP Bundle with Management or Networking, the point bundle value remains the same.

The second thing I’d like to cover is the BND column inside of the Virtual Machine History report – this is column P –

We can see in the above screenshot three important columns:

  1. Bnd Column – which is the bundle identifier. In the above example, we see VM’s reporting ID 7, which is the Standard Bundle.
  2. vROps Column – we would see a “Y” or “N” here depicting if this VM is registered inside of vRealize Operations. What we can conclude from the above screenshot is the following:
    1. Running vSphere Enterprise (NOT Enterprise Plus)
    2. vRealize Operations Itemized Breakout
    3. How? Well, Usage Meter will always pick the most cost-effective option as a bundle for the Providers. We know that the 7-point/Advanced Bundle has vSphere Enterprise Plus while the 5-point Standard bundle uses vSphere Enterprise which was EoL’d a few years ago. Moreover, if the Provider utilizes Advanced or Standard vROps, this is not in any VCPP bundle, so this will be itemized billed out. This could also be the Enterprise version since we are using the 5-point bundle.
  3. NSX Column – in this example, we do not have any NSX detection. However, if we did, we would see:
    1. B – NSX SP Base Version. Included in Advanced/7-Point Bundle
    2. A – Advanced SP Version. Included in Standard with Networking (8-Point) OR Advanced with Networking Bundle (9-Point).
    3. E – Enterprise SP Version. Included in Advanced with Networking and Management/12-Point Bundle.

As a quick refresher, here are the different versions of NSX inside of VCPP –

We can see in the below screenshot where the VM state changed – VM was registered inside of vROps. Therefore, the bundle went from BND 8 (Advanced SP) to BND 10 (Standard with Management). Why? Well, it was not utilizing vCloud Director nor NSX, so this is the most cost-effective option for this VM. 

Makes sense. Moreover, this is AVERAGED over the month, so if you utilize the Advanced bundle for half of the month while utilizing Standard with Management for the rest, you only pay for the specific hours of use.

Let’s talk about an interesting scenario. I noticed that a VM was “flapping” between BND 7 and BND 13 – that’s a big change. We can see that it’s utilizing vROps and NSX Advanced, but why wasn’t defaulting to a lower point bundle?

Well, Usage Meter will append a new line for VM state change – that includes vMotions. What we can see if this VM vMotion from host-30 to host-31 (sanitized names) but were using different vSphere licenses. Ah ha!

We can see on the top line which is host-30, it was using a vSphere Enterprise license while the next three line items (host-31) were on an vSphere Enterprise Plus license.

Interesting! So, how did this look in the Monthly Usage Report?

We can see NSX Advanced in the Monthly Report. While there is no itemized NSX Advanced in the Product Usage Guide, I believe the Provider would have to just report NSX Enterprise for these VM’s.

So, what did we learn from this scenario? Make sure your licensing is configured in a uniform fashion! This will be very unlikely in the future as Enterprise is not supported after September 2018, but it’s imperative to have proper hygiene for the same hosts in the same cluster.

Happy Metering,

-Daniel

VMware EMPOWER Usage Meter Session Material for Cloud Providers

Luis and I had a great session this morning at the VMware Partner EMPOWER conference around Optimizing vCloud Usage Meter for VMware Cloud Provider Environments –

Due to the popularity of the session (it was full this past weekend), we now have added a second session on Thursday, April 19th. Luis will be presenting solo since I have a prior conflict.

A few things I want to stress for the providers that may have been at the session or one that has not –

  1. Usage Meter is not a customer-facing chargeback solution. Below is a Venn diagram we built that shows what overlaps with vRealize Business for Cloud – not much as you can see. 
  2. Follow the five steps to success – this will ensure everything is covered for a proper and successful Usage Meter deployment. 
  3. Use the planning sheet that was created – this is a great way of ensuring everything is covered from a planning perspective. 
  4. Follow Luis’s do’s and do not’s for proper billing and reporting. It’s important as this is an obligation of all Cloud Providers within the program. Luis went into extensive detail during the session and gave real-world examples. 

Finally, we have all of the material we referenced here in one location, along with our presentation. Luis and I look forward to future discussions and we also have submitted this session for VMworld. Hoping to see many of you this week and at other sessions.

Thank you!

-Daniel

A deeper look at vCloud Director and NSX Distributed Logical Router and Firewall Services with Usage Meter feature detection

Need to work on my titles, but that’s what I have for now. I want to spend some time reviewing how NSX Distributed, Edge, and DLR Firewall services behave in respect to vCloud Director and vCloud Usage Meter.

Some may know vCloud Usage Meter provides automated feature detection on a per-VM basis – essentially allowing granular-level billing for tenants. For example, tenant ACME may have 5 VM’s that need Distributed Firewall out of 20 – why charge them for all if they aren’t using it? Since version 3.6 of Usage Meter, this feature has been applied on a per VM level, for the most part.

There are three different versions of NSX available in the Cloud Provider Program –

We can see that your basic fundamentals are available in SP Base: your distributed switching and routing, Edge Firewall services, NAT’ing, etc. Advanced adds in Distributed Firewalling, Service Insertion and other advanced functionality while Enterprise is adding in X-vCenter NSX, HW VTEP integration.

Second, let’s take a look at the chart for NSX Editions by Feature. This comes from our vCloud Usage Meter Feature Detection whitepaper. Don’t have it? Get on VMware Partner Central and grab a copy.

Take note at the statement of “All VMs on all networks serviced by the edge” – this means even if you have a VM on that edge that does not use that feature, it will charge for it since it still has access to it. For example, if you set up a L2VPN on an Edge, be aware that any other connected networks will be charged for NSX Enterprise even though they may not be able to traverse to that tunnel!

Lab Setup

I wanted to design a DLR environment within vCD along with using Edge and Distributed Firewall rules. I came up the following design in my 9.x environment:

  1. Creating an NSX Distributed Logical Router (DLR) is pretty easy. Select the Advanced Gateway box and check Enable Distributed Routing. You can also enable Distributed Routing on any existing Advanced Edge – 
  2. The great thing about how vCloud Director creates Distributed Routing is it’s actually two Edges – a standard perimeter edge along with the DLR southbound. The transit interface is created as a /30 while applying static routes for any connected DLR interface. DLR’s default gateway is the Edge transit interface. Below is what I can see inside of NSX. 

Using the NSX Distributed Logical Router is in the NSX Base bundle and covered by Advanced SP Bundle, which is great for providers. However, Edge Firewall services are only available in the NSX Base bundle, where some providers may want to provide “high-powered” firewalling services.

The key difference between Edge and Distributed Firewall services is we do not hairpin for forwarding decisions in the DFW model: the decision is made inside of the hypervisor before the packet ever egresses anywhere. Hence, provides better throughput and capability compared to Edge or traditional firewall services – check out Wissam’s discussion on DFW capabilities here. 

vCD Access to Edge Firewall vs Distributed Firewall

I think Tomas did a great job of summarizing vCD Firewall capabilities and pointing out some of the architecture differences between the two firewall technologies.

From a vCD UI access point of view, you have to access the firewall services in two different places.

  1. Edge Firewall services are accessed by right-clicking on the Edge Gateway and selecting Edge Services. Makes sense, right? 
  2. Now Distributed Firewall management is accessed by right-clicking on the organization VDC and clicking on Manage Firewall. Not my favorite and doesn’t state DFW, but this is how it’s accessed today in the Flex UI. 

NSX Distributed Firewall Changes

Okay, let’s get into a few scenarios and test out how Usage Meter will put up the changes.

  1. I freshly created my three vApps: T1-App-1, T1-DB-01, T1-DLR-tclinux-01/02a (Web Servers). We can run a VM History Report and pick them up and see they all have been associated with the Advanced Bundle initially. I will try to point out the vROps and NSX column in the following discussion, but we will be looking for a checkmark and an “A” that refers to Advanced usage. 
  2. So let’s go ahead and crack open the DFW and start carving up some rules. This is a simple 3-tier architecture so I’m going to lay out allowing web, web to app traffic, app to DB, allowing SSH to App and DB, and blocking everything else in Web, App, and DB Tiers. 
  3. As you can see, the Applied To for my deny rule is only applied to my three Distributed Routing tiers (or routed Org VDC Networks). Not only is this a good NSX practice, this cuts down on who gets charged for NSX Advanced!
  4. Now looking at the DFW rules from vCenter, I can see vCD created the tenant folder and applied the policies in order. Very streamlined. 
  5. Now let’s check to see if my new rules work. Yep, I can still SSH to my VM’s but do not receive any ICMP replies. Perfect! 

How did Usage Meter detect the changes?

  1. So let’s now take a look at the Usage Meter VM History Report. What’s fascinating is Usage Meter tracks every move called state change. We can see in my tclinux-vApp (or Web) that it tracked when it started using Base NSX usage, then switched to Advanced, then my vROPs Enterprise instance picked it up and added it to its inventory. All in a very short timespan. Very useful! 
  2. With the DB and App layers, we see something very similar – vROps Enterprise, however, picked up these VM’s first and then we see Advanced NSX usage. 
  3. Now, I can see a few new line items populated on my Customer Monthly Usage and Monthly Usage report. I now see Advanced Bundle with Networking, Advanced Bundle with Management, Advanced Bundle with Networking and Management.
  4. This is to be expected since my VM’s went through a few iterations – my Web VM’s initially went with NSX Advanced without vROps which falls in the Advanced with Management while DB/App started using NSX Advanced without vROps registration (Advanced with Networking bundle). Last of all, all three are now assigned to the Advanced w/Networking and Management since we are using NSX Advanced features along with vROps Enterprise.
  5. While I see the new line items, I don’t see any units to be reported. Why? Well, I have some very small VM’s (256MB in vRAM) and they just ran a few hours during this testing. Keep in mind Usage Meter averages out the usage over the entire calendar month (720 hours for a 30 day period or 744 hours in a 31 day period). Again, to be expected but was pleased that new categories were added immediately.

In summary, Usage Meter does a great job of detecting NSX feature usage and bills it accordingly based on a specific service – Distributed Firewall being one of them. Thanks!

-Daniel

vCloud Usage Meter 3.6.1 Hot Patch Steps – In-Place Upgrade!!

This is an exciting day – there has been a patch release for vCloud Usage Meter. With this patch release, we do not need to deploy a new appliance and migrate over. There was a release for vCD 9.1 support and a few miscellaneous fixes.

This is a VERY simple process and I just uploaded my own Usage Meter instance in about five minutes while screenshotting the process.

Note – this can be used with vCloud Usage Meter 3.6.1 build 7359407. If you are running an older version of Usage Meter, you will need to use the traditional migration method. 

Steps from the README file

  1. Ensure there are no current running tasks in UM, like auto-collect or hourly reporting.
  2. Backup the appliance – either snapshot it or clone it (remember to delete the snap after)
  3. Enable SSH on the appliance (if not enabled)
  4. Download the patch from here
  5. SCP the zip file to the appliance
  6. Check SHA to ensure consistency
  7. Switch user up to root (or sudo)
  8. RPM -i to install the patch.
  9. Done! Now you can add vCD 9.1 for successful metering

Step by Step Install

We can see the current build is the following:

Download and Upload

  1. Download the patch from the VMware Downloads Site 
  2. Extract it…
  3. Let’s now SCP it up – I am using the “usgmtr” account since that allows remote logins by default. 

SSH to Verify SHA and Install Patch

  1. Let’s now SSH to Usage Meter using the “usgmtr” account: 
  2. Verify hash – yep, it matches:
  3. Let’s switch user to root so we can install the package successfully. 
  4. Run “rpm -i <filename>” and let it do its work! 

Login to UM, Verify Build, add vCD 9.1

  1. We can now see a new build number for UM: 
  2. Now let’s activate or add in vCloud Director 9.1 for successful metering. 
  3. Now we can see it active in the Products list – excellent!

Again, very easy. Make sure you backup the appliance (either clone it) and run this after the 3rd of the month per the README. Enjo

-Daniel