Bug 841213 - [rhevm] direct lun: existing luns with RHT_STORAGE tag should be excluded from luns list
[rhevm] direct lun: existing luns with RHT_STORAGE tag should be excluded fro...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
x86_64 Linux
unspecified Severity high
: ---
: 3.1.0
Assigned To: Ayal Baron
Haim
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 08:39 EDT by Haim
Modified: 2016-02-10 11:39 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-23 02:14:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Haim 2012-07-18 08:39:00 EDT
Description of problem:

this issue is a combination between gray-out-luns functionality and direct lun.
when adding a new external disk using web-admin, getDeviceList is sent to vdsm, and in return, we get all the luns that are visible on host, which means, also the luns that used as RHEV storage domains in the system.
upon confusion, one can easily select system storage domain, attach it as external disk to a vm, and delete all existing data. 

expected results: either exclude all luns that contain the RHT_STORAGE tag (all information is reported in getDeviceList or using data-base LUNS table) or show lun as gray-out.
Comment 1 Ayal Baron 2012-07-23 02:14:26 EDT
This can only happen on LUNs belonging to domains from a different setup.
2 things:
1. there is no way of differentiating between a LUN that is longer in use and one that is in use in another setup
2. there is no reliable way of reporting this as we only store the vg metadata on 1 lun in the VG so if we cannot access this LUN but some of the others are visible then we'd see it as 'clean'.  Since we're talking about LUNs which belong to a different setup it is quite likely that this would be the case as it is a misconfiguration to expose such luns to hosts in current setup to begin with.

Closing as not a bug.
Comment 2 Yaniv Kaul 2012-07-23 02:39:22 EDT
(In reply to comment #1)
> This can only happen on LUNs belonging to domains from a different setup.
> 2 things:
> 1. there is no way of differentiating between a LUN that is longer in use
> and one that is in use in another setup

That's actually a good question - when cleanly removing a storage domain, are we properly cleaning it? Removing the tag, etc.?

> 2. there is no reliable way of reporting this as we only store the vg
> metadata on 1 lun in the VG so if we cannot access this LUN but some of the
> others are visible then we'd see it as 'clean'.  Since we're talking about
> LUNs which belong to a different setup it is quite likely that this would be
> the case as it is a misconfiguration to expose such luns to hosts in current
> setup to begin with.
> 
> Closing as not a bug.

Note You need to log in before you can comment on or make changes to this bug.