Content
| Table of Contents |
|---|
BVQ° licensing overview
BVQ° is licensed as a combination of BVQ° editions and capacities entitlements:
Editions & Packages | Free edition Entry edition Enterprise edition |
|---|---|
Capacity entitlements | Compute layer (GiB Memory*) Network layer (Ports) Storage layer (TiB) |
For very large installations, other licensing methods can be used that are mutually beneficial.
* Memory based Compute layer licensing available since BVQ° release 2023.H1 (see below)
BVQ° editions & packages
BVQ° functionality is tailored to the typical needs of different infrastructure sizes and customer demands:
BVQ° Enterprise edition | Full functionality: Monitoring, reporting, alerting & analysis |
|---|---|
BVQ° Entry edition | Major functionality: Monitoring, reporting, alerting |
BVQ° Free edition | Basic functionality for a limited environment size |
https://bvq-software.de/en/bvq-license
BVQ° capacity entitlements
The size of a BVQ° managed environment is measured with capacity entitlements. Each BVQ° edition has a specific price for one of the three following entitlement types related to an IT-infrastructure layer grouping the platforms and their systems supported by BVQ. Entitlements are marketed in packages, that contain a specific count of entitlements.
Layer | Licence Entitlement | Packet size |
|---|---|---|
Memory (RAM) capacity GiB count | 128 GiB | |
Port count | 25 Ports | |
Managed Storage capacity TiB count | 10 TiB |
Compute layer Memory entitlements
BVQ° license is validated against the total count of GiB of installed Memory (RAM) of all Compute layer systems monitored by BVQ. The count is independent from the online state or usage of this capacity.
All Compute layer systems must be completely licensed by Virtual machine entitlements or be completely licensed by Memory entitlements. Partial entitlement intermix is not supported.
Compute layer licensing based on memory is available since BVQ° release 2023.H1 and replaces the Compute layer Virtual machine entitlements (see below).
Compute layer Virtual machine entitlements
If you are still using this type of entitlements, BVQ° license is validated against the total count of all Virtual machines or Logical partitions (VMs) configured of all systems monitored by BVQ. The count is independent from the online state or function of the VMs. IBM PowerVM VIOS are excluded from the count.
In case a BVQ° OS Agent is used on a System that is already monitored via PowerVM HMC or VMware vSphere BVQ° Scanners, no additional VM entitlement count is needed.
All Compute layer systems must be completely licensed by Virtual machine entitlements or be completely licensed by Memory entitlements. Partial entitlement intermix is not supported.
Compute layer licensing based on Virtual machine entitlements is no longer available since BVQ° release 2023.H1. A migration path to the new Compute layer Memory entitlements (see above) is available. Please ask your SVA contact for details.
BVQ° Compute layer licensing tries to keep the virtualization layer transparent
In a cascaded compute virtualization layer environment, for example Kubernetes containers running inside a VMware vSphere hypervisor, the memory capacity is only counted once. Memory discovered in upper compute container nodes provisioned from underlying compute hypervisor systems which are monitored and completely licensed by BVQ° is not validated against the BVQ° license. Otherwise, memory discovered in upper compute container nodes provisioned from underlying compute hypervisor systems which are not monitored and completely licensed by BVQ° is completely validated against the BVQ° license.
With that, you can add your Kubernetes environment without additional charge, if the underlying compute hypervisor system memory is licensed already. This provides the advantage of a deeper a end-to-end monitoring expertise.
Network layer Port entitlements
BVQ° license is validated against the total count of all ports of all switches and directors monitored by BVQ, which are activated by a license of the device vendor. The count is independent from the online state or function of the ports. Ports on Core Routing blades in Brocade director class switches only count if a QSFP is plugged into such ports.
Storage layer Capacity entitlements
For the IBM storage systems the BVQ° license is validated against the total count of managed storage pool capacity TiBs of all systems monitored by BVQ. The count is independent from the online state or usage of the capacity.
Managed storage pool capacity is based on the amount of total capacity that is provided by the storage system pools that can be assigned to volumes, filesystems or metadata. This capacity is typical less than the gross raw disk capacity and less than the capacity after volume data reduction (compression, de-duplication, thin provisioning, ...).
For all other storage systems the BVQ° license is validated against the total :
Netapp ONTAP: Total count of all
drive size TiBs
Dell Unity: Total count of all pool capacity TiBs
Dell PowerStore: Total count of system physical capacity TiBs
Pure FlashArray: Total count of system capacity TiBs
NetApp ONTAP Metrocluster
The capacity of Disk Enclosures shared between two NetApp ONTAP IP or FC Metro clustered Systems is only counted once.
BVQ° Storage layer licensing tries not to take care where data reduction takes place
In case of volume data reduction: This does not affect the total managed capacity of the pools, so it does not affect the BVQ° license.
In case of pool data reduction: BVQ° license is validated against the smaller physical allocatable capacity not the logical capacity.
In case of drive level data reduction: BVQ° license is validated against the smaller physical allocatable capacity not the logical capacity. This is currently only applicable for some systems. All other systems need to be licensed for the pool capacity as explained above.
BVQ° respects drive level data reduction for the following systems:IBM Storwize family systems
IBM FlashSystems
In case of thin provisioned MDisks provisioned from BE Systems to the Storage virtualization layer (eg IBM Spectrum virtualize (SVC)), the sum of the physical capacity and the sum of the logical capacity is calculated and only the smallest of both results is counted (since BVQ° release 2021.H2).
The support of thin provisioned MDisks in the virtualization layer. is required for that. IBM supports that feature for a growing number of backend storage subsystems from IBM and other vendors.
BVQ° Storage layer licensing tries to keep the virtualization layer transparent
In the storage virtualization layer, the managed storage pool capacity of storage pools provisioned by backend storage subsystems monitored and completely licensed by BVQ° is not validated against the BVQ° license. Otherwise, managed storage pool capacity of storage pools provisioned by backend storage subsystems not monitored by BVQ° is completely validated against the BVQ° license.
You can take the following advantages by including supported backend storage subsystems in your BVQ° monitoring:
This may decrease the amount of licensed BVQ° capacity, in case data reduction takes place inside the backed subsystems .
e, without additional charge if the backend subsystem capacity is completely provisioned to the virtualization layer.
BVQ° Storage layer licensing example calculation (based on TiB)
Backend subsystem | Virtualization layer | BVQ | ||||||
|---|---|---|---|---|---|---|---|---|
BVQ° monitored? | Drive physical | Drive logical | Pool physical capacity | Pool logical capacity | Volume logical capacity | pool logical | Licensed | Reason why |
| 100 | 100 | 100 | 100 | 100 | 100 | 100 | No data reduction at all |
| 100 | 100 | 100 | 100 | 200 | 200 | 100 | Volume level data reduction in BE subsystem is respected by BVQ |
| 100 | 100 | 100 | 200 | 200 | 200 | 100 | Pool level data reduction in BE subsystem is respected by BVQ |
| 100 | 200 | 100 | 200 | 200 | 200 | 100 | Drive level data reduction in BE subsystem is respected by BVQ |
| N/A (50) | N/A (100) | 50 | 100 | 100 | 100 | 100 | Drive level data reduction in BE subsystem not listed to be respected by BVQ |
| N/A | N/A | N/A | N/A | N/A (100) | 100 | 100 | No information from BE subsystem: Virtualization layer pool logical capacity counts. |
| 100 | 100 | 100 | 100 | 100 | 50 | 100 | Not all capacity of a BE subsystem managed by BVQ° is provisioned to the virtualization layer: Total managed BE System capacity counts. |
| N/A | N/A | N/A | N/A | N/A (200) | 100 | 100 | Not all capacity of the BE subsystem is provisioned to the virtualization layer: Virtualization layer capacity counts. |
| N/A | N/A | 100 | N/A | 200 | 200 | 100 | Inline inquiry information from BE subsystem via thin provisioned MDisks: |
| N/A | N/A | 200 | N/A | 100 | 50 | 100 | Inline inquiry information from BE subsystem via thin provisioned MDisks, but |
Storage layer Enclosure entitlements
This way of licensing is withdrawn from market since . Customers with an active BVQ° license may still extend their systems with that type of license.
For eligible storage systems, the BVQ° license is validated against the total count of all enclosures containing disk drives (controller an expansion enclosures). The count is independent from the online state of the enclosure.
The following storage systems are eligible for BVQ° enclosure based licensing: IBM Storwize V5000, V7000, V7000F
All Storwize systems' capacity below SVC is not eligible for enclosure based licensing.
Standalone Storwize systems not attached to SVC, must be completely licensed by enclosure or be completely licensed by capacity entitlements. Partial entitlement intermix is not supported.
A typical scenario is: A customer has some Backend systems below SVC and some other eligible Storwize systems not connected to the SVC so they are directly provisioning some hosts with storage capacity. Here the customer can license the direct attached systems by BVQ° enclosure based licensing and the SVC Capacity by BVQ° capacity based licensing.