<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">You mean add new path by hands on each
      node via iscsiadm ? And how that changes survive possible node
      reboots / reinstalls, as i suppose - it wouldn't?<br>
      In ovirt webadmin i cannot edit added domain - connection
      information is greyed out (even when storage domain in maintenance
      mode)<br>
      <br>
      <pre class="moz-signature" cols="72">Yuriy Demchenko</pre>
      On 04/03/2013 01:00 PM, Alex Leonhardt wrote:<br>
    </div>
    <blockquote
cite="mid:CAH4_GUvgqzh+h9vd6mE1TxTxb+bKTVXS1R3_D14OKe+ZvP_5ZA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default" style="font-size:small">I think i'd
          just add the 2nd path when the device is available ... i've
          recently exprimented with iscsi / tgtd and multipath on a
          ovirt hyper-visor and it will identify the disk as "the same"
          (new path to target) as long as the LUN ID is the same (this
          is taken from experience, not from a spec document) ...&nbsp;</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 3 April 2013 08:14, Yuriy Demchenko
          <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:demchenko.ya@gmail.com" target="_blank">demchenko.ya@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess
            you misunderstood me<br>
            I'm going to try this scheme:<br>
            &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|STORAGE|<br>
            FC &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; / &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \<br>
            &nbsp; &nbsp; |SERV1/tgtd| &nbsp; &nbsp;|SERV2/tgtd|<br>
            iSCSI &nbsp; &nbsp; &nbsp; \ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/<br>
            &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|ethernet switches|<br>
            iSCSI &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;||||||||<br>
            &nbsp; &nbsp; &nbsp; &nbsp;|blades|blades|blades|<br>
            <br>
            serv1/serv2 - connectivity isnt a problem, multipathed FC
            scheme, all good. Same lun accessible for both servers and
            than exported via tgtd to iSCSI: with different target names
            ("iqn.2013-03.serv1:store", "iqn.2013-03.serv2:store"), but
            same vendor_id, product_id, scsi_sn, scsi_id. That way
            client can login into both targets and see lun as
            multipathed device.<br>
            And multipath failover scheme (via custom config with
            path_grouping_policy=failover for corresponding
            vendor_id/product_id) is on blades-clients - so they use
            only one target at time (no round-robin or similar stuff),
            but with ability to switch to another target in case one of
            serv1/serv2 is down.<br>
            <br>
            However, in my case "serv2" would not be available during
            oVirt setup (need to setup ovirt and virtual servers to move
            stuff first), so i cant enter both targets on storage domain
            initialization - that's why I'm asking if there's any way to
            edit storage domain details after initialization without
            destroying it (maybe directly via sql or something).<span
              class="HOEnZb"><font color="#888888"><br>
                <br>
                Yuriy Demchenko</font></span>
            <div class="im HOEnZb"><br>
              <br>
              On 04/02/2013 06:26 PM, Shu Ming wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                I am not sure if the multipathd can recognize the FC
                path to the storage when the second server is available
                and regards it as the same as the iSCSI path used
                before. If it is not, I think the device under
                /dev/mapper may change when you cut the iSCSI path off
                and then enable FC path. That will definitely corrupt
                the meta data of the volume group which the storage
                domain is sitting on and the storage domain will be
                corrupted finally. <br>
              </blockquote>
              <br>
            </div>
            <div class="HOEnZb">
              <div class="h5">
                _______________________________________________<br>
                Users mailing list<br>
                <a moz-do-not-send="true" href="mailto:Users@ovirt.org"
                  target="_blank">Users@ovirt.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.ovirt.org/mailman/listinfo/users"
                  target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr">| RHCE | Sen Sys Engineer / Platform Architect |
          <a moz-do-not-send="true" href="http://www.vcore.co"
            target="_blank">www.vcore.co</a> | <a
            moz-do-not-send="true" href="http://www.vsearchcloud.com"
            target="_blank">www.vsearchcloud.com</a> | <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>