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 <demchenko...@gmail.com> 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 > Users@ovirt.org > http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org/mailman/listinfo/users> > -- | RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co | www.vsearchcloud.com |
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users