Comments on: das.allowNetwork where and when http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/ Building blocks for virtualization... Fri, 19 Mar 2010 12:16:43 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: TimC http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-5055 TimC Fri, 13 Nov 2009 20:30:19 +0000 http://www.yellow-bricks.com/?p=302#comment-5055 So... I've run into an interesting "problem". All of my SC's are on the same subnet. 0 issues with esx 3.5. When I upgraded to vsphere4, it gives the error. Thing is, we're using a class B instead of a class C. It looks to me like the code checking automatically assumes a class C and bombs out. Maybe it's something else, but to me it looks like it's an HA config issue. So… I’ve run into an interesting “problem”. All of my SC’s are on the same subnet. 0 issues with esx 3.5. When I upgraded to vsphere4, it gives the error. Thing is, we’re using a class B instead of a class C. It looks to me like the code checking automatically assumes a class C and bombs out. Maybe it’s something else, but to me it looks like it’s an HA config issue.

]]> By: Kris Nijs @ Business IT Solutions » HA - DRS Advanced Options http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-3928 Kris Nijs @ Business IT Solutions » HA - DRS Advanced Options Wed, 01 Jul 2009 12:28:49 +0000 http://www.yellow-bricks.com/?p=302#comment-3928 [...] - Disable the “compatible network” check for HA that was introduced with Update 2. Default value is “false”, setting it to “true” disables the [...] [...] – Disable the “compatible network” check for HA that was introduced with Update 2. Default value is “false”, setting it to “true” disables the [...]

]]> By: Duncan Epping http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-839 Duncan Epping Mon, 11 Aug 2008 12:27:09 +0000 http://www.yellow-bricks.com/?p=302#comment-839 Seva, 1) I agree, that's what I stated... It's new. 2) We're saying the same but in a different way 3) I don't agree on this one. According to Marc's posts on the VMTN forum it isn't possible. 4) I know you have to specify number, but I didn't elaborate on it because that's not what the article is about, but I will clarify it. 5) I don't think DNS is obsolete. Maybe for HA it is. But when I use stuff like scripting you'll need DNS to resolve the other hosts etc. Seva,

1) I agree, that’s what I stated… It’s new.
2) We’re saying the same but in a different way
3) I don’t agree on this one. According to Marc’s posts on the VMTN forum it isn’t possible.
4) I know you have to specify number, but I didn’t elaborate on it because that’s not what the article is about, but I will clarify it.
5) I don’t think DNS is obsolete. Maybe for HA it is. But when I use stuff like scripting you’ll need DNS to resolve the other hosts etc.

]]> By: Seva http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-838 Seva Mon, 11 Aug 2008 11:16:18 +0000 http://www.yellow-bricks.com/?p=302#comment-838 I'm not very happy with this explanation. In my understanding of the matter: 1. Network compatibility check is a genuine part of HA cluster design. It wasn't working in the previous versions, just because it wasn't implemented. 2. During the formation of the HA cluster all service console network interfaces (all management network interfaces on ESXi) are being sorted into networks. HA treats each service console interface (each management interface on ESXi which is not used by VMotion, unless we have das.allowVmotionNetworks defined ) as cluster network interface (here the dependence on the das.isolationaddress must be checked). When HA discovers a network interffaqce which does not belong to any known cluster network id adds the new network. HA expects that all cluster members will have the same networks. Thus if a new host has an interface which does not belong top any existing xluster networks HA throws message about incompatible networks 3. Option das.allowNetwork allow to pick for cluster communcication only those networks, whose port group name matches the value of this parameter. It is not an intended use of das.allowNetwork but with this parameter we chan "mask out" service console interfaces which should not be used for cluster communications. Each parameter denotes one network. Thus das.allowNetwork allows to put in the same network interfaces on different subnets. 4. Do not use das.allowNetwork (without number) with das.allowNetwork2 (with number) this may prevent the cluster formation. I need to verify some staments and then I can prepare document with some use cases. 5. DNS configuration (as well as /etc/hosts file) for an ESX host in HA cluster are obsolete. Each node gets the name resolution for others cluster members and keeps it locally. You may need DNS / /etc/hosts for time seerver configuration. I will double check everything there and republish results Best regards I’m not very happy with this explanation.
In my understanding of the matter:
1. Network compatibility check is a genuine part of HA cluster design. It wasn’t working in the previous versions, just because it wasn’t implemented.
2. During the formation of the HA cluster all service console network interfaces (all management network interfaces on ESXi) are being sorted into networks. HA treats each service console interface (each management interface on ESXi which is not used by VMotion, unless we have das.allowVmotionNetworks defined ) as cluster network interface (here the dependence on the das.isolationaddress must be checked). When HA discovers a network interffaqce which does not belong to any known cluster network id adds the new network. HA expects that all cluster members will have the same networks. Thus if a new host has an interface which does not belong top any existing xluster networks HA throws message about incompatible networks
3. Option das.allowNetwork allow to pick for cluster communcication only those networks, whose port group name matches the value of this parameter. It is not an intended use of das.allowNetwork but with this parameter we chan “mask out” service console interfaces which should not be used for cluster communications. Each parameter denotes one network. Thus das.allowNetwork allows to put in the same network interfaces on different subnets.
4. Do not use das.allowNetwork (without number) with das.allowNetwork2 (with number) this may prevent the cluster formation.
I need to verify some staments and then I can prepare document with some use cases.
5. DNS configuration (as well as /etc/hosts file) for an ESX host in HA cluster are obsolete. Each node gets the name resolution for others cluster members and keeps it locally. You may need DNS / /etc/hosts for time seerver configuration.

I will double check everything there and republish results
Best regards

]]> By: Duncan http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-830 Duncan Fri, 08 Aug 2008 22:29:50 +0000 http://www.yellow-bricks.com/?p=302#comment-830 Yes it will, as far as I know. Yes it will, as far as I know.

]]> By: Jaime http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-828 Jaime Fri, 08 Aug 2008 20:43:21 +0000 http://www.yellow-bricks.com/?p=302#comment-828 Would HA still use only the primary SC default gateway for the isolation address unless others are specified using das.isolationaddress? Would HA still use only the primary SC default gateway for the isolation address unless others are specified using das.isolationaddress?

]]> By: Duncan Epping http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-825 Duncan Epping Fri, 08 Aug 2008 19:34:12 +0000 http://www.yellow-bricks.com/?p=302#comment-825 Benjamin: Indeed, that would be the easiest! I would empty out the host files, as in get all the entries for the other hosts out of there. as of 2.5 U2 HA will get this info from the VC anyway. Jaime: If you have several Service Consoles all will be used for HA. You will only need to specify these 2 SC's if you've got a third for instance and want to rule that one out. Benjamin: Indeed, that would be the easiest! I would empty out the host files, as in get all the entries for the other hosts out of there. as of 2.5 U2 HA will get this info from the VC anyway.

Jaime: If you have several Service Consoles all will be used for HA. You will only need to specify these 2 SC’s if you’ve got a third for instance and want to rule that one out.

]]> By: Jaime http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-821 Jaime Fri, 08 Aug 2008 18:44:21 +0000 http://www.yellow-bricks.com/?p=302#comment-821 Does adding das.allowNetwork1 "Service Console" das.allowNetwork2 "Service Console 2" Have the same effect of having Service Console redundancy and telling it to use multiple addresses to check for isolation? Does adding

das.allowNetwork1 “Service Console”
das.allowNetwork2 “Service Console 2″

Have the same effect of having Service Console redundancy and telling it to use multiple addresses to check for isolation?

]]> By: benjamin http://www.yellow-bricks.com/2008/08/08/dasallownetwork-where-and-when/comment-page-1/#comment-820 benjamin Fri, 08 Aug 2008 14:55:17 +0000 http://www.yellow-bricks.com/?p=302#comment-820 I was asked: If a host has one service console network with default label Service Console, is it ok to change to something_else? As far as I know, why not! Go change it. It's just a label! But given a scenario like below, it might be simple to do as below 5 Hosts - one SC network, same subnet 6th Hosts - one SC network, different subnet 7th Hosts - one SC network, different subnet Instead of adding "Service Console 2" on 6th and 7th host, changing "Service Console" to "Service Console 2" on 5 hosts, I suggest to 1) Keep "Service Console" as it is on 5 hosts 2) Add new SC portgroup on 6th and 7th and change the label "Service Console 2" 3) Move "Service Console" in 6th and 7th to same subnet as 1 - 5. That is, if 6th and 7th still need to stay in their original subnet. Note: Updating /etc/hosts file and /etc/resolv.conf might be necessary for 6th and 7th hosts. I was asked:

If a host has one service console network with default label Service Console, is it ok to change to something_else? As far as I know, why not! Go change it. It’s just a label!

But given a scenario like below, it might be simple to do as below

5 Hosts – one SC network, same subnet
6th Hosts – one SC network, different subnet
7th Hosts – one SC network, different subnet

Instead of adding “Service Console 2″ on 6th and 7th host, changing
“Service Console” to “Service Console 2″ on 5 hosts, I suggest to

1) Keep “Service Console” as it is on 5 hosts
2) Add new SC portgroup on 6th and 7th and change the label “Service Console 2″
3) Move “Service Console” in 6th and 7th to same subnet as 1 – 5.

That is, if 6th and 7th still need to stay in their original subnet.
Note: Updating /etc/hosts file and /etc/resolv.conf might be necessary for 6th and 7th hosts.

]]>