Bug 1463122 - [GSS] RHCI deployment fails with Device /dev/sdb not found (or ignored by filtering). [NEEDINFO]
[GSS] RHCI deployment fails with Device /dev/sdb not found (or ignored by fil...
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gdeploy (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Sachidananda Urs
Manisha Saini
Depends On:
  Show dependency treegraph
Reported: 2017-06-20 03:54 EDT by Roman Hodain
Modified: 2018-03-20 01:30 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Gluster
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
surs: needinfo? (rreddy)
surs: needinfo? (dkota)

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3106491 None None None 2017-07-06 07:54 EDT

  None (edit)
Description Roman Hodain 2017-06-20 03:54:19 EDT
Description of problem:
When installing Red Hat Hyperconverge Infrastructure via Cockpit, it is not possible to create the bricks as it is not possible to create LVM PVs on the physical devices.

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

How reproducible:

Steps to Reproduce:
1. install latest RHV-H
2. Try to deploy RHCI
3. Specify sdb device in Brick section

Actual results:
    Device /dev/sdb not found (or ignored by filtering).

Expected results:
    PV is created

Additional info:
    The RHCI deployment tool tries to create PVs on top of devices in /dev, but these devices are filtered out as a multipath device is created on top of them. It is also not possible to specify the LUN device as it is looked up in /dev/<LUN_ID> which does not exists.

Either the tool should expect the the LUN as the parameter or the node should allow /dev/sd.. devices.
Comment 1 Ryan Barry 2017-06-20 05:26:24 EDT
The LVM filtering here is not done by RHVH, but vdsm.

If the gluster wizard cannot use multipath devices, work will need to be done with the vdsm team to make the filtering more granular.
Comment 3 Ryan Barry 2017-06-20 08:33:47 EDT
That depends on whether the WWN is the same and multiple systems are connecting to a device that only has a single path, but yes.

Either way, it is vdsm which does this. Is this reproducible on RHEL?
Comment 5 Nir Soffer 2017-06-20 11:08:27 EDT
Ryan, Vdsm does not filter /dev/sdb, this may be wrong configuration on
gluster side, or some other issue, but this not a vdsm issue.

Vdsm is working only with /dev/mapper/xxxyyy devices, we never touch or look at
/dev/sd* devices.
Comment 6 Ryan Barry 2017-06-20 11:16:15 EDT
Thanks Nir. I thought you also filtered local devices.
Comment 7 Nir Soffer 2017-06-20 12:19:13 EDT
Ryan, if you have a host reproducing this issue, can you share the contents of 
/etc/multipath.conf before and after vdsm is installed?
Comment 8 Ryan Barry 2017-06-20 13:00:59 EDT
Hey Nir --

I recently moved, and I don't have a reproducer. Nor do I have an iSCSI/FC environment I can reproduce on for a couple of weeks.


Can one of you please provide an sosreport? Or at least /etc/multipath* and /etc/lvm* ?

Specifically, lvm.conf, lvmlocal.conf, and multipath.conf, though a complete sosreport would be better.
Comment 14 Roman Hodain 2017-07-06 05:22:57 EDT
moving to Red Hat Gluster (gdeploy) for blacklisting the local storage during the setup.
Comment 20 Sachidananda Urs 2017-07-27 05:50:49 EDT
Roman, here is another solution I found for this problem:


Device /dev/sdb not found (or ignored by filtering) (Try vgreduce --removemissing this as well)
do dmsetup table to see whether any device is part of multipath
Edit /etc/multipath.conf by adding
blacklist {
        wwid "*"
systemctl restart multipathd.service
Now again do pvcreate it would work
pvcreate /dev/sdb
WARNING: dos signature detected on /dev/sdb at offset 510. Wipe it? [y/n]: y


Since this is not gdeploy issue, I think we should close this bug and raise
a doc bug and document how to solve such issues.

I suggest we do not add this solution into gdeploy.
Comment 21 Roman Hodain 2017-07-29 09:38:08 EDT

this workaround is mentioned in the KC solution assigned to this bugzilla.

The problem here is that it is an installation issue. I assume that gdeploy is here to automate the installation so the users do not have to do it manually. gdeploy has enough information to handle the configuration. We should avoid any manual configuration done by the user as they can broke the node. RHCI is a complicated product even with automated installation and adding some additional manual steps make it worse.

Obviously the final decision is up to you.

Comment 22 Sachidananda Urs 2017-08-03 04:55:36 EDT
Roman, I agree with your argument, we are in the process of collecting all known
possible pre-installation issues. Which eventually should go into sanity-check
script. We will keep it updated as and when we encounter new issues.

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