Yellow Bricks

by Duncan Epping

Disk.UseDeviceReset do I really need to set it?

· ·

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.

Reader Interactions

Comments

  1. Thanks for clearing that up Duncan.

    I can take this setting out of my vCLI script that I run against new ESXi installs 🙂

  3. 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

  4. 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.

  5. 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?

  6. @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.

  7. 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

  8. 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

  9. It is just an old invalid best practice that not many have updated yet unfortunately.

  10. 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