• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

How do I use das.isolationaddress[x]?

Duncan Epping · May 25, 2012 ·

Recently I received a question on twitter how the vSphere HA advanced option “das.isolationaddress” should be used. This setting is used when there is the desire or a requirement to specify an additional isolation address. The isolation address is used by a host which “believes” it is isolated. In other words, if a host isn’t receiving heartbeats anymore it pings the isolation address to validate if it still has network access or not. If it does still have network access (response from isolation address) then no action is taken, if the isolation address does not respond then the “isolation response” is triggered.

Out of the box the “default gateway” is used as an isolation address. In most cases it is recommended to specify at least one extra isolation address. This would be done as follows:

  • Right click your vSphere Cluster and select “Edit settings”
  • Go to the vSphere HA section and click “Advanced options”
  • Add “das.isolationaddress0” under the option column
  • And add the “IP Address” of the device you want to use as an isolation address under the value column

Now if you want to specify a second isolation address you should add “das.isolationaddress1”. In total 10 isolation addresses will be used (0 – 9). Keep in mind that all of these will be pinged in parallel! Many seem to be under the impression that this happens sequential, but that is not the case!

Now if for whatever reason the default gateway should not be used you could disable this by adding the “das.usedefaultisolationaddress” to “false”. A usecase for this would be when the default gateway is a “non-pingable” device, in most scenarios it is not needed though to use “das.usedefaultisolationaddress”.

I hope this helps when implementing your cluster,

Related

BC-DR, Server 4.1, 5.0, ha, high availability, vSphere

Reader Interactions

Comments

  1. BartvDB says

    25 May, 2012 at 18:28

    It is my understanding that you start at das.isolationaddress1 and not 0 whenever you add extra isolation addresses

    das.isolationaddress0 being the default GW that you modify whenever you set das.usedefaultisolationaddress to false.

    But I might be wrong though…

    B.

  2. Duncan Epping says

    25 May, 2012 at 19:36

    The start is 0 and the last is 9. The default GW is not part of that. Don’t know who informed you about this, but that is not correct.

  3. Dave says

    25 May, 2012 at 21:33

    Duncan,
    Good information to know. Which interface does the ping originate from (Service Console port or a VMkernel port)?

  4. BartvDB says

    26 May, 2012 at 09:12

    Regarding the das.isolationaddress1-10 I’ve seen this in the vCenter 5 Availability Guide at http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-availability-guide.pdf page 30

    Also KB Setting Multiple Isolation Response Addresses for VMware High Availability at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002117

    Followed by KB Advanced Configuration options for VMware High Availability at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006421

    And this KB VMware High Availability cluster reports the error: Could not reach isolation address at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1002787
    tells me that das.isolationaddress must be used with das.usedefaultisolationaddress when the GW is not pingable.

    On your own web site, you say in HA Architecture Series – Advanced Settings (5/5) at http://www.yellow-bricks.com/2011/07/28/ha-architecture-series-advanced-settings-55/ to pair das.usedefaultisolationaddress and das.isolationaddress0

    Surely you get the same result I guess, but it is confusing to say the least…

    B.

  5. Duncan says

    26 May, 2012 at 16:21

    I will get the KB articles corrected Bart to ensure the message is consistent and makes sense. Thanks for spotting that and taking the time to list them, much appreciated.

  6. Duncan Epping says

    27 May, 2012 at 21:56


    I removed several comments from this post as they were not appropriate. Any future comments that are not appropriate will also be removed without warning. I would again like to point to my disclaimer. Although I am a VMware employee all views expressed on this site are strictly mine and not the opinion / views of VMware and as such my recommendations may differ from VMware’s recommendations.

  7. Duncan Epping says

    31 May, 2012 at 14:07

    @Bart: All KB articles, documentation and the best practices guide will be corrected. I have validated it again and 0 – 9 is indeed what should be used. Also the recommendation to have at a minimum 2 isolation address (default gateway + 1 das.isolationaddress) will be properly documented.

    Thanks for pointing these out, much appreciated!

  8. Daniel Rhoden says

    2 June, 2012 at 16:38

    Duncan, as always I appreciate all of your articles.

    A couple questions. First off, how does this recommendation relate to the new HA feature in vSphere 5, storage heartbeat? Wouldn’t this new feature remove the recommendation of needing a second isolation address entirely?

    Also, in almost all VMware environments I’ve been involved with, all hosts are multi-homed, redundantly connected to a pair of stacked switches or separate blades. With this setup I have not been creating a second isolation address because if an individual switch goes out, all hosts can communicate on the other switch in the stack. If a single port goes out, that particular host would use the other stacked switch. In this case, am I properly protecting the environment by only having one isolation address due to the sheer redundancy being implemented? There’s an assumption that the gateway is located on the stacked switches or on a router with full network redundancy back to it (ie; multiple interfaces into separate blades/switches).

    I would assume that only when you have single points of failures in the networking that the secondary isolation address is significant?

  9. Duncan says

    3 June, 2012 at 21:24

    Do a search on my blog, datastore heartbeats don’t prevent isolation but help determining the state of a host instead.

  10. Daniel Rhoden says

    3 June, 2012 at 22:53

    Thanks Duncan, not sure how I missed your post on it. I guess I keep on, keeping on, with designing for host network isolation whether it’s network redundancy or isolation address redundancy (multiple isolation addresses).

    Datastore Heartbeating and preventing Isolation Events?:
    http://www.yellow-bricks.com/2011/10/03/datastore-heartbeating-and-preventing-isolation-events/

  11. Rickard Nobel says

    18 June, 2012 at 03:18

    The KB article http://kb.vmware.com/kb/1002117 says that you should increase the das.failuredetectiontime when having multiple das.isolationaddress specified (for the reason of allowing more time to ping the different addresses), but when we discussed this about a year ago the conclusion was that this was not necessary and really did not improve anything.

    http://rickardnobel.se/archives/441

    The recommendation is still in the KB, so do you know what the official status of this is?

  12. Duncan Epping says

    18 June, 2012 at 09:26

    I will get the KB article updated. That info is outdated. Info I provided is correct.

  13. Joshua says

    13 March, 2013 at 03:56

    Regarding this statement:
    Many seem to be under the impression that this happens sequential, but that is not the case!
    Personally, I was under this impression based on this guide:
    http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-501-availability-guide.pdf
    Which states:
    Specifying too many addresses makes isolation detection take too long

    The statement that additional addresses increases the detection timout implies these tests are sequential, and is probably the source of that confusion – although I have independantly confirmed your advise here is correct.

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
Aug 21st – VMware Explore
Sep 20th – VMUG DK
Nov 6th – VMware Explore
Dec 7th – Swiss German VMUG

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in