<div dir="ltr"><div class="gmail_default" style="font-size:small">but you can add a iscsi disk to a existing iscsi domain ... see attached screenshot .. .if the disk you're adding has the same LUN ID as the already existing one, ovirt will just "add it" as a 2nd / 3rd / 4th and so forth path ... </div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 April 2013 10:49, Yuriy Demchenko <span dir="ltr"><<a href="mailto:demchenko.ya@gmail.com" target="_blank">demchenko.ya@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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)<span class="HOEnZb"><font color="#888888"><br>
<br>
<pre cols="72">Yuriy Demchenko</pre></font></span><div><div class="h5">
On 04/03/2013 01:00 PM, Alex Leonhardt wrote:<br>
</div></div></div><div><div class="h5">
<blockquote 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) ... </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 3 April 2013 08:14, Yuriy Demchenko
<span dir="ltr"><<a href="mailto:demchenko.ya@gmail.com" target="_blank">demchenko.ya@gmail.com</a>></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>
|STORAGE|<br>
FC / \<br>
|SERV1/tgtd| |SERV2/tgtd|<br>
iSCSI \ /<br>
|ethernet switches|<br>
iSCSI ||||||||<br>
|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><font color="#888888"><br>
<br>
Yuriy Demchenko</font></span>
<div><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>
<div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a 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 href="http://www.vcore.co" target="_blank">www.vcore.co</a> | <a href="http://www.vsearchcloud.com" target="_blank">www.vsearchcloud.com</a> | <br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div></div>| RHCE | Sen Sys Engineer / Platform Architect | <a href="http://www.vcore.co" target="_blank">www.vcore.co</a> | <a href="http://www.vsearchcloud.com" target="_blank">www.vsearchcloud.com</a> | <br>
</div>
</div>