On Mon, Oct 07, 2013 at 10:06:51AM +0100, Daniel P. Berrange wrote: > On Sun, Oct 06, 2013 at 07:25:50PM -0400, Matthew Miller wrote: > > On Sun, Oct 06, 2013 at 11:32:13PM +0200, Lennart Poettering wrote: > > > Or in other words: I don't think it makes much sense to turn this on > > > only at runtime inside the service file as matthew suggests, as it hides > > > the fact that the setting is made, makes it hard for admins to discover > > > and override it, and creates the assumption that the package would turn > > > off the setting safely again after the daemon exited, but which it > > > doesn't and can't since it doesn't know if anything else still requires > > > it. > > > Hope that makes some sense, > > > > It does make some sense; overall I don't think there's a really good answer > > here. In trying to figure out what's the most sensible given that, I looked > > at what libvirt does, which is turn it on globally in exactly the hidden way > > you suggest, and makes no attempt to restore it. I'm not really excited > > about that, but apparently that's been the case for a while. > > Yeah, what libvirt does is really not very nice. If you want to use a > routed networking setup though, I don't know of any better options for > making this work. > > We really only wanted to enable forwarding from virbr0, to the LAN, but > you can't toggle this per NIC afaick - you have to turn on the global > ip_forwarding sysctl. Libvirt just turns it on when first creating its > NAT'd device, which for most installs will be at boot time when libvirtd > starts. Another way to look at it might be: Since a lot of people have libvirt installed (it's the default isn't it?) and hence forwarding has been on for many people for a long time, what harm is it causing? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
