change in default SCSI-3 Persistent Reserve settings

Yes, starting from 5875 SCSI3 Persistent Reserve is set to enabled by default. In one of the environment I worked all the new devices created was having SCSI3 enabled but I never faced any problem.

What problem did you faced because of SCSI3 being enabled? I would be interested to know.

If you want to disable the setting, can you please try running this command,

symconfigure -sid 123 -cmd "set device xxx attribute=no SCSI3_persist_reserv;" preview

Please use caution while disabling the flag on prod systems.

We had 2 cases of problems in our ESX cluster due to devices SCSI3_persist_reserv = yes.

Both times, one of the nodes in the cluster locked access to the device, and the VMs on that device stopped responding because their hosts could not access the VMDK.

That symconfigure command is what I now use on our devices after I create them.  It is an extra hassle to do so, because the SMC disregards that setting when you specifically set it to no when you create TDEVs.  EMC claims that this is a "feature", not a bug. :-/

We have an enhancement request logged with EMC to fix the SMC behavior.   I can accept that they decided to change the default behavior (EMC support doesn't sound thrilled with that decision based on who I've talked to about it), but what is definitely a bug is that the SMC doesn't do what it is specifically told to do when creating a device.

This is a known problem in the Vmware world while using SCSI3_Reservation, but we need to use SCSI3_Reservation for devices in ESX clusters. I am not sure if you can have a ESX cluster without SCSI3 Reservation.

Some of the VMFS operations cause the LUN to be locked trmporarily for use with one ESXi server:-
1) VMotion 2) Creating Snapshots 3) Powering VM on and off, etc
Suppose some other ESX server needs lock at the same time the operation may fail

This has been the case atleast till version 4.1

A new feature is introduced in Vsphere 5 known as VAAI-Hardware Assisted Locking that uses VAAI feature,

atomic_test_and_set(ATS)

Scenario with  SCSI reservations:
• Suppose we have a cluster and have some ESXi host with many VMs sharing a VMFS, all doing I/O.
• Now one ESXi needs to grow a file on behalf of a VM.
• It needs to do a SCSI reservation – disrupting all the other ESXi hosts and all the VMs.

Scenario with ATS:-

• Suppose we have a cluster and some ESXi servers with many VMs sharing a VMFS, all doing I/O.
• One ESXi needs to grow a file on behalf of a VM.
• Using ATS, the ESXi can own the LUN without causing any disruption to the other ESXi

I'm with dynamox.  We have never had to set SCSI3_persist_reserv on our ESX devices.  We upgraded to Vmax code 5875, which changed the default behavior, and since then we have had 2 lockups on new devices that were created with the new defaults.  We have not had any lock ups with devices that had the flag set to no.

In each case, changing the flag from yes to no resolved the lock up.

Sure sounds to me like the proper setting for ESX 4.1i is no.

i have never set SCSI3 Reservation for ESX and it was never required, locking is handled by VMFS.

Sounds pretty new information to me, We always used SCSI3_persist_reserv attribute for shared devices, whether its ESX or any other cluster.

I too agree with dynamox that VMFS is handling the SCSI3 reservation but I was under the impression that we need the SCSI3 attribute on devices to make it work properly on Symmetrix.

Sounds like I was wrong

I am still confused with regards to how disabling the SCSI3 attribute on devices will solve the problem with SCSI reservation that is held by ESX server.