Re: [libvirt] [PATCH RFC] network: try to eliminate default network conflict during package install

Sometimes libvirt is installed on a host that is already using the network 192.168.122.0/24. If the libvirt-daemon-config-network package is installed, this creates a conflict, since that package has been hard-coded to create a virtual network that also uses 192.168.122.0/24. In the past libvirt has attempted to warn of / remediate this situation by checking for conflicting routes when the network is started, but it turns out that isn't always useful (for example in the case that the *other* interface/network creating the conflict hasn't yet been started at the time libvirtd start its owm networks). This patch attempts to catch the problem earlier - at install time. During the %post install for libvirt-daemon-config-network, we look through the output of "ip route show" for a route that exactly matches 192.1 68.122.0/24, and if found we search for a similar route that *doesn't* match (e.g. 192.168.123.0/24). When we find an available route, we just replace all occurences of "122" in the default.xml that is being created with ${new_sub}.

This could obviously be made more complicated - automatically determine the existing network address and mask from examining the template default.xml, etc, but this scripting is simpler and gets the job done as long as we continue to use 192.168.122.0/24 in the template. (If anyone with mad bash skillz wants to suggest something to do that, by all means please do). This is intended to at least "further reduce" the problems detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=811967 I acknowledge that it doesn't help for cases of pre-built cloud images (or live images that are created on real hardware and then run in a virtual machine), but it should at least eliminate the troubles encountered by individuals doing one-off installs (and could be used to stifle complaints for live images, as long as libvirtd was running on the system where the live image compose took place (or the compose was itself done in a virtual machine that had a 192.168.122.0/24 interface address). --- The question here is: "Will this help some people's situation without causing new problems for anyone else?"

I wouldn't mind pushing this patch, but also wouldn't mind if it was just the catalyst for discussion that leads to a better solution. We do need *some kind* of solution though, as more and more people are installing OSes that include the libvirt package in virtual machines, and are running into this problem with increasing frequency.