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 _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
