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.
Barrie says
Thanks for clearing that up Duncan.
I can take this setting out of my vCLI script that I run against new ESXi installs 🙂
Bas says
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/
Duncan Epping says
yes I was about to do that… but I have a day job as well 🙂
Dennis Agterberg says
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
Eddie says
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.
Rasmus Teglgaard says
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?
Duncan Epping says
@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.
Eyal Tamir says
Hi Duncan,
I have bumoped into this today again…this appears both in vSphere4.1 and vSphere5 Docs for FC + iSCSI guides. the fact that this not inlign with the default setting for DeviceReset (default value is 1, VMware doc specify it needs to be 0)is problematic, especially when we’re dealing with such a delicate issue as storage. As you mention in your article, this can be safely ignored since LUNreset will override this, however this is indeed confusing.
Thanks,
Eyal
Guido says
Hi Duncan,
Since last week our Storage Vendor (Datacore) recommends changing Devicereset from 1 to 1. But according to this it seems useless… Strange 🙂
Disk.UseLunReset to 1
Disk.UseDeviceReset to 0
Greetings,
Guido
Duncan says
It is just an old invalid best practice that not many have updated yet unfortunately.
Bob Schumway says
Duncan,
Sure, this is interesting, but only to some degree. I’m going to continue to set Disk.UseDeviceReset to zero. Presumably there is no harm in setting it to zero, and moreover it makes it more clear just what the intention is; even if it doesn’t change the behavior; why wouldn’t I want to set it to zero?
For anyone rushing to take it out of their scripts, I’d recommend reconsidering. I’d care as much about have the configuration represent my intentions, as I do about it working correctly.
Cheers,
Bob
Duncan Epping says
there is no harm leaving it in there, but then again… there is also no point. Only thing I was trying to do is explain what does what,