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:
- The BND identifier does not reflect the actual bundle point value. This is by design due to the variances of past bundles.
- The Standard Bundle is being retired, but will still show up in any existing or previous Usage Meter instances.
- 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:
- Bnd Column – which is the bundle identifier. In the above example, we see VM’s reporting ID 7, which is the Standard Bundle.
- 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:
- Running vSphere Enterprise (NOT Enterprise Plus)
- vRealize Operations Itemized Breakout
- 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.
- NSX Column – in this example, we do not have any NSX detection. However, if we did, we would see:
- B – NSX SP Base Version. Included in Advanced/7-Point Bundle
- A – Advanced SP Version. Included in Standard with Networking (8-Point) OR Advanced with Networking Bundle (9-Point).
- 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.