Bug 1289551 - [RFE] Need a way for RHEV-H to ensure it installs on an appropriate LUN
Summary: [RFE] Need a way for RHEV-H to ensure it installs on an appropriate LUN
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhev-hypervisor
Version: unspecified
Hardware: x86_64
OS: Unspecified
Target Milestone: ovirt-4.0.0-beta
: ---
Assignee: Fabian Deutsch
QA Contact: cshao
Depends On:
Blocks: ovirt-node-ng
TreeView+ depends on / blocked
Reported: 2015-12-08 12:17 UTC by Greg Scott
Modified: 2016-08-23 21:05 UTC (History)
10 users (show)

Fixed In Version: rhev-hypervisor7-ng-3.6-20160429.0
Doc Type: Enhancement
Doc Text:
With this update, the new Anaconda installer has added the ability to identify individual disks. This change was required to ensure the correct installation decisions are made.
Clone Of:
Last Closed: 2016-08-23 21:05:03 UTC
oVirt Team: Node
ycui: testing_plan_complete?

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1702 normal SHIPPED_LIVE redhat-virtualization-host bug fix and enhancement update for RHV 4.0 2016-08-24 00:35:27 UTC

Description Greg Scott 2015-12-08 12:17:01 UTC
Description of problem:
The RHEV-H installation process boots from CD/DVD and presents the user with a series of fibrechannel LUNs on which to either wipe or install RHEV-H.  The LUNs present themselves as sdnn devices.  Picking the wrong LUN from the list could be disastrous.  Imagine accidentally wiping a storage domain and installing a copy of RHEV-H over the top of it. That could destroy a logical data center and shut down thousands of users.

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

How reproducible:
at will

Steps to Reproduce:
1. Boot a new bare metal host from RHEV-H media.
2. Pick the wrong sda device and install RHEV-H.

Actual results:
I don't like to think about the possible actual results.

Expected results:
RHEV-H should present a warning or something to ensure it never installs on the wrong LUN.

Additional info:
This applies to fibrechannel data centers where firmware presents LUNs with no higher level software getting involved.  It is especially dangerous in boot from SAN scenarios.

Comment 1 Fabian Deutsch 2015-12-08 16:09:54 UTC
It is already possible to address specific disks during auto-installation using the serial numbers.

Could you provide the output of

$ find /dev/disk/

from a host with the described storage setup?

With that output we can tell if the disks expose enough information to be identifiable on RHEV-H.

Comment 3 Greg Scott 2015-12-08 17:10:25 UTC
re: comment 1 - I put the question to the customer in the support case.  

If rhevh.next does its install similarly to RHEL7 with the graphical display of existing partitions and so forth, that feels like a great step forward.  I'll ask the customer if that will work.

- Greg

Comment 5 Fabian Deutsch 2016-03-23 10:24:33 UTC
RHEV-H next (planned for RHEV 4.0) will be using Anaconda for installation.

Anaconda provides mechanisms to precisely identify LUNs (i.e. through serial numbers/wwids).

Does the featureset provided by Anaconda meet the requirements expressed here?

Comment 6 Greg Scott 2016-03-23 11:01:07 UTC
It should.  I asked the customer earlier to try a test RHEL 7 or Fedora install to get a feel for it.  I'll ask again.

- Greg Scott

Comment 7 Fabian Deutsch 2016-03-24 13:18:49 UTC
Thanks, moving this bug ON_QA for now.

Comment 9 cshao 2016-06-02 10:07:00 UTC
Test version:

According #c5 & C6, Anaconda can provides mechanisms to precisely identify LUNs.

So the bug is fixed. Change bug status to VERIFIED.

Comment 11 errata-xmlrpc 2016-08-23 21:05:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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