cancel
Showing results for 
Search instead for 
Did you mean: 

Reservation Conflict in SSO Drive

rajeshthink
Level 4

Hi All,

 

This query is not about resolution but more over a deep study on Drives in SSO .

 

Reservation Conflict can be fix by below steps ..

1) check /avr/adm/message | grep -i <drive_name>

2) check which media / master server is using ./vmdareq -D <drive name>

3) ./vmoprcmd -crawlreleasebyname <drive_name> -h <host>

4)./nbrbutil -releaseDrive <drive_name>

5) relase the mds

6) check the vm.conf also device configuration

 

But even after the drive goes down amd after looking into sys logs i find Reservation Conflict.

 

 

Cheer,

Rajesh Kumar

 

1 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

 

 

I will agree 100% that the steps could be used in troubleshooting (or some of them), but the comment - "Reservation Conflict can be fix by below steps" is wrong.  The comment suggests that the problem can 'always' be fixed with these steps, which is untrue.  Given the simple fact that the majority of reservation issues have a cause outside NBU.

 

1) check /avr/adm/message | grep -i <drive_name>

2) check which media / master server is using ./vmdareq -D <drive name>

3) ./vmoprcmd -crawlreleasebyname <drive_name> -h <host>

4)./nbrbutil -releaseDrive <drive_name>

5) relase the mds

6) check the vm.conf also device configuration

 

Most of those commands don't fix anything if the reservation conflict is coming from outside NBU, which it probably is ...

1/ 2 are informational

3 - should force scsi reservations to be dropped.  I agree, if NBU has just got confused, then this might fix the issue, but if the cause is still there, it will comae back again.

4. Nothing to do with the problem

5. Does not even make sense, though I know what you mean, which you have covered with step 4.

6. If no changes have been made, won't be this.

What devices see the drives - the most likely cause is something outside NBU is trying to access the drives.

Are drives shared with none NBU servers

Are people runnnig commands on the media servers

Are you using 'monitoring software'

Check zoning - are the devices you think see the drives the ONLY devices that see the drives ....

SAN errors

etc ...

Personally,  I would probably remove and reconfigure the drives in NBU.  I would not expect this to fix the issue (it might in rare cases) but it is the only way to demonstrate that NBU isn't the cause, because you have just given it a nice shiny new config.

Then, I would start on the list above.  Do not try to troubleshoot this through NBU (providing the reconfig doesn't fix of course) because you will never solve it.  NBU won't be causing the issue, it's just showing the issue.

 

Martin

View solution in original post

2 REPLIES 2

mph999
Level 6
Employee Accredited

 

 

I will agree 100% that the steps could be used in troubleshooting (or some of them), but the comment - "Reservation Conflict can be fix by below steps" is wrong.  The comment suggests that the problem can 'always' be fixed with these steps, which is untrue.  Given the simple fact that the majority of reservation issues have a cause outside NBU.

 

1) check /avr/adm/message | grep -i <drive_name>

2) check which media / master server is using ./vmdareq -D <drive name>

3) ./vmoprcmd -crawlreleasebyname <drive_name> -h <host>

4)./nbrbutil -releaseDrive <drive_name>

5) relase the mds

6) check the vm.conf also device configuration

 

Most of those commands don't fix anything if the reservation conflict is coming from outside NBU, which it probably is ...

1/ 2 are informational

3 - should force scsi reservations to be dropped.  I agree, if NBU has just got confused, then this might fix the issue, but if the cause is still there, it will comae back again.

4. Nothing to do with the problem

5. Does not even make sense, though I know what you mean, which you have covered with step 4.

6. If no changes have been made, won't be this.

What devices see the drives - the most likely cause is something outside NBU is trying to access the drives.

Are drives shared with none NBU servers

Are people runnnig commands on the media servers

Are you using 'monitoring software'

Check zoning - are the devices you think see the drives the ONLY devices that see the drives ....

SAN errors

etc ...

Personally,  I would probably remove and reconfigure the drives in NBU.  I would not expect this to fix the issue (it might in rare cases) but it is the only way to demonstrate that NBU isn't the cause, because you have just given it a nice shiny new config.

Then, I would start on the list above.  Do not try to troubleshoot this through NBU (providing the reconfig doesn't fix of course) because you will never solve it.  NBU won't be causing the issue, it's just showing the issue.

 

Martin

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

In addition to Martin's excellent post:

Reservation Conflict is also commonly caused by lack of Persistent Binding in the environment.

In Windows environment, check that TUR is disabled: http://www.symantec.com/docs/HOWTO56216