Open Stack

On Fri, Jul 03, 2015 at 03:55:37PM +0100, Anthony PERARD wrote:
> 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.

FYI, libvirt checks to see if the -w flag is available before using
it, and any use in Nova should do the same

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|