[Openais] Two questions; Intro to AIS? and TOTEM errors in fence loop

Madison Kelly linux at alteeve.com
Tue Nov 3 12:42:28 PST 2009


Darren Thompson wrote:
> Madi
> 
> In essence, yes it's the same thing. Only the VMs would have an active
> IP address, although I have never thought to use a VM as a firewall
> server (I see that it's routing the 'Internet facing' and 'internal'
> networks). 
> 
> In my case I treat the Internet facing bridge as a DMZ so the only
> access to the VMs is through a hardware firewall/router. Probably
> because I have one to use; (sodding expensive things normally).
> 
> Since you are saying that the device is 'peth2' and the bridge is
> 'xenbr2' I see that you have chosen to persist with that dodgy
> "network-bridge fudge script", but that's fine if you are happy with how
> it's all working.
> 
> I'm glad to hear that it's all working for you.
> 
> Daz

Hi Daz,

   I'm a bit of a stickler for trying to stick with "the default way". 
Mainly because I trust the package managers have thought things through 
more than I have. :)

   I am also in a fortunate position of working for an ISP so we have no 
shortage of network hardware. I am also treating xenbr2 as a polluted 
DMZ, and thus, only the firewall's eth1 has an IP address. All other VMs 
on either node must route through the firewall's eth0 via xenbr0.

   The main reason I wanted to virtualize the firewall was so that, if 
it's host hardware failed, I could bring it right back up on the other 
node and continue providing firewalling and routing to all VMs. This 
works because both xenbr0 and xenbr2 on either node are connected 
through dedicated switches allowing the firewall to be on either node 
and still support VMs on the same node and the other.

   I've put in a comment regarding this issue with an existing similar 
ticket on Red Hat's bug list. I am tempted to fire a message to Xen as 
well. I can't really see a good reason why a service that totally 
changes networking should be one of the last things started. Really, it 
should be started immediately after the underlying network itself comes 
up. If for some reason Xen proper has to wait, then they should split 
out the networking modifications and have them, at the very least, 
directly follow the network start. When this is the case, all of the 
clustering problems go away and everything is fine.

Madi


More information about the Openais mailing list