[Users] way to edit iSCSI storage domain?
Hi, is there any way to edit iSCSI storage domain: change/add targets ? (lun, id, sn and actual content wouldn't be affected) Without VM export/import process - downtime should be as little as possible. I'm researching possibility to use oVirt in env where I have only FC storage, connected to 2 servers (and sadly, second server will be available later, hence my question about changing targets in oVirt) and bunch of blades, on which i would like to run virtualization (no fc storage connectivity) - so idea is to share storage via iSCSI/tgtd and use multipathd with failover mode to protect from storage corruption. -- Yuriy Demchenko
Yuriy Demchenko:
Hi,
is there any way to edit iSCSI storage domain: change/add targets ? (lun, id, sn and actual content wouldn't be affected) Without VM export/import process - downtime should be as little as possible.
I'm researching possibility to use oVirt in env where I have only FC storage, connected to 2 servers (and sadly, second server will be available later, hence my question about changing targets in oVirt) and bunch of blades, on which i would like to run virtualization (no fc storage connectivity) - so idea is to share storage via iSCSI/tgtd and use multipathd with failover mode to protect from storage 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.
corruption.
-- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming@cn.ibm.com or shuming@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC
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.
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@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 |
This is a multi-part message in MIME format. --------------010702090104000703040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 <demchenko.ya@gmail.com <mailto:demchenko.ya@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 <mailto:Users@ovirt.org> 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> |
--------------010702090104000703040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <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) ... </div> </div> <div class="gmail_extra"><br> <br> <div class="gmail_quote">On 3 April 2013 08:14, Yuriy Demchenko <span dir="ltr"><<a moz-do-not-send="true" 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 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> --------------010702090104000703040900--
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 ... On 3 April 2013 10:49, Yuriy Demchenko <demchenko.ya@gmail.com> wrote:
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 <demchenko.ya@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
-- | RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co | www.vsearchcloud.com |
-- | RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co | www.vsearchcloud.com |
This is a multi-part message in MIME format. --------------080606070708070207050403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit oh, now i see my mistake was putting storage domain in maintenance - when it in maintenance, all options is greyed out, but when active - discover&login options awailable. Thanks for help! Yuriy Demchenko On 04/03/2013 07:05 PM, Alex Leonhardt wrote:
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 ...
On 3 April 2013 10:49, Yuriy Demchenko <demchenko.ya@gmail.com <mailto:demchenko.ya@gmail.com>> wrote:
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 <demchenko.ya@gmail.com <mailto:demchenko.ya@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 <mailto:Users@ovirt.org> 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> |
-- | RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co <http://www.vcore.co> | www.vsearchcloud.com <http://www.vsearchcloud.com> |
--------------080606070708070207050403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <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">oh, now i see<br> my mistake was putting storage domain in maintenance - when it in maintenance, all options is greyed out, but when active - discover&login options awailable.<br> <br> Thanks for help!<br> <pre class="moz-signature" cols="72">Yuriy Demchenko</pre> On 04/03/2013 07:05 PM, Alex Leonhardt wrote:<br> </div> <blockquote cite="mid:CAH4_GUu-mWekHq_WeG=gvrW-LWWO1LTwHTHwHX5k1jCAstq7Ow@mail.gmail.com" type="cite"> <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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 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> </div> </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> --------------080606070708070207050403--
Yuriy Demchenko:
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|
I am still confused if SERV1/SERV2 are used as a iSCSI bridge to the storage only or used as VDSM host also? If they are used as VDSM host and both of them can have FC channel to the storage, why not create FC storage domain for them instead of iSCSI domain?
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.
-- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail:shuming@cn.ibm.com orshuming@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC
they're used only as iSCSI bridge, VM's would be running on other servers (blades) that have no FC connectivity Yuriy Demchenko On 04/03/2013 07:15 PM, Shu Ming wrote:
I am still confused if SERV1/SERV2 are used as a iSCSI bridge to the storage only or used as VDSM host also? If they are used as VDSM host and both of them can have FC channel to the storage, why not create FC storage domain for them instead of iSCSI domain?
participants (3)
-
Alex Leonhardt -
Shu Ming -
Yuriy Demchenko