BVQ Whitepaper:
BVQ Service Level Management Package

Avoid mission critical security vulnerabilities with Service
Level Management  - a practical approach

Same document in German Language

Avoid mission critical security vulnerabilities with SLM.pdf


We mirror storage volumes, especially in mission critical environments, to avoid that a simple technical failure leads to application downtime and loss of production.
With SVC or Storwize it is very easy to migrate volumes between different storage systems, and with this it may happen that two sides of a mirror are moved to the same site or even worse to the same storage system.
Highly explosive to this situation is, that SVC or Storwize migrates volumes completely transparent, and the server administrator has no way and no tool to recognize this move.
He will only be surprised at the time of a one sided storage failure or controlled shutdown, that the security levels for his mission-critical systems have not been met.
This is a situation, where service level management can help. A defined service level rule for this situation can be: "A volume of class A is not allowed to be stored on the same storage system or in the same geographic site as a volume of class B".
Now a tool is needed, which is continuously monitoring this rule and raises alarm, when this rule is no longer met.
Monitoring rules like this is part of the BVQ Service Level Management Package.


We created a BVQ VDisk Group Relation rule for the VDiskgroups LVM1 and LVM2. In this rule is defined that volumes from these two VDisk groups may not be served from the same controller (storage system).

  • A group VDisk is a collection of several SVC / Storwize volumes that belong together organizationally.
  • In this VDisk Group relation rule we would also be able to define that volumes from these volume groups have to be located on different sides or in different rooms.

Figure 1: This BVQ Group VDisk Relation rule specifies that volumes from the
LVM1 / LVM2 volume groups are not allowed to be on the same storage system.
If the volume in the volume groups groups are now designed in a way that each
of the mirrors is in another BVQ Volume Group then BVQ can raise an an alert
when this rule was abolished by a thoughtless migration. As long as this rule is
satisfied the administrator can be assured that the mirrored volumes are at least
stored on different storage systems. If the BVQ definitions also include room
and site informations the administrator can also use locations in this rule.

With BVQ it is now easy to monitor the current state of these rules. In the following figure (Fig. 2), we use a standard BVQ Treemap with the additional Analysis for Alerting or placement rules (the same result in this example) All volumes displayed in brown are not secured with additional alerting rules. The volumes in green are secured with and their status is "OK" (inconspicuous).

Figure 2: A standard BVQ Treemap with additional Alerting status. Brown means that the volumes are not
additionally secured with an Alert method. Green means the volume is secured by additional alerting methods
and the status is "OK – no error detected"


We migrate (Fig. 3) one of the volumes from the volume group LVM1 to the same controller where we also find volumes from the volume group LVM2. Although we destroy the planned integrity of the server with this migration, and risk a production loss in case of a simple failure, this migration is a standard task for SVC and the execution will not lead to a warning.

  • With SVC or Storwize volumes can be moved from one storage to another storage with only one mouse button click. This migration is completely transparent - it is not at all noticeable outside the SVC or Storwize management.

  • One can easily imagine that the awareness about the special relationships and the placing of volumes can become forgotten over time No system or server administrator will notice this volume move , as long as it does not lead to noticeable performance differences. The transparency and the simplicity of volume migration is a significant risk potential as long as it will not be monitored

  • This security leak will be detected in the worst case only, when the storage system fails and one realizes, full of surprise that the planned security did not exist any longer.

  • BVQ scans the structure and relationships of the SVC or Storwize volumes continuously and compares them against the rules, which are stored in the BVQ database. BVQ will display warnings, after some minutes, when rules are violated (Fig. 4). With Version 3 BVQ can automatically raise alerts on rule violations .

Figure 3: SVC has no knowledge about organizational needs. A volume migration is easy to start and BVQ will
bring it to an end, regardless whether or not the security needs of a production system are affected.

Figure 4: BVQ has detected the rule violation and displays it in the Treemap. The volumes that are no longer
compliant with the rules marked in red. It is now easy to find out what the reason for the alert and migrate the
volume back ASAP. With Version 3 BVQ will automatically raise alerts on rule violations

BVQ in the www

BVQ Website

IBM Developer Works Documents and Presentations