Hello Jhon,<div><br></div><div>First of all congratulations for doing this, it's an absolutely amazing contribution.  :-) It rocks!</div><div><br></div><div>We're in the process of defining the roadmap for OpenNebula 3.6 and we had already thought of improving the network management, especifically the management of a NIC's firewall while a VM is running (which I think it's a rather nifty feature). I think this could fit in nicely with what you've done.</div>

<div><br></div><div>Upon a first look on the rationale you have described in your email: creating a specific resource in OpenNebula's core to handle network filters, creating a CLI command, xml-rpc interfaces, sunstone tab, etc it certainly makes a lot of sense to us to do it that way.</div>

<div><br></div><div>There is something that concerns us, though: if we implement this feature only through libvirt, probably VMware won't have support and Xen will certainly don't. But I think we can call a different action depending on each hypervisor, maybe create a new VMM action to setup network filters. So in the end, for KVM it will be done exactly how you've done, but we would need to implement those actions for the rest of hypervisors. We have to look into this, but I think it's feasible.</div>

<div><br></div><div>Anyways we're really interested in this feature!</div><div><br></div><div>Thanks again for your serious hacking and for sharing!</div><div><br></div><div>Cheers,<br>Jaime</div><div><br></div><div>
 </div>
<div><div class="gmail_quote">On Wed, Apr 11, 2012 at 11:24 AM, Jhon Masschelein <span dir="ltr"><<a href="mailto:Jhon.Masschelein@sara.nl">Jhon.Masschelein@sara.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Dear Openenbula users,<br>
<br>
On our openenbula cloud, we implemented a libvirt netfilter based firewall. First on top of ONE 3.0 and then ported to ONE 3.2.<br>
<br>
The black&white ports approach that is already  present in ONE does not seem to answer to our needs because one cannot specify ip ranges that should be allowed access to certain ports. (Please correct me if I am wrong).<br>


<br>
Also, because the iptables are apparently set by oneadmin, we fear that we might get into unpredictable situations when we have to manually restart VMs due to, for example, a node crash.<br>
<br>
<br>
Our implementation is based completely on the libvirt netfilters. (<a href="http://libvirt.org/formatnwfilter.html" target="_blank">http://libvirt.org/<u></u>formatnwfilter.html</a>)<br>
We added a new object called "networkfilter" to the ONE core and implemented the standards onenetworkfiler cli command that does pretty much what you would expect it to do. (It works with the acl/permission system.)<br>


<br>
A onenetworkfilter is actually just a bunch of parameters that are fed to the NIC specification in the deployment template. By adding a "LIBVIRT_NETWORKFILTER" custom attribute to a vnet, the end result is a network interface that references a libvirt network filter that is populated with the parameters that are included.<br>


<br>
We are able to force the use of networkfilters on certain networks (the ones that give access to the Internet).<br>
<br>
Filters can be created using the cli command or xml-rpc and we added a sunstone plugin to allow people to add ip/port rules using a simple gui. (The filter object can work with other variables types like mac adresses, but the sunstone template is limited to ip+port rules.)<br>


<br>
A screenshot of the sunstone tab can be found at <a href="http://tinyurl.com/cpdb5cc" target="_blank">http://tinyurl.com/cpdb5cc</a> . (And of course the "create template" form was made networkfiler-aware.)<br>


<br>
Since these filters are pure libvirt filters and are therefore set and maintained by libvirt, there is full support for migration, suspending and whatever else libvirt can do with a VM.<br>
<br>
<br>
We would like to know whether there is interest in this feature and whether this is something that could be added to the ONE distribution.<br>
<br>
We are porting the code to every new ONE release anyway and would have no problem contributing (and maintaining) the code.<br>
<br>
With kind regards,<br>
<br>
Jhon<br>
<br>
-- <br>
Jhon Masschelein<br>
Senior Systeemprogrammeur<br>
SARA - HPCV<br>
<br>
Science Park 140<br>
1098 XG Amsterdam<br>
T <a href="tel:%2B31%20%280%2920%20592%208099" value="+31205928099" target="_blank">+31 (0)20 592 8099</a><br>
F <a href="tel:%2B31%20%280%2920%20668%203167" value="+31206683167" target="_blank">+31 (0)20 668 3167</a><br>
M <a href="tel:%2B31%20%280%296%204748%209328" value="+31647489328" target="_blank">+31 (0)6 4748 9328</a><br>
E <a href="mailto:jhon.masschelein@sara.nl" target="_blank">jhon.masschelein@sara.nl</a><br>
<a href="http://www.sara.nl" target="_blank">http://www.sara.nl</a><br>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/users-opennebula.<u></u>org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Jaime Melis<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Cloud Computing<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:jmelis@opennebula.org" target="_blank">jmelis@opennebula.org</a><br>


</div>