Please attach complete logs. Unclear if it's 3.6 or 4.0.4 - please clarify. (Originally by Yaniv Kaul)
its rhv-4.0.4. I'll attach the sosrpeort and other data shortly. (Originally by Sachin Raje)
Looking into related bugs, mentioned earlier: Some dirty LUNs are not usable in RHEV https://bugzilla.redhat.com/show_bug.cgi?id=1253640 [Nimble Storage] multipath unable to add new path https://bugzilla.redhat.com/show_bug.cgi?id=1309409 Specifically here: https://bugzilla.redhat.com/show_bug.cgi?id=1253640#c15 I think maybe this is not a vdsm bug at all? Nir, can you please check and move to platform, if needed? This is an urgent customer bug. (Originally by Marina Kalinin)
(In reply to Marina from comment #11) > Looking into related bugs, mentioned earlier: > Some dirty LUNs are not usable in RHEV > https://bugzilla.redhat.com/show_bug.cgi?id=1253640 > > [Nimble Storage] multipath unable to add new path > https://bugzilla.redhat.com/show_bug.cgi?id=1309409 > > Specifically here: > https://bugzilla.redhat.com/show_bug.cgi?id=1253640#c15 > > I think maybe this is not a vdsm bug at all? > > Nir, can you please check and move to platform, if needed? This was comment 3 . I don't think it's our issue. > This is an urgent customer bug. (Originally by Yaniv Kaul)
I agree with Yaniv, if we don't see the device in the scsi layer, vdsm can do nothing about it. Maybe we do not rescan scsi devices correctly? I suggest to move this to platform. (Originally by Nir Soffer)
Hi Zdenek, Do you think an lvm filter with a 'white-list' is the best solution for this issue as well? (as you've suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1374545#c74) Thanks! (Originally by Daniel Erez)
We've also reached the conclusion that disabling (and stopping) lvmetad is a good idea and we'll implement it in 4.0.7 and 4.1. Can you try that? (Originally by Yaniv Kaul)
Should be fixed in 4.1.1 by disabling lvmetad. (Originally by Nir Soffer)
(In reply to Nir Soffer from comment #18) > Should be fixed in 4.1.1 by disabling lvmetad. Current target milestone (for this bug) is 4.0.7. If it's intended to be fixed there, need clone, backport, etc. Otherwise - set target milestone to 4.1.1. (Originally by Yaniv Kaul)
(In reply to Yaniv Kaul from comment #19) > (In reply to Nir Soffer from comment #18) > > Should be fixed in 4.1.1 by disabling lvmetad. > > Current target milestone (for this bug) is 4.0.7. If it's intended to be > fixed there, need clone, backport, etc. This fix is also available in 4.0.7, so we should be good. I don't think we can verified since we don't know how to reproduce this issue, it is caused by race between multipath and lvm when new device is discovered. (Originally by Nir Soffer)
(In reply to rhev-integ from comment #23) > (In reply to Yaniv Kaul from comment #19) > > (In reply to Nir Soffer from comment #18) > > > Should be fixed in 4.1.1 by disabling lvmetad. > > > > Current target milestone (for this bug) is 4.0.7. If it's intended to be > > fixed there, need clone, backport, etc. > > This fix is also available in 4.0.7, so we should be good. > > I don't think we can verified since we don't know how to reproduce this > issue, it > is caused by race between multipath and lvm when new device is discovered. > > (Originally by Nir Soffer) According to this comment - this bug is verified even though it can't be reproduced. moving to VERIFIED!
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-2017-0544.html