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? In ovirt webadmin i cannot edit added domain - connection information is greyed out (even when storage domain in maintenance mode)

Yuriy Demchenko

On 04/03/2013 01:00 PM, Alex Leonhardt wrote:
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) ...


On 3 April 2013 08:14, Yuriy Demchenko <[email protected] <mailto:[email protected]>> wrote:

    I guess you misunderstood me
    I'm going to try this scheme:
                   |STORAGE|
    FC             /           \
        |SERV1/tgtd|    |SERV2/tgtd|
    iSCSI       \              /
             |ethernet switches|
    iSCSI            ||||||||
           |blades|blades|blades|

    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.
    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.

    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).

    Yuriy Demchenko


    On 04/02/2013 06:26 PM, Shu Ming wrote:

        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.


    _______________________________________________
    Users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.ovirt.org/mailman/listinfo/users




--
| RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co <http://www.vcore.co> | www.vsearchcloud.com <http://www.vsearchcloud.com> |

_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to