9:44 a.m.
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
10:26 a.m.
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(a)cn.ibm.com or
shuming(a)linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193,
PRC
3:14 a.m.
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.
5 a.m.
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 |
5:49 a.m.
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(a)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(a)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(a)gmail.com</a>&gt;</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(a)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/user...
</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--
11:05 a.m.
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(a)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(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
>
--
| RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co |
www.vsearchcloud.com |
--
| RHCE | Sen Sys Engineer / Platform Architect | www.vcore.co |
www.vsearchcloud.com |
11:15 a.m.
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(a)linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193,
PRC
5:07 a.m.
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(a)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(a)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(a)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(a)gmail.com</a>&gt;</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(a)gmail.com</a>&gt;</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(a)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/user...
</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--
5:10 a.m.
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?
4052
days inactive
4054
days old
8 comments
3 participants
participants (3)
-
Alex Leonhardt -
Shu Ming -
Yuriy Demchenko