Fwd: Re: the case for volatile nwfilters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




For some reason this message could not be sent to the list.

On 10/30/2013 05:57 AM, Laine Stump wrote:
On 10/29/2013 06:33 PM, Dan Kenigsberg wrote:
I'd like oVirt to make a more extensive usage of libvirt's nwfilters in
order to implement security groups, i.e. which protocol/port/host should
be open on an interface.

Since oVirt is cetrally-managed by ovirt-engine, filter definitions
should be edited there and kept in its database. However, libivrt's
domain xml requires to have a locally-defined filter as well:

   <devices>
     <interface type='bridge'>
       <filterref filter='filter-name'/>
     </interface>
   </devices>

We can leave with it by defining an ad-hoc filter before staring a VM,
deleting it after the VM stops, and collecting garbage (due to system
crashes) occasionally.

It would be nicer if we could instead have just-in-time filter
definition such as

   <devices>
     <interface type='bridge'>
       <filter name='nameless'>
          <rule/>
          <rule/>
          <rule/>
       </filter>
     </interface>
   </devices>

avoiding nwfilter persistence. Would something like this be beneficial
to other libvirt users? Would it be easy to implement within libvirt?
My first thought when I saw the subject line was of adding a transient
"define and start" API similar to that used for domains and networks,
but of course nwfilters have no concept of "start" or "destroy", so they
wouldn't be able to follow the same semantics as transient domains and
networks anyway.

Most likely Stefan made nwfilters use in domains all be references to
the actual nwfilters rather than having them contained in order to 1)
save duplication in the configuration now, and 2) potentially save
duplication in the kernel iptables rules in the future. I can see the
convenience, but wonder how much inefficiency it could lead to.

Structurally it makes sense though, and the xml has conveniently named
the existing element as <filterref> so that <filter> is still available
- was there some premonition of this being requested in the future? :-)

I recall that Stefan has been extremely busy elsewhere and unable to
completely follow libvir-list for awhile, so I'm Cc'ing him - Stefan, do
you have any opinion/wisdom on this?


Why can the client not call nwfilter-define to define a filter and have
the filter referenced from the domain XML?
Also many of the items in the domain XML only become active after a
reboot of the VM (afaik) and I didn't want to change that with nwfilter.
So you can at any time replace the referenced nwfilter and it will be
instantiated when/while the VM is running or rejected if it cannot be
instantiated.

   Stefan



--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]