Forum Discussion

rajeshthink's avatar
rajeshthink
Level 4
13 years ago

Reservation Conflict in SSO Drive

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

 

Backup and Recovery
Case Study
NetBackup
Performance
Troubleshooting
  • mph999's avatar
    mph999
    13 years ago

     

     

    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

  • mph999's avatar
    mph999
    Level 6
    13 years ago

     

     

    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