Bug 1183306

+++ This bug was initially created as a clone of Bug #1182774 +++

Description of problem:
In hyperconverged, a gluster volume becomes the storage domain for vm images. However, actions on the volume (stop/remove) are not currently prevented when the volume is actually assigned and in use as a storage domain.

Once a volume has been assigned as a storage domain, it should 'own' the glusterfs volume and the workflow around these tasks should change to be oVirt orientated.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. in hyperconverged cluster, create a volume and start it
2. add the volume as a storage domain to oVirt
3. go to the volumes tab and issue a stop to confirm that a volume action does not link to actions against the associated object in oVirt

Actual results:
stop and remove are allowed underneath an active storage domain.

Expected results:
For a volume that is a storage domain (hyperconverged - or not!), I would expect the following to happen;

* Volume Stop ;
  - include on the "stop volume" modal dialog the fact that this volume is 
    assigned as a storage domain
  - once the admin confirms the stop operation, place the domain into maintenance mode for consistency in the UI
  - once in maintenance mode, the voume stop can be performed

* Volume remove (note a stop must have already been performed)
  - should prompt for confirmation pointing out that the volume is a storage domain
  - if the user confirms removal
    - destroy the associated storage domain
    - issue the vol delete to remove the volume

* Volume start;
  - start the volume 
  - check domain state, and if in maintenance mode issue an activate



Additional info: