TruCluster
cancel
Showing results for 
Search instead for 
Did you mean: 

Persistent reservation problem with MSA1000

Martin Begley
Occasional Advisor

Persistent reservation problem with MSA1000

I have a 2 x DS20e cluster with 2 x MSA1000 arrays connected via Fibre Channel, running Tru64/TruCluster V5.1B-3.

I formed the cluster from one system and all seemed OK. Ran clu_add_member and then when it prompted I went to the other DS20e and tried to boot it.

It failed to boot with a "reservation conflict" on the boot disk, i.e. it completely failed to open the boot device.

From the booted member I looked at all the disks presented via the MSA1000 arrays using SCU and they all have persistent reservations set on them.

I have tried to clear these reservations using SCU but it just returns a CAM error.

So I tried shutting down the booted member and then the second member did start the boot process but it gets as far as trying to mount its boot disk and hangs (again presumably because the reservation is still there).

Any suggestions?

I can't use cleanPR because it does not "know" about MSA1000s.

I've had this before with other non Digital/Compaq/HP SAN storage but can't remember how I got around it as it was several years ago.

The bit I have difficulty understanding is why the cluster software takes out a persistent reservation on ALL the disks when techically it has not been informed about them all, i.e. it is only using 1 disk for the cluster /, /usr and /var and 1 disk for the member boot and 1 for the quorum so why does it take out reservations on ALL the disks it can see?
6 REPLIES
Ivan Ferreira
Honored Contributor

Re: Persistent reservation problem with MSA1000

Last time we had reservation problems we solved by turning off the device (EVA).

The problem started with a problem in the lan interconnect. Then we migrated to memory channel to avoid the problem.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Johan Brusche
Honored Contributor

Re: Persistent reservation problem with MSA1000


To answer your question: why was persistent reservation set ?
Well to create the boot disk the 1st member had to disklabel and mount it, so a reservation was certainly taken at that moment.

Btw, did you use the SCU"preserve release" command or SCU"release" command ?

Rgds,
Johan.

_JB_
Ivan Ferreira
Honored Contributor

Re: Persistent reservation problem with MSA1000

No, I did not. It was not necessary in our case. But I will attach the file that describes the process if you need it.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Martin Begley
Occasional Advisor

Re: Persistent reservation problem with MSA1000

I tried both "scu release" and "scu preserve" but both returned CAM errors.
Ivan Ferreira
Honored Contributor

Re: Persistent reservation problem with MSA1000

Have you tried booting the newly created member with the old member down.

Shutdown the other member, and run:

init
wwidmgr -clear all

And try to boot the new member.

It looks extrange to me this problem, ensure that you reviewed the following doc:

h30097.www3.hp.com/docs/updates/msa1000/msa1000.pdf
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Martin Begley
Occasional Advisor

Re: Persistent reservation problem with MSA1000

I have finally managed to get the second member to boot by turning everything off.