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).
4) Turn ip_forward on during libvirt install. This one doesn't make sense to me, because you don't know at the time of libvirt install whether or not the installation if going to end up with any virtual networks that need forwarding.
Now, thinking a bit outside the box: is it possible to create a libvirt-network package, whose sole purpose is to turn on the ip_forward setting at install time? That is, the main libvirt package doesn't touch the setting, but an optional add-on package does; that way, users can choose whether to install one or both packages, depending on their intended usage patterns. In other words, I think point 4 via split packaging solves this nicely.
I think the important things to accomplish are:
1) Avoid having networking magically stop working when someone else reloads sysctl.conf
Agreed. Point 3 meets this, but by putting the burden on the sysadmin. Point 4 also meets it by actually changing the persistent config, if the optional package is installed.
2) Make sure that the admin realizes that ip_forward is being turned on (or needs to be turned on).
Point 3 meets this via error message; point 4 meets this by explicitly requesting the extra package.
3) If we're going to turn it on, at least don't do it if it's not needed.
Point 3 meets this by leaving it up to the sysadmin; point 4 meets this by leaving the optional package out.
4) Something else we need to consider is the ability to provision a host for proper guest networking purely through the libvirt API, and if we were to stop turning on ip_forward automatically when a network was started, that wouldn't work anymore (unless ip_forward happened to be turned on already).
Not sure how best to address this through just libvirt API. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list