Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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.

In the following scenario (HA cluster storage split):

RHEL 6.6 stretch cluster with lvm2-2.02.111-2.el6_6.1.x86_64 using lvm mirror with segment_type=raid1

- Service running in node1
- The storage that becomes split. 
The cluster is happy because quorum is maintained. Granted, only one side will be running and there is no corruption yet.
- But the service could be relocated to the other side for any number of reasons.  
- Both sites believe the disk from the other site has failed and both sites have changed the contents of their storage.

There are ways to avoid this scenario from resource manager point of view, for instance using partial_activation in pacemaker lvm resource agent, but is there a way to prevent this from a storage point of view?

What if the service is stopped and need to be started while the storage is still split, how can we identify which path of the mirror was the last to be modified?

I want to point out that if a storage (but not cluster) split is a concern, multipathing should be employed to ensure redundancy of the storage connections.