RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 492785 - [NetApp 6.0 feat]Anaconda installer should also support wwid based DM-Multipath device names during OS installation for root multipath scenarios
Summary: [NetApp 6.0 feat]Anaconda installer should also support wwid based DM-Multipa...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: alpha
: 6.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 217209 519842 554559
TreeView+ depends on / blocked
 
Reported: 2009-03-29 15:17 UTC by Naveen Reddy
Modified: 2010-11-15 13:51 UTC (History)
14 users (show)

Fixed In Version: anaconda-13.21.2-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-15 13:51:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Anaconda logs. (640.00 KB, application/x-tar)
2009-03-30 12:37 UTC, Naveen Reddy
no flags Details

Description Naveen Reddy 2009-03-29 15:17:24 UTC
Feature Request for RHEL6.0:
Currently during OS installation for root on multipath scenarios, the Anaconda installer displays DM-Multipath devices with mpath names only i.e. with user_friendly_names enabled by default. Since wwid based multipath names are the standard, the Anaconda installer should also be providing this feature as well i.e. it should display DM-Multipath device names with both options - mpath names along with wwid based names.

Comment 1 Joel Andres Granados 2009-03-30 11:24:46 UTC
What do you mean with "currently".  What version of anaconda did you test with, what distribution did you test with? (rhel5, centos, f10, f11Alfa, f11Beta).  Can you also post the logs for anaconda.  they are located at /tmp/*

Comment 2 Naveen Reddy 2009-03-30 12:37:40 UTC
Created attachment 337213 [details]
Anaconda logs.

I have tested with RHEL5.3.  And this is a feature request for RHEL6.0 

The anaconda version is anaconda-11.1.2.168-1.x86_64.rpm

And I am also uploading anaconda logs here.

Comment 3 Chris Lumens 2009-07-20 17:46:43 UTC
What does a WWID look like?  Can you attach the results of:

udevadm info --query=all --name=<name_of_device>

to this bug so we can see what information is available for us to filter and identify based upon?  Thanks.

Comment 4 Naveen Reddy 2009-07-21 14:07:59 UTC
The wwid is the unique SCSI identifier. 
It is 360a98000433464742f6f51474e632d4a for the following device.

Attaching the output of udevinfo on a RHEL5.4 host as udevadm is not available with older udev versions.

# udevinfo -q 'all' -n sda
P: /block/sda
N: sda
S: disk/by-id/scsi-360a98000433464742f6f51474e632d4a
S: disk/by-path/pci-0000:02:00.0-fc-0x500a09839647d79b:0x0000000000000000
E: ID_VENDOR=NETAPP
E: ID_MODEL=LUN
E: ID_REVISION=7310
E: ID_SERIAL=360a98000433464742f6f51474e632d4a
E: ID_TYPE=disk
E: ID_BUS=scsi
E: ID_PATH=pci-0000:02:00.0-fc-0x500a09839647d79b:0x0000000000000000

Comment 5 Máirín Duffy 2009-08-18 15:22:21 UTC
Hi Naveen, I'm a UI designer with Red Hat. Would you mind reviewing some mockups we created that we think may address this issue? Please let us know if there's any additions or changes you'd suggest for them to better suit your needs:

https://fedoraproject.org/wiki/Design/AnacondaStorageUI

Of particular interest to you I think would be the mockups starting here:

https://fedoraproject.org/wiki/Design/AnacondaStorageUI#Advanced_Device_Selection_-_Multipath_Tab_-_Unfiltered

Thanks in advance for any feedback you can provide!

Comment 6 Naveen Reddy 2009-08-19 07:36:48 UTC
I just looked at screen shots provided in the above link. 

So what I observed here is when you filer with "WWID" option under "Multipath Devices" Tab , the name of the device is still mpath0 (i.e user_friendly_names is set to "yes" in multipath.conf).
(In ref to "Advanced Device Selection - Multipath Tab - Vendor Filter" screenshot)

What we want is, the name of the multipath device should be the unique scsi_id of that device when we chose the option "WWID" (i.e user_friendly_names should be set to "no" in multipath.conf).

Ex: When we change the "user_friendly_names" option in multipath.conf, the naming of device will be as follows.

user_friendly_names "yes"         ->      mpathX  (say mpath0)

user_friendly_names "no"          ->      360a98000433464742f6f51474e632d4a

Comment 7 Máirín Duffy 2009-08-19 19:58:56 UTC
Hi Naveen,

Thanks for the quick response! I have a couple of quick questions for you:

* Is the SCSI ID a different ID than the WWID? my assumption was that they are the same?
* if the SCSI ID is different than the WWID, how should we handle devices that do not have a SCSI ID (e.g. fiber?)

If I understood your original request in comment 0 correctly, you had asked for the mpath name to be beside the WWID, and in these mockups they are shown side-by-side per device. E.g., as you can see in this mockup both the user-friendly device name and WWID are shown in separate columns:

https://fedoraproject.org/w/uploads/thumb/b/bd/Anaconda_devselect-mpathtab2_3.png/800px-Anaconda_devselect-mpathtab2_3.png

Is it a problem if both the WWID and the multipath user-friendly device name are shown? Or is your concern more about the placement of each attribute - for example, would you rather the user-friendly device name not be shown as the first column? If so, why?

A a note, we cannot read any multipath.conf at the point this UI is running. So we can't change the behavior of the UI based on values there.

Would it be possible to back up a bit and describe in more detail the problem you'd like us to solve here? I thought the issue was that we weren't providing the WWID at all so it was difficult to identify the device you needed. However, it seems you still have concerns even though the mockups provide both WWID and user-friendly name.

Thanks!

Comment 8 Naveen Reddy 2009-08-20 06:22:22 UTC
Hi Máirín,

The WWID for the SCSI device is the SCSI ID itself.

I think there is a misunderstanding. 

Currently, when we install OS on a SANboot LUN with multiple paths, the multipathing feature "user_friendly_names" is set to "yes" by default and so the scsi device names come as "mpathX" (say mpath0) by default.

What we want is there should be an option such that "user_friendly_names" is set to "no". In that case the device names will be WWIDs (i.e SCSI ID) itself.

Ex: I am providing SCSI device name in both cases of "user_friendly_names" feature in multipathing.

1. user_friendly_names yes
       device name - mpath0

2. user_friendly_names no
       device name - 360a98000572d4461524a52334831727a

So, it is two different naming methods which we want to be available during installation. One is existing one("mpathX") and other is based on WWIDs.

It is not reading from "multipath.conf" but instead when we select the second method, the "user_friendly_names" should be set to "no" in multipath.conf and accordingly the names will be generated based on WWIDs.

Thank you.

Comment 9 Denise Dumas 2009-09-22 20:48:24 UTC
Hi Naveen, 

OK, we've reworked the storage UI several times and the latest version is at 
https://fedoraproject.org/wiki/Design/AnacondaStorageUI

This is what we're implementing, based on lots of input from a wide variety of users. Does it handle your use case now?

Comment 10 Martin George 2009-09-23 14:53:55 UTC
Denise,

Seeing the UI mentioned above, it seems both the wwid & mpath names of the devices are displayed together i.e. if you select the wwid of a particular device, it also resolves to the corresponding mpath & underlying SCSI devices & vice versa. Ultimately that would still end up with the root partition getting created on the /dev/mapper/<mpath>.

Actually the device choice should be either wwid or mpath, but not both together - if you select the wwid, the root partition should be created on the corresponding /dev/mapper/<wwid>. And if mpath is selected, the root partition should be on /dev/mapper/<mpath>.

Comment 11 Máirín Duffy 2009-09-29 17:34:53 UTC
Naveen, Martin - 

It sounds like your main concern is the naming scheme for the mount point or device name of these devices post-install, is that correct?

If so, could you explain in what scenarios you prefer the naming scheme to include the WWID and in what cases you prefer it to include the mpath name? If you cannot create it using the WWID, in what ways does that affect your operations? 

Thanks, ~m

Comment 12 Martin George 2009-10-03 08:29:53 UTC
(In reply to comment #11)
> Naveen, Martin - 
> 
> It sounds like your main concern is the naming scheme for the mount point or
> device name of these devices post-install, is that correct?

Actually no. 

> 
> If so, could you explain in what scenarios you prefer the naming scheme to
> include the WWID and in what cases you prefer it to include the mpath name? If
> you cannot create it using the WWID, in what ways does that affect your
> operations? 

I may have miscommunicated. So let me try again. Forget the naming scheme of the root mount point for now - that is an eventual outcome on whether wwid or mpath names are selected for the root device.

In the current RHEL5 anaconda, only mpath names are provided for the root device install. All that is being requested now is provide wwid names as well - but not in the manner shown in the above UI. Ensure that the user is able to select either wwid or mpath names for the root device (and not both together). So you could perhaps have a drop box where the root device resolves to either a wwid name, mpath name, etc. But at a time, the user would be able to select only one of these.

Comment 13 Máirín Duffy 2009-10-05 13:44:49 UTC
Hi Martin,

Why is it a requirement that wwid and mpath names cannot be shown together? 

Thanks,
~m

Comment 14 Denise Dumas 2009-12-03 22:04:27 UTC
I don't think we've ever gotten this request straight but we're at Beta and there's no more time. We'll be implementing the changes at 
https://fedoraproject.org/wiki/Design/AnacondaStorageUI
and hopefully that meets your needs.

Comment 15 Martin George 2009-12-14 11:58:57 UTC
(In reply to comment #13)
> Why is it a requirement that wwid and mpath names cannot be shown together? 
> 

There is no explicit requirement that wwid & mpath names should not be shown together. No issues if both are shown together, or only one at a time. The only requirement is that if one selects the wwid name, it should automatically resolve to the root device getting mounted at /dev/mapper/<wwid> during OS installation i.e. user_friendly_names is disabled.

And if selects the mpath name, it should then resolve to the root device getting 
mounted at /dev/mapper/<mpath> i.e. user_friendly_names is enabled.

As per RHEL5, you only had the choice of selecting mpath names alone which would resolve to /dev/mapper/<mpath>. All that is being requested now is to provide an additional wwid option, which would resolve to the /dev/mapper/<wwid> .

Comment 16 Martin George 2009-12-14 12:01:44 UTC
(In reply to comment #14)
> I don't think we've ever gotten this request straight but we're at Beta and
> there's no more time. We'll be implementing the changes at 
> https://fedoraproject.org/wiki/Design/AnacondaStorageUI
> and hopefully that meets your needs.  

The changes mentioned at https://fedoraproject.org/wiki/Design/AnacondaStorageUI are not seen in the RHEL6 alpha2 bits. So in which release are these changes proposed now?

Comment 17 Chris Lumens 2009-12-14 16:42:45 UTC
These changes will be in anaconda-13.11-1, which itself will show up in RHEL6 once we rebase anaconda in that tree.  I don't know the exact date for that.

Comment 18 Denise Dumas 2009-12-15 17:21:12 UTC
This will show up in Beta 1 for partners.

Comment 19 Chris Lumens 2010-01-19 15:56:08 UTC
We've rebased anaconda in RHEL6.  Once you have a beta tree with anaconda-13.21.x in it, can you please give it a test and see how well it's working for you?  This support should be much improved now.

Comment 22 Alexander Todorov 2010-07-13 16:34:23 UTC
Hi NetApp,
have you been able to test this feature with RHEL6 Beta 2 or later? What's the test result. 

Thanks.

Comment 23 Rajashekhar M A 2010-09-13 12:29:27 UTC
We checked the anaconda version - 13.21.81 (RHEL 6.0 Snapshot 13). The wwid of the devices are being shown while installation. But the option to select the name of the intended root device (whether it has to be mpath or wwid based) is not provided. By default, the installation is done on an mpath device - like /dev/mapper/mpatha even though the device is shown with the wwid name in the GUI. 

We would like to have an option provided to the user while installation itself whether the device name should be like /dev/mapper/mpatha or /dev/mapper/360a98000486e2f66426f5831337a326e and this device will be mounted for root while booting.

Comment 24 Andrius Benokraitis 2010-09-13 18:46:09 UTC
*IMPORTANT*

Partners - please test this bugzilla *immediately* and report back with a comment. Delays in test findings could impact future proposed inclusions due to failed partner test commitments. Your results are very important to Red Hat and its mutual customers.

Comment 25 Andrius Benokraitis 2010-09-13 19:49:39 UTC
I'm going to assume this is tested based on the comment - the missing piece should have a new RHEL 6.1 bugzilla to finish it up.

Comment 26 Chris Lumens 2010-09-13 19:57:18 UTC
Exposing an option in the UI allowing the user to select the style of naming they want is a terrible interface that's bound to introduce confusion for more users than it's going to help.

Comment 27 Martin George 2010-09-14 07:50:43 UTC
(In reply to comment #26)
> Exposing an option in the UI allowing the user to select the style of naming
> they want is a terrible interface that's bound to introduce confusion for more
> users than it's going to help.

What is being requested is that if the wwid of the device is selected, the machine should then boot up with the root mounted on a /dev/mapper/<wwid> device. And instead if the mpath name of the device is selected, then the root should be mounted as a /dev/mapper/<mpath> device. How that's implemented in the Anaconda is your choice - either through an additional GUI option or whatever.

The current limitation with the Anaconda is no matter what you select for root dm-multipath installations, the machine always boots up with the root mounted on /dev/mapper/<mpath> alone. All we are asking is to enable mounting root on /dev/mapper/<wwid> as well. That was the original intent of this bugzilla.

Comment 28 releng-rhel@redhat.com 2010-11-15 13:51:20 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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