<br><div class="gmail_extra"><br>Hi</div><div class="gmail_extra"><br></div><div class="gmail_extra">The 3.8 version of the Openvswitch drivers use openflows as there are some incompatibility issues when using iptables and ovswitch. Note that there are some filtering limitations (compared to the iptables) regarding the definition of TCP/UDP port ranges.</div>
<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Mon Nov 12 15:17:44 2012 [VMM][D]: Message received: LOG E 216 post:<br>
Command "sudo /usr/bin/ovs-ofctl add-flow vlan5<br>
in_port=,dl_src=02:00:0a:80:05:32,priority=40000,actions=normal" failed.<br>
</blockquote><div><br></div><div>This may be some kind of incompatibility of the ovswitch version of your installation and the drivers. The problem here is the empty in_port. Can you deploy the VM by hand and send the output of (executed as oneadmin):</div>
<div><br></div><div>sudo /usr/bin/ovs-ofctl dump-ports vlan5 <VM_tap_interface></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The vlan5 port on this particular switch is a `fake bridge`. Linux<br>
bridge compatibility layer is enabled as requested by the docs [1].<br>
<br>
```<br>
$ ps aux | grep openvswitch </blockquote><div><br></div><div>All seems ok here</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The OpenFlow default rules employed by OpenNebula state on the doc<br>
[2] page the following:<br>
<br>
`These rules prevent any traffic to come out of the port the MAC<br>
address has changed.`<br>
<br>
Does this mean that traffic coming out of the port OpenNebula just<br>
created on the switch is denied/dropped? Or does it mean that traffic<br>
with the source MAC address of the VM should only come in on the<br>
specified port, the newly added port for the VM?<br></blockquote><div><br></div><div>The later, any traffic with source MAC address different from one assigned to the VM is filtered out. To prevent a user to change the VM MAC from the guest...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Maybe I'm wrong, but at a glance flows can improve security and thus are<br>
a huge improvement to OpenNebula. Do you, devs and users, think that it<br>
would be better to separate the flow definition from code? For now if we<br>
want to add flow rules we have to modify<br>
`/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb`. I think it would be<br>
wise to have separate files with rules based on the users' need. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
`ovs-ofctl` can add flows directly from a file so it wouldn't be very<br>
hard, I guess, to separate the flows from the code. Of course one can do<br>
this by himself by modifying `post`.<br></blockquote><div><br></div><div>Yes, this may be a good idea. Use a filter file with some template engine (ERB, haml...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One more thing, why does OpenNebula need the Linux bridge compatibility<br>
layer enabled?<br></blockquote><div><br></div><div>This is basically a requirement from the hypervisor that uses brctl addif... KVM (through libvirt) supports Openvswitch without compatibility layer since version 0.9.11. We opted to preserve this requirement and remove it in future versions (and add <virtualport> for NICs). Note that the driver itself does not require the compatibility layer, as it uses openvswitch commands.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Can anybody shed some light?<br>
<br>
[1]: <a href="http://opennebula.org/documentation:rel3.8:openvswitch#hosts_configuration" target="_blank">http://opennebula.org/documentation:rel3.8:openvswitch#hosts_configuration</a><br>
[2]: <a href="http://opennebula.org/documentation:rel3.8:openvswitch#openflow_rules" target="_blank">http://opennebula.org/documentation:rel3.8:openvswitch#openflow_rules</a><br>
<br>
Thanks. Cheers and Goodwill,<br>
v<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org<br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>
OpenNebula - The Open Source Solution for Data Center Virtualization<br></a><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula<br>
<br>
<br>
</blockquote></div></div>