In my previous post, VMFS 5/6 and VMFS locking, I discussed characteristics of both VMFS versions along with upgrade possibilities and VMFS locking mechanisms. Why am I talking about it then?
Well, the reason is that, topic of this post, SCSI – 3 Persistent Reservation is an extension of our discussion on SCSI-2 Reservations from previous post. With vSphere 7, VMware has added support for SCSI – 3 PR at the virtual disk (VMDK) level. So the question that comes to mind, What is new with SCSI-3 PR?
We already discussed shortcomings of SCSI Reservations locking mechanism that if SCSI Bus reset is performed, lock on LUN will be released even if the ESXi host that locked the LUN by sending SCSI-Reserve command has not released it.
The SCSI-3 Persistent Reservation addresses this concern by adding the ability for the reservation to persist even if the SCSI bus is reset due to error recovery. In SCSI – 3 PR, this is done by using the SCSI Persistent Reserve Out and Persistent Reserve IN commands.
Persistent reserve in
Used by the initiator on host to read information on the target about existing reservations and registrations.
Persistent reserve out
Used by the initiator on host to register, alter its reservations, and break reservations for error recovery
How does SCSI-3 Persistent Reservations Work?
SCSI-3 PR provides mechanisms to control access to shared device.
SCSI-3 PR uses a concept of registration and reservation as mentioned earlier. Multiple system can registers its own key (called as PR_Key) with a shared SCSI-3 device. After this, registered systems can establish the reservation in any of following mode.
- Write Exclusive (WE)
- Exclusive Access (EA)
- Write Exclusive – Registrants Only (WERO)
- Exclusive Access – Registrants Only (EARO)
- Write Exclusive – All Registrants (WEAR)
- Exclusive Access – All Registrants (EAAR)
Check with storage vendor for supported mode and working in supported mode.
With SCSI-3 PR, blocking write access or removing a registration from a device is a simple process. Only registered members can eject the registration of other members. If a system needs to eject other system, it may register itself, preempt or clear the other registered initiators.
When a Reservation conflict response is sent from the target to an initiator, the conflicting initiator will need to retry the reserve request. The host initiator’s OS will control at what interval the reserve request is retried. The conflicting host will continue to get a reservation conflict status from the target, until one of the following events occurs:
- The controlling host sends a release command.
- A SCSI bus device reset is issued from any initiator.
That’s it for this post. This is just an overview of SCSI-3 PR. Since I have limited research scope for this, we’ll have to wrap it up with just overview. I hope it will be informative to you.