<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
<div>Right, I agree. I was just seeing if anyone from ClusterLabs or Red Hat could give a "formal" recommendation to use WWIDs - it's just an up hill battle for us on my team without an actual recommendation or documentation from the creators/maintainers. Ha!<br></div><div dir="auto"><br></div><div dir="auto">Thanks all!<br></div><div style="16px"><br></div><div style="16px">Respectfully,<br></div><div style="16px"> Tyler Phillippe<br></div><div><br></div><div><br></div><div><br></div><div>Apr 21, 2023, 4:56 PM by jerome.becot@deveryware.com:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><p>Well,<br></p><p>If you use friendly names bare, you can swap disk names if your
      system loose connection to the SAN Array and reconnects with many
      factors. If you configure static device names in the config, you
      probably already configure wwids ? Then it's more reliable to not
      declare them in the configure and disable friendly names, so disks
      are identified by their WWID directly.<br></p><p>Regards<br></p><div class="">Le 21/04/2023 à 22:41, Tyler Phillippe
      via Users a écrit :<br></div><blockquote type="cite"><div>LVM (currently) isn't an option for us since most of the team
        is unfamiliar with it. We use Puppet to push out the
        multipath.conf and are trying to prevent against a badly written
        or changed config file being pushed to the PCS servers - that's
        what I meant by corruption, more so than actual bit corruption.
        Was thinking if the Filesystem resource pointed to the WWID,
        since that can only change on the SAN box, even if the
        multipath.conf was wrong or the aliases changed, the resource
        wouldn't know/care/fail.<br></div><div dir="auto"><br></div><div dir="auto">Thanks!!<br></div><div><br></div><div>Respectfully,<br></div><div> Tyler Phillippe<br></div><div><br></div><div><br></div><div><br></div><div>Apr 20, 2023, 9:36 PM by <a href="mailto:nwahl@redhat.com" class="" rel="noopener noreferrer" target="_blank">nwahl@redhat.com</a>:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>On Thu, Apr 20, 2023 at 1:49 PM Tyler Phillippe via Users<br></div><div><a href="mailto:users@clusterlabs.org" class="" rel="noopener noreferrer" target="_blank"><users@clusterlabs.org></a> wrote:<br></div><blockquote><div><br></div><div>Hello all,<br></div><div><br></div><div>In my position, we are running several PCS clusters that
            host NFS shares and their backing disks are SAN LUNs. We
            have been using the /dev/mapper/<multipath-alias> name
            as the actual device when defining a PCS Filesystem
            resource; however, it was brought up that potentially the
            multipath configuration file could be corrupted in any
            number of accidental ways. It was then proposed to use the
            actual SCSI WWID as the device, under
            /dev/disk/by-id/scsi-<wwid>. There has been discussion
            back and forth on which is better - mostly from a peace of
            mind perspective. I know Linux has changed a lot and
            mounting disks by WWID/UUID may not strictly be necessary
            any more, but I was wondering what is preferred, especially
            as nodes are added to the cluster and more people are
            brought on to the team. Thanks all!<br></div></blockquote><div><br></div><div>I almost always see users configure LVM logical volumes
          (whose volume<br></div><div>groups are managed by LVM-activate resources) as the device
          for<br></div><div>Filesystem resources, unless they're mounting an NFS share.<br></div><div><br></div><div>I'm not aware of the ways that the multipath config file
          could become<br></div><div>corrupted (aside from generalized data corruption, which is
          a much<br></div><div>larger problem). It seems fairly unlikely, but I'm open to
          other<br></div><div>perspectives.<br></div><blockquote><div>Respectfully,<br></div><div>Tyler Phillippe<br></div><div>_______________________________________________<br></div><div>Manage your subscription:<br></div><div><a href="https://lists.clusterlabs.org/mailman/listinfo/users" class="" rel="noopener noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br></div><div><br></div><div>ClusterLabs home: <a href="https://www.clusterlabs.org/" class="" rel="noopener noreferrer" target="_blank">https://www.clusterlabs.org/</a><br></div></blockquote><div><br></div><div><br></div><div><br></div><div>--<br></div><div>Regards,<br></div><div><br></div><div>Reid Wahl (He/Him)<br></div><div>Senior Software Engineer, Red Hat<br></div><div>RHEL High Availability - Pacemaker<br></div></blockquote><div dir="auto"><br></div><div><br></div><pre class="" wrap="">_______________________________________________
Manage your subscription:
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" class="" rel="noopener noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a>

ClusterLabs home: <a href="https://www.clusterlabs.org/" class="" rel="noopener noreferrer" target="_blank">https://www.clusterlabs.org/</a>
<br></pre></blockquote><div class=""><div>--<br></div><div class=""><div><b><span style="color:#002060">Jérôme
            BECOT</span></b> <span style="color:#002060"></span><br></div><div> <span style="color:#002060">Ingénieur DevOps Infrastructure </span><br></div><div> <br></div><div> <span style="color:#002060">Téléphone fixe: </span> <span style="color:#002060;mso-fareast-language:FR">01 82 28 37 06</span><br></div><div> <span style="color:#002060">Mobile : +33 757 173 193</span><br></div><div> <span style="color:#002060">Deveryware - 43 rue Taitbout - 75009
          PARIS</span><br></div><div> <a href="https://www.deveryware.com" rel="noopener noreferrer" target="_blank"> <span style="color:#002060"><span> https://www.deveryware.com</span></span></a><br></div></div><div class=""><div> <span style="color:#002060;mso-fareast-language:FR"></span><br></div><div> <img alt="Deveryware_Logo" src="cid:part1.k23sQuV0.RvnC3My0@deveryware.com" class="" width="402" height="107"><a href="https://www.deveryware.com" rel="noopener noreferrer" target="_blank"><span style="color: rgb(8, 99, 143); text-decoration: none;"><span class="size" style="font-size:10pt"></span></span></a><br></div></div></div></blockquote><div dir="auto"><br></div>  </body>
</html>