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

Steven Dake sdake at redhat.com
Tue Nov 3 13:23:02 PST 2009


On Tue, 2009-11-03 at 15:42 -0500, Madison Kelly wrote:
> 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.
> 

Your right - xen shouldn't be mucking with all these network config
options in the s99 run position.

Unfortunately this problem was detected after most distros released the
cluster stack + xen software.  A majority of distros policy is that
start and stop positions for init scripts may not change during the
major version of the product life.  (IE no init script changes to RHEL5
for example).

This is why other hacky workarounds were created which work to varying
degrees.

Hope that helps
-steve

> Madi



More information about the Openais mailing list