[libvirt] RFC: automatic setting of ip_forwarding (or not)
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. 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. 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. 5) Make ip_forward a tunable in /etc/libvirt/libvirtd.conf, and set it accordingly every time libvirtd is started. I don't know if this makes sense either - if you have NATed or routed virtual networks, you will need ip_forward=1 for them to work properly, and if you don't have them, you don't care, so it's really redundant. **** I think the important things to accomplish are: 1) Avoid having networking magically stop working when someone else reloads sysctl.conf 2) Make sure that the admin realizes that ip_forward is being turned on (or needs to be turned on). 3) If we're going to turn it on, at least don't do it if it's not needed. 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). So, what are your opinions? (BTW, the firewall rules added for virtual networks suffer from a similar problem - because they're loaded into the kernel directly with the iptables command, there is no external record of them, and some other process reloading the firewall will flush out all libvirt's rules, leaving the guests with nonworking networking. But that discussion is a bigger one, that probably needs to go outside just libvirt, so I'll avoid that here...)
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
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
Uh huh, hi? On 10/01/2010 08:46 PM, Laine Stump wrote: [...]
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".
You've got me a bit confused here, because what exactly is supposed # sysctl -a -p; do? I mean, what kind of magic? I've tried this and if I turn on net.ipv4.ip_forward to '1' and run # sysctl -a -p; it stays on, unless defined as 0 in /etc/sysctl.conf (and sysctl run only with -p, not -a AND -p). And if it's defined as 0 there, then there must be reason for being so. Also, why on Earth would you have every sysctl parameter in /etc/sysctl.conf unless you're not happy with default ones? Imho this file is for fine tuning, thus ~ include things what I don't like or want changed, but not every possible kernel option which I might or might not want to change. Because then there is no surprise for such odd behavior. Also, the outlined problem here sounds more like "left hand doesn't know what's doing right hand" or I just didn't get your point. I'm also missing the previous discussion about the problem, if there was any. I mean, your e-mail comes out of the blue sky without any previous reference. I hope this doesn't sound too much jerk-ish, but I kinda don't like too much what I'm reading here. Have a nice weekend and thank you for your (or anyone's) reply on this one. Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 10/01/2010 04:44 PM, Zdenek Styblik wrote:
Uh huh, hi?
On 10/01/2010 08:46 PM, Laine Stump wrote: [...]
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".
You've got me a bit confused here, because what exactly is supposed # sysctl -a -p; do? I mean, what kind of magic?
Sorry about that - remove the "-a" from that command. No magic. As the manpage says, "sysctl -p" reads the provided file (or /etc/sysctl.conf if no file is provided) and sets all the kernel parameters listed there to the values given. As you know, /etc/sysctl.conf is used, at least on RHEL and Fedora, to "permanently" set kernel parameter values to something other than the defaults hardcoded into the kernel and loadable kernel modules. (actually they can be modified to something else either by individually setting them with sysctl -w or by writing directly to the /proc entry, but this will be overridden the next time "sysctl -p" is run). On both RHEL and Fedora, both the network and NetworkManager services (and others, eg see the bug reports a bit further down in this reply) run sysctl with -p to reload all non-kernel-default settings when they are started, and Fedora puts "net.ipv4.ip_forward=0" into /etc/sysctl.conf at install time. So at boot time, both of those services run "sysctl -p" which sets ip_forward to 0, then libvirtd starts, which sets it to 1. At this point, libvirt virtual networks are running (as expected), but also there may be some other unwanted routing going on (which the admin won't expect). If the network or NetworkManager service is later manually restarted (or some other parameter is added to sysctl.conf and it's reloaded with "sysctl -p" as many HOWTO documents suggest when changing a kernel parameter), libvirt's virtual networks suddenly/unexpectedly stop working.
I've tried this and if I turn on net.ipv4.ip_forward to '1' and run # sysctl -a -p; it stays on, unless defined as 0 in /etc/sysctl.conf (and sysctl run only with -p, not -a AND -p).
Right, my mistake.
And if it's defined as 0 there, then there must be reason for being so.
Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call.
Also, why on Earth would you have every sysctl parameter in /etc/sysctl.conf unless you're not happy with default ones?
Nobody is talking about putting any value there other than net.ipv4.ip_forward (which, on RHEL and Fedora is already put there by the installer), and that only to assure that it's set to the value that libvirtd needs for its virtual networks to work properly. (Possibly my erroneous addition of "-a" threw you off there).
Imho this file is for fine tuning, thus ~ include things what I don't like or want changed, but not every possible kernel option which I might or might not want to change. Because then there is no surprise for such odd behavior.
Also, the outlined problem here sounds more like "left hand doesn't know what's doing right hand" or I just didn't get your point.
Again you are correct. currently libvirt is turning it on without documenting that fact in the (as far as I know) standard accepted place of doing so - /etc/sysctl.conf.
I'm also missing the previous discussion about the problem, if there was any. I mean, your e-mail comes out of the blue sky without any previous reference.
Two Active bug reports that I'm aware of offhand (one for RHEL and one for Fedora): https://bugzilla.redhat.com/show_bug.cgi?id=612865 https://bugzilla.redhat.com/show_bug.cgi?id=612867 There are also related bugs for older Fedora releases: https://bugzilla.redhat.com/show_bug.cgi?id=240922 https://bugzilla.redhat.com/show_bug.cgi?id=426792 https://bugzilla.redhat.com/show_bug.cgi?id=467687 https://bugzilla.redhat.com/show_bug.cgi?id=514228 The first two prompted a short discussion on an internal Red Hat call, first a brief mention of it a month or two ago, and again in a similar call last week, where the main point of the conversation was "1) this is a problem, 2) we should fix it, 3) here's a list of some ideas, 4) we need to post these ideas on libvir-list to start a conversation in the libvirt community about the best course of action." I'm not sure how else we could have proceeded that would have made it less of a surprise to you. (Of course now that I've hopefully better articulated myself, you may be less surprised :-)
I hope this doesn't sound too much jerk-ish, but I kinda don't like too much what I'm reading here.
You may be reading more into this than is there - the discussion is newly started, no code has even been written yet (much less patches posted, or pushed), and none of the proposed changes are as sweeping as you may think. It sounds like we agree on at least a couple of important points: 1) "the left hand should know what the right hand is doing" and 2) if ip_forward is set to 0, that was likely done for a reason, so we shouldn't silently modify it. it. Beyond that, is a point that is really just a fact, not an opinion: 3) libvirt's virtual networks won't work unless ip_forward is turned on. The current code is only compatible with 1 of those 3; we need to agree on a method to satisfy all of them. Are you voting for my proposal (1) in the original mail? (do nothing), or do you have another idea?
On 10/04/2010 08:13 PM, Laine Stump wrote:
On 10/01/2010 04:44 PM, Zdenek Styblik wrote: [...sysclt stuff...]
On both RHEL and Fedora, both the network and NetworkManager services (and others, eg see the bug reports a bit further down in this reply)
Hm, how to put it. I, for myself, don't like idea of fixing something just because of other buggy applications. But this expression might be wrong - it is probably wrong expression indeed.
run sysctl with -p to reload all non-kernel-default settings when they are started, and Fedora puts "net.ipv4.ip_forward=0" into /etc/sysctl.conf at install time. So at boot time, both of those
Yes, well you can change that, although this would turn on IP forward by default.
[...]
Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call.
Only thing that popped in my head was: admin should read documentation :(
[...more of sysctl.conf...]
[...] Two Active bug reports that I'm aware of offhand (one for RHEL and one for Fedora):
[...]
The first two prompted a short discussion on an internal Red Hat call, first a brief mention of it a month or two ago, and again in a similar call last week, where the main point of the conversation was "1) this is a problem, 2) we should fix it, 3) here's a list of some ideas, 4) we need to post these ideas on libvir-list to start a conversation in the libvirt community about the best course of action."
I'm not sure how else we could have proceeded that would have made it less of a surprise to you. (Of course now that I've hopefully better articulated myself, you may be less surprised :-)
Reference to these(or anything else) would help. ;)
You may be reading more into this than is there - the discussion is newly started, no code has even been written yet (much less patches posted, or pushed), and none of the proposed changes are as sweeping as you may think.
Well, I haven't thought about such possibility in the first place.
It sounds like we agree on at least a couple of important points: 1) "the left hand should know what the right hand is doing" and 2) if ip_forward is set to 0, that was likely done for a reason, so we shouldn't silently modify it. it. Beyond that, is a point that is really just a fact, not an opinion: 3) libvirt's virtual networks won't work unless ip_forward is turned on. The current code is only compatible with 1 of those 3; we need to agree on a method to satisfy all of them. Are you voting for my proposal (1) in the original mail? (do nothing), or do you have another idea?
To get back to original points/summary:
I think the important things to accomplish are:
1) Avoid having networking magically stop working when someone else reloads sysctl.conf
I think this can't be guaranteed unless periodical polling. I mean, it doesn't(well "doesn't") matter if you modify /etc/sysctl.conf or 'echo 1' into /proc/...; it still can be turned off. More, the point is network can magically stop working whenever I or anybody please. This is not only about /etc/sysctl.conf, I'm afraid. Right, the question is what's better (the best) approach here. echo 1 into /proc/... only when it's needed and note in documentation about this?
2) Make sure that the admin realizes that ip_forward is being turned on (or needs to be turned on).
Documentation?
3) If we're going to turn it on, at least don't do it if it's not needed.
I agree.
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).
I don't fully understand it, thus - I don't know :)
(BTW, the firewall rules added for virtual networks suffer from a similar problem - because they're loaded into the kernel directly with the iptables command, there is no external record of them, and some other process reloading the firewall will flush out all libvirt's rules, leaving the guests with nonworking networking. But that discussion is a bigger one, that probably needs to go outside just libvirt, so I'll avoid that here...)
Once again I'm going to "troll" about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution. I hope this makes some sense, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 10/07/2010 10:48 PM, Zdenek Styblik wrote:
On 10/04/2010 08:13 PM, Laine Stump wrote: <snip>
Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call.
Only thing that popped in my head was: admin should read documentation :(
Is this the kind of behavioural thing that we should have a "reasonable default" for, plus allow for it to be configured differently via libvirtd.conf? were_special_really_really_really_please_dont_enable_ipforwarding = 1 :)
Once again I'm going to "troll" about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution.
Using the words "hooks" here makes me wonder if we could do the needed work through having network hook scripts in place (with appropriate bits to call them), and whether it would be a useful way of doing things. (absolutely no idea if it's even feasible. :>)
On 10/07/2010 01:57 PM, Justin Clift wrote:
On 10/07/2010 10:48 PM, Zdenek Styblik wrote:
On 10/04/2010 08:13 PM, Laine Stump wrote: <snip>
Exactly one of my points. libvirt really wants (no, *needs*) this to be on for virtual networks, but it's very likely there was a reason for it being turned off, so the admin should at the very least be alerted that it's being turned on, or the fact that it's off should be logged in some way to assure it gets the admin's attention so they can make the proper judgement call.
Only thing that popped in my head was: admin should read documentation :(
Is this the kind of behavioural thing that we should have a "reasonable default" for, plus allow for it to be configured differently via libvirtd.conf?
were_special_really_really_really_please_dont_enable_ipforwarding = 1
:)
Umm I don't know, but this feels as being somewhat out of the context. Ok, I don't think more log bogus will solve anything. Admin should know what software does; software documentation should clearly state what software does and does not. I really don't know what else to say about proposed point :)
Once again I'm going to "troll" about this and bundled everything inside one thing. As I've said many times already, I'm pro-external things as DHCP, firewall ... whatever. On the other hand, I realize the point of libvirt might be to ship out-of-the-box solution like it is now. I mean, tell admin what to add if he wants this and that; or make external hooks, or whatever. That's hard to say, because there is no one ultimate solution.
Using the words "hooks" here makes me wonder if we could do the needed work through having network hook scripts in place (with appropriate bits to call them), and whether it would be a useful way of doing things. (absolutely no idea if it's even feasible. :>)
Well, it might not be terminus technicus. I also see that I have unfinished point here. What I meant was and is that eg. DCC has in documentation what rules you have/should add into your firewall to make DCC to work. Hooks as external shell or whatever scripts - truly, I don't know, although that was point of some sort. Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On Fri, Oct 01, 2010 at 02:46:34PM -0400, Laine Stump wrote:
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
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.
This would be a major regression for anyone upgrading their libvirt install.
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.
Agreed, this is the wrong time/place.
5) Make ip_forward a tunable in /etc/libvirt/libvirtd.conf, and set it accordingly every time libvirtd is started.
I don't know if this makes sense either - if you have NATed or routed virtual networks, you will need ip_forward=1 for them to work properly, and if you don't have them, you don't care, so it's really redundant.
Yeah, doesn't make much sense to have to edit a config file to change a variable in a different config file. It is no better than telling people to edit sysctl.conf. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
I'd forgotten to reply to this before... On 10/07/2010 08:14 AM, Daniel P. Berrange wrote:
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
On Fri, Oct 01, 2010 at 02:46:34PM -0400, Laine Stump wrote: 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.
participants (6)
-
Daniel P. Berrange -
Eric Blake -
Justin Clift -
Laine Stump -
Stefan Berger -
Zdenek Styblik