I noticed a discussion on an internal mailinglist which mentioned the advanced setting “Disk.UseDeviceReset” as it is mentioned in the FC SAN guide. The myth that you need to set this setting to “0 “in order to allow for Disk.UseLunReset to function properly has been floating around too long. Lets discuss first what this options does. In short, when an error or SCSI reservations need to be cleared a SCSI reset will be send. We can either do this on a device level or on a LUN level. With device level meaning that we will send it to all disks / targets on a bus. As you can imagine this can be disruptive and when there is no need to reset a SCSI but this should be avoided. With regards to the settings here is what will happen with the different settings:
-
Disk.UseDeviceReset = 0 & Disk.UseLunReset = 1 --> LUN Reset
-
Disk.UseDeviceReset = 1 & Disk.UseLunReset = 1 --> LUN Reset
-
Disk.UseDeviceReset = 1 & Disk.UseLunReset = 0 --> Device Reset
I hope that this makes it clear that there is no point in changing the Disk.UseDeviceReset setting as Disk.UseLunReset overrules it.
ps: I filed a document bug and hope that it will be reflected in the doc soon.
Thanks for clearing that up Duncan.
I can take this setting out of my vCLI script that I run against new ESXi installs
Maybe it’s wise to update your own recommendation with this new info since search engines will point people directly to your former articles.
http://www.yellow-bricks.com/2008/07/21/queuedepth-and-whats-next/
http://www.yellow-bricks.com/2009/03/09/set-diskusedevicereset-with-powershell/
yes I was about to do that… but I have a day job as well
Great stuff. Thanks for the info. Good to know. For now I’ll just put a reference to your article in our design documents. Keep us posted on when it is fixed in the documents
On another note, my SAN vendor had me set this option on two new ESXi installs. The first reboot was fine, afterward, the hosts would take …3 HOURS TO BOOT!!! And if I ran a rescan, I could not see networking components or storage adapters in the system.
I found this related to the boot issue:
iscsi_vmk loaded successfully (Where you see this message at boot time for an hour)
as well as this message later on:
nbr_filter loaded successfully
Running usbarbitrator start
I have reverted the setting back to 1, boot still takes a while, but certainly not 3 hours. I have multipathing in place and setup on adapters that are not in use as I’m still testing right now, so that may also have something to do with my boot times.
Is this information cleared with VMware officials? I mean, where did you get this info, and how can I trust it when it contradicts VMware’s own doc on the subject?
@Rasmus: I am a VMware employee. I have submitted this as a document bug, it has until now unfortunately never been fixed. I will try to bring this under the attention again of the doc team.