Open Stack

On Wed, Jul 01, 2015 at 02:45:13PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 30, 2015 at 03:02:54PM +0100, Anthony PERARD wrote:
> > Hi all,
> > 
> > We have an issue with the driver libvirt-xen. When a guest is started by
> > Nova, nova-network is going to do some network setup and call
> > iptables-{save,restore}, and the Xen toolstack is going to setup the
> > vif of the guest, via a script, which also update the iptables.
> > 
> > The Xen script is simply calling those commands:
> >   ip link set dev ${dev} down
> >   ip link set dev ${dev} address fe:ff:ff:ff:ff:ff
> >   ip address flush dev ${dev}
> >   brctl addif ${bridge} ${dev}
> >   ip link set dev ${dev} up
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev" -j ACCEPT
> >   iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out "$dev" -j ACCEPT
> > 
> > $dev been by default vif$domid.$devid.
> > 
> > Only the call to iptables is an issue and fail fairly often when it looses
> > the race against iptables-{save,restore}.
> > 
> > It is possible to have Nova asking to run a different script that would not
> > call iptables. But that script would need to be store somewhere, in the
> > nova repo would be best.
> > 
> > Any though on that?
> > 
> > Is `iptables` call necessary for the vif with OpenStack?
> > If so, can nova-network do the update? Or the script called by the Xen
> > toolstack could take an OpenStack lock before calling iptables?
> > 
> > Bug report: https://bugs.launchpad.net/nova/+bug/1461642
> 
> IIRC, the iptables physdev matches are to deal with the fact that the
> kernel default sends all bridge traffic via the net filter layer. This
> is arguably a layering violation, because if you're bridging guests at
> the network layer, you generally don't expect traffic to be filtered
> at the IP layer. Some distros override this kernel default by setting
> some sysctls:
> 
>  net.bridge.bridge-nf-call-ip6tables = 0
>  net.bridge.bridge-nf-call-iptables = 0
>  net.bridge.bridge-nf-call-arptables = 0
> 
> At which point I think the iptables rules you quote should be
> redundant.

Thanks for the explanation.

> In terms of locking, libvirt uses the '-w' flag when calling iptables
> which prevents concurrent execution of iptables. I'm not sure whether
> adding -w would be sufficient to deal with your particular case.
> Regardless, any time nova invokes iptables, it should use -w

The --wait flag would not work because the call might append between an
OpenStack iptable-{save,restore} calls.
Also, the flag can not be accepted upstream as it is too recent, some
distribution that we care about does not have it.

Thanks,

-- 
Anthony PERARD