Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

Reservation Conflict in SSO Drive

Created: 02 Oct 2012 • Updated: 05 Feb 2013 | 2 comments
rajeshthink's picture
This issue has been solved. See solution.

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.


Rajesh Kumar

Comments 2 CommentsJump to latest comment

mph999's picture

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.


Regards,  Martin
Setting Logs in NetBackup:
Marianne's picture

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:


Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links