Comments on: VMware ESX Guest OS I/O Timeout Settings (for NetApp Storage Systems)

By: VMware tools disk timeout value Linux GOS |

VMware tools disk timeout value Linux GOS | — Wed, 28 Apr 2010 11:49:32 +0000

[...] while ago Jason wrote an excellent article about the values and benefit of increasing the guest os [...]

By: VMware ESX Guest OS I/O Timeout Settings (for NetApp Storage … | VirtualizationDir - Top Virtualization Providers, News and Resources

Sun, 01 Nov 2009 10:25:32 +0000

[...] is the original post: VMware ESX Guest OS I/O Timeout Settings (for NetApp Storage … Plurk This Post Delicious Digg This Post MySpace Ping This Post Reddit This Post [...]

By: Jase McCarty

Jase McCarty — Fri, 30 Oct 2009 23:18:19 +0000

Well, I did somewhat of a follow up. A quick way to push changes out to a bunch of Windows guests remotely.

Here’s the post:
http://www.jasemccarty.com/blog/?p=393

Thanks,
Jase

By: Chad Sakac

Chad Sakac — Fri, 30 Oct 2009 08:48:06 +0000

Sorry – one typo… Meant to say:

“NetApp FAS and EMC Celerra (as well as all other clustered NAS platforms that I know of) **cluster failover is** unbounded in NAS use cases – meaning that we work hard to make it as short as possible, but the amount of time it can take for a cluster failover varies based on a number of factors.

By: Chad Sakac

Chad Sakac — Fri, 30 Oct 2009 08:44:16 +0000

Disclosure – I’m an EMC employee.

The question of extending the guest timeouts, and the rationale behind it is also covered in the EMC/NetApp “Multivendor NFS” post which can be seen on my blog here http://virtualgeek.typepad.com/virtual_geek/2009/06/a-multivendor-post-to-help-our-mutual-nfs-customers-using-vmware.html as well as on Vaughn Stewart’s at NetApp.

NetApp FAS and EMC Celerra (as well as all other clustered NAS platforms that I know of) is unbounded in NAS use cases – meaning that we work hard to make it as short as possible, but the amount of time it can take for a cluster failover varies based on a number of factors.

It’s my opinion (not trying to imply it is that of NetApp’s, but I would exepct that it would be), that we believe that the long term goal is to progressively shorten and further bound (so it’s not dependent on variables) NAS failover time under the default OS timeout values so changes are not needed.

Whereas some things that are very handy on NAS devices as compared to block models, architecturally, some things are a lot harder from an engineering standpoint – this is one of them.

By: Leif Hvidsten

Leif Hvidsten — Fri, 30 Oct 2009 03:43:36 +0000

I concur with Justin regarding cluster failovers and non-disruptive upgrades. It’s one of the large reasons NetApp has the host utility kits (HUK) for the various platforms connecting to their storage.
Jason, thanks for pointing out this KB. NetApp is trying to make this easier with their Virtual Storage Console that was just released last week as a VC client plug-in. In there it is possible to attach an .iso with the timeout scripts through the plug-in on its “Tools” page.
I haven’t had a chance to test it yet but am pretty excited to give this tool a run. It is replacing the ESX HUK that was installed in the COS.
http://blogs.netapp.com/virtualstorageguy/2009/10/now-available-the-virtual-storage-console-vsphere-plug-in.html#more

By: jason

jason — Fri, 30 Oct 2009 02:51:07 +0000

Good points Justin!

By: Justin Warren

Justin Warren — Fri, 30 Oct 2009 02:46:39 +0000

You need to tune this setting when you have large numbers of volumes on NetApp clusters, too, since more volumes == longer cluster failover time.

You need to fail over the cluster to do non-disruptive upgrades to ONTAP.

Keep your maintenance needs in mind when you’re setting timeout values.