[rhos-list] Discussion about quantum + iptables and libvirt-vif

[Perry Myers]

Bringing a useful thread from off-list to the list, in case the info is
helpful for others

>> After I updated the system to latest release today, I immediately
>> noticed a change on nova-compute side. With the new release, now if I
>> try to spawn up a VM, the libvert.xml contains a tap interface as
>> "target dev", which never happened before. I can also see this
>> interface
>> by ifconfig command in Linux.
>>
>>    <interface type="bridge">
>>      <mac address="fa:16:3e:f6:79:d7"/>
>>      <model type="virtio"/>
>>      <source bridge="qbr2ca5427d-c8"/>
>>      <target dev="tap2ca5427d-c8"/>
>>      <filterref
>> filter="nova-instance-instance-0000000f-fa163ef679d7">
>>        <parameter name="IP" value="192.168.178.3"/>
>>        <parameter name="DHCPSERVER" value="192.168.178.2"/>
>>        <parameter name="PROJNET" value="192.168.178.0"/>
>>        <parameter name="PROJMASK" value="255.255.255.0"/>
>>      </filterref>
>>    </interface>
>
> Towards the end of the folsom release we discovered a number of
> problems with the OVS VIF driver and the Nova security groups. In
> short the traffic was bypassing the security groups. The solution was
> to add in a bridge that would enforce the security groups (this is
> done by the OVSHybrid driver).
> There is a tap device from the VM which is connected to a bridge
> which is connected via a veth pair to the OVS bridge.
>
> So for example one would have:
>
> qbr3bdb52c4-e9        8000.96fcd9e833df    no        qvb3bdb52c4-e9
>                           tap3bdb52c4-e9
>
> And:
>
> [root at dhcp-4-83 ~(keystone_joe)]$ ovs-vsctl show
> 1a06b182-8419-4612-9a6e-3e4b7c75570d
>   Bridge br-int
>       Port br-int
>           Interface br-int
>               type: internal
>       Port "tap77830a12-b6"
>           tag: 1
>           Interface "tap77830a12-b6"
>               type: internal
>       Port "qvo3bdb52c4-e9"
>           tag: 1
>           Interface "qvo3bdb52c4-e9"
>
>
> This is for:
> <interface type="bridge">
> <mac address="fa:16:3e:af:d4:bf"/>
> <model type="virtio"/>
> <source bridge="qbr3bdb52c4-e9"/>
> <target dev="tap3bdb52c4-e9"/>
> <filterref filter="nova-instance-instance-00000008-fa163eafd4bf">
> <parameter name="IP" value="10.0.0.3"/>
> <parameter name="DHCPSERVER" value="10.0.0.2"/>
> <parameter name="PROJNET" value="10.0.0.0"/>
> <parameter name="PROJMASK" value="255.255.255.0"/>
> </filterref>
> </interface>
>
>> I am wondering what's the main reason to add this tap interface?
>> Further
>> more, what's the implication on the traffic flow in and out of
>> VM? For
>> example, does iptable rule work on this tap interface? If so, which
>> chain, INPUT/FORWARD/OUTPUT? I realized that now DHCP, which used to
>> work last night, stopped working. DHCP request from VM is not handed
>> over from linux bridge to OVS bridge. No iptable rules is
>> helpful…..:(
>> Do you think it is correlated to this change?
>
> To be honest I think this is one of the problems that we have with
> the iptables rules at the moment. This is still under investigation.
> The mail I sent you yesterday may have been incorrect when it comes
> to the ip tables.
>
> With the linux bridge it was working with me and I have problems with
> the OVS with todays installation.
> One thing for sure is that there is a performance penalty for the
> additional bridges.
>
> Hope that the explanation helps.