Thank you for your help! I will try your suggestions shortly.

I am not quite sure about the iSCSI reset to be honest, I just tell
what the open-e interface tells me.
the strange thing is that yesterday I did create some stuff on the
open-e san that needed the 'reset' again. and my server continued
working just fine, no broken raid this time.

Maybe software raid is not supported on top of iSCSI. But if you want
a redundant storage layer and you don't have a lot of money it, it's
really a great sollution :-)

On Apr 23, 8:29 pm, Konrad Rzeszutek <> wrote:
> On Thu, Apr 23, 2009 at 04:07:15PM +0200, Ulrich Windl wrote:
> > On 23 Apr 2009 at 4:48, Omko wrote:
> > > The situation:
> > > I have 2 sans (brand is: open-e, runs open-iscsi I think).
> IET to be exact.
> > > on both san's I create a target.
> > > I have 1 server. the recieves the targets from both san's.
> > > next the server does a raid1 on the two iSCSI disks.
> > > I do run multipath to the san
> > > and this works like a charm. When one of the san's fails, my server
> > > continues working.
> > > The problem:
> > > When I add a new target on the SAN it has to do a iSCSI reset. If I do
> > > this the server drops the connection to the san, the raid1 is broken.
> You can make an entry in the multipath.conf that would have
> 'queue_if_no_path' entry which would allow the I/O to be queued during
> this outtage. What is an iSCSI reset? Is it Open-E logging out the
> initiator?
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to