On 10/01/2010 04:40 PM, Eric Blake wrote:
On 10/01/2010 12:46 PM, Laine Stump wrote:
3) Whenever a virtual network that would require ip_forward = 1 to
operate properly is started (ie at libvirtd start time, and when a
network is newly defined), check if it's currently on, and if not log a
warning message, informing the admin that they should turn on ip_forward
in sysctl.conf and reload it in order to have properly working
networking.
This would assure that the admin was informed of the necessity for
ip_forward, but eliminate the possibility of two processes fighting over
the setting of ip_forward, leaving it up to the admin to make the
decision and do the right thing. On the other hand, it would prevent
libvirt's networking from "just working" on a new install.
Option 3 is consistent with what we just checked in for nwfilter vs.
/proc/sys/net/bridge/bridge-nf-call-ip[6]tables in commit 570d040435.
On the surface, I'm liking that option best - tell the user that we
can't do what they asked because it requires them to make a conscious
admin decision; even though it unfortunately doesn't play nicely with
out-of-the-box installation (and that matters more for user attitudes
than anything else, in my experience).
The problem may be that not everyone knows how to enable forwarding,
filtering, or reads log files. People are used to that networking (or
filtering) works out-of-the box but then on one installation for some
reason it doesn't. After some time typically one finds the answer online
somewhere what needs to be configured... I guess documentation is 'key'.
Maybe libvirt could have an admin mode 'somehow' that prevents it from
automatically making those changes whereas the less-savvy audience gets
it set up all automatically.
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
