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.ya(a)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(a)ovirt.org
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
--
| RHCE | Sen Sys Engineer / Platform Architect |
www.vcore.co |
www.vsearchcloud.com |