Currently libvirt will turn on net.ipv4.ip_forward by writing "1\n" to
/proc/sys/net/ipv4/ip_forward whenever a virtual network of with a
forward mode of "nat" or "route" is started. This is problematic for two
reasons: 1) /etc/sysctl.conf is not updated with this information, so
any other process reprocessing /etc/sysctl.conf (with "sysctl -a -p")
will potentially turn ip forward back to 0, leaving libvirt-created
virtual networks in a non-working state, and 2) it's possible the
administrator turned off ip forwarding on purpose for security reasons,
and our silently turning it on leaves them mistakenly believing it is
still off.
We've discussed a few ways of remedying this situation lately, and I
thought I should summarize all the mentioned ideas, and take a poll to
try and determine which way we should fix this.
1) Leave it as is. The simplest solution, but has the problems outlines
above.
2) Turn it on in the same place, but do it by writing
net.ipv4.ip_forward = 1
to /etc/sysctl.conf and calling "sysctl -a -p". This gives us the same
behavior as currently, but with the advantages that a) our change to the
config is documented in /etc/sysctl.conf and b) virtual networked guests
won't suddenly have their network fail when some other process runs
"sysconfig -a -p".
However, it seems rather drastic to be turning this on every time a
virtual network is started, especially without alerting the admin that
this has been done.

We have to bear in mind that this functionality has existed in
libvirt for 4 years now and as such we really don't want to cause
a regression in behaviour for people. Option 1 does have the
problem you mention, but for the vast majority of people it has
been working for years& they'll be annoyed if we break it.
To me, this ties back in with the problem of managing the firewall
in general. Toggling of ip forward should be something done by the
firewall management service....of which none exists yet. There is
current active development work to provide a dynamic firewall
management service in Fedora. This is to address the needs of libvirt,
NetworkManager, CUPs, System-D all of whom are suffering from the
current lack of firewall management. I expect the ip_forward setting
will fall under this service.
My preference would thus be to leave current libvirt behaviour
unchanged and wait to see how the firewall mgmt work plays out

If there is some other/better solution brewing, then I'm happy to wait
to see how it works out. The current situation, although it's been this
way for a long time, is just asking for trouble, however.

I'm going to look into the firewall management project and see if I can
help by trying out integrating it into libvirt.