Bug 1289551

Summary:	[RFE] Need a way for RHEV-H to ensure it installs on an appropriate LUN
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Greg Scott <gscott>
Component:	rhev-hypervisor	Assignee:	Fabian Deutsch <fdeutsch>
Status:	CLOSED ERRATA	QA Contact:	cshao <cshao>
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	audgiri, gklein, gscott, lsurette, melewis, mgoldboi, pstehlik, srevivo, ycui, ykaul
Target Milestone:	ovirt-4.0.0-beta	Keywords:	FutureFeature, TestOnly
Target Release:	---	Flags:	ycui: testing_plan_complete?
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-23 21:05:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Node	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1140646

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):
all

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.
3. 

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:
rhev-hypervisor7-ng-3.6-20160518.0
imgbased-0.6-0.1.el7ev.noarch

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.

https://rhn.redhat.com/errata/RHBA-2016-1702.html