Bug 629830

I spoke with lvmguy aka Heinz Mauelshagen who seems to be the maintainer of
dmraid about this question from
https://bugzilla.redhat.com/show_bug.cgi?id=629830#c2

===
2010-09-07 12:14:38     jbrier  lvmguy: i see you do a lot of work on
dmraid, i opened several RFE on RHEV-H so that we can properly wipe out
fakeraid metadata after oen of my cust had isseus with preexisting
metadata..
2010-09-07 12:15:05     jbrier  lvmguy: engineering needs to know the
specs for the diff fakeraid specs and specifically how big of a space they
use to ensure we wipe it properly, currently rhev-h wipes first 1MB
2010-09-07 12:15:17     jbrier  can you help with finding those specs
2010-09-07 12:15:59     jbrier  RFE i'm referring to
https://bugzilla.redhat.com/show_bug.cgi?id=629830,
https://bugzilla.redhat.com/show_bug.cgi?id=629828
2010-09-07 12:17:43     lvmguy  jbrier: most fakeraid metadata is void
with the last disk sector wiped. some have backups which need 32k, so your
1mb heuristic is fine. there's only ine ancient Highpoint exxeption which
stored metadata at the beginning of each member drive
===

So now I'm kinda confused.. this casts doubt on the wiping not being done
completely, and the RFEs themselves.. 

but what else could explain this?

we were assuming that rhev h didn't wipe the fakeraid metadata properly,
and for some reason this caused the SSL certificates to fail to create
(and fail w/o logging the failure IIRC).

that doesn't make sense to me and really is why I was pushing for this to
be some sort of bug within RHEV-H and not a hardware issue (as it was kind
of suggested this was by saying we need RFE to fix the problem)

but at the same time the customer did confirm that if they remove the
logical drive they don't have this problem, and if they leave it in tact,
they do..

so i'm confused.

so i followed up a bit more..

===
2010-09-07 12:35:32     jbrier  lvmguy: so to expand on that question earlier, the reason we were thinking rhev-h wasn't wiping the metadata properly is that when the cust left the logical drive in tact rhev-h silently failed to create SSL Certs, but if cust deleted the logical drive in BIOS, no issues
2010-09-07 12:35:50     jbrier  so we figured there was some problem with wiping that metadata that creates the logical drive, do you have any idea what could explain that?
2010-09-07 12:37:19     lvmguy  jbrier: *if* you wiped the last MB *and* deactivated any mappings to any RAID sets: no
2010-09-07 12:37:43     jbrier  lvmguy: would removing the drive from the BIOS do the deactivation of the mappings?
2010-09-07 12:37:54     jbrier  removing the logical raid drive
2010-09-07 12:38:03     jbrier  i dont know what that means to deactivate the mappings
2010-09-07 12:38:15     lvmguy  jbrier: no, metadata signature would still be on
2010-09-07 12:38:33     jbrier  so that is what dd of first and last MB should take care of right?/
2010-09-07 12:38:34     lvmguy  jbrier: any active logical drives on the raid set
2010-09-07 12:38:42     lvmguy  jbrier: y
2010-09-07 12:38:49     jbrier  hm
2010-09-07 12:38:56     lvmguy  jbrier: last mb will do for your HP/Intel box
===


not sure what to make of it.. what do you guys think?

Note that in RHEL6 (and Fedora) is a new wipefs(8) command that allows to remove FS and RAID signatures. See for example:
http://karelzak.blogspot.com/2009/11/wipefs8.html

=== In Red Hat Customer Portal Case 00320256 ===
--- Comment by Brier, John on 10/18/2010 5:48 PM ---

Closing this legacy Issue Tracker ticket in favor of newly created sfdc 00363911 which now has the following BZ associated to it
BZ 629830 [RFE] Wipe metadata on local disks before RHEV-H installs

RHEV-H installer should be already wiping enough of a disk to remove fake-raid metadata.
For 5.7/6.1 we'll test this on a machine which had previously fake-raid configured.

Created attachment 501727 [details]
ovirt.log

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
For hard drives that previously had fake RAID configured, the fake RAID metadata would prevent Red Hat Enterprise Virtualization Manager from successfully installing. The installation process now wipes this metadata and Red Hat Enterprise Virtualization Manager can successfully install.

(In reply to comment #27)
> For hard drives that previously had fake RAID configured, the fake RAID
> metadata would prevent Red Hat Enterprise Virtualization Manager from
> successfully installing. The installation process now wipes this metadata and
> Red Hat Enterprise Virtualization Manager can successfully install.

It was wiped before too, bug is TestOnly to verify this.
Issue was and still is that RHEV-H cannot be installed when fake RAID is _enabled_ in the BIOS.

Thanks for the comment, Alan. How's this:
Red Hat Enterprise Virtualization Manager cannot be successfully installed on hard drives that previously had fake RAID configured and have fake RAID enabled in the BIOS. The installation process now issues an error if you attempt to install Red Hat Enterprise Virtualization Manager when fake RAID is enabled.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-For hard drives that previously had fake RAID configured, the fake RAID metadata would prevent Red Hat Enterprise Virtualization Manager from successfully installing. The installation process now wipes this metadata and Red Hat Enterprise Virtualization Manager can successfully install.+Red Hat Enterprise Virtualization Manager cannot be successfully installed on hard drives that previously had fake RAID configured and have fake RAID enabled in the BIOS. The installation process now issues an error if you attempt to install Red Hat Enterprise Virtualization Manager when fake RAID is enabled.

(In reply to comment #29)
> Thanks for the comment, Alan. How's this:
> Red Hat Enterprise Virtualization Manager cannot be successfully installed on
> hard drives that previously had fake RAID configured and have fake RAID enabled
> in the BIOS. The installation process now issues an error if you attempt to
> install Red Hat Enterprise Virtualization Manager when fake RAID is enabled.

This is about RHEV Hypervisor install, not the Manager. Replace Manager with Hypervisor.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1090.html

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-Red Hat Enterprise Virtualization Manager cannot be successfully installed on hard drives that previously had fake RAID configured and have fake RAID enabled in the BIOS. The installation process now issues an error if you attempt to install Red Hat Enterprise Virtualization Manager when fake RAID is enabled.+Red Hat Enterprise Virtualization Hypervisor cannot be successfully installed on hard drives that previously had fake RAID configured and have fake RAID enabled in the BIOS. The installation process now issues an error if you attempt to install Red Hat Enterprise Virtualization Hypervisor when fake RAID is enabled.