]> git.ipfire.org Git - thirdparty/libvirt.git/commit
network: try to eliminate default network conflict during package install
authorLaine Stump <laine@laine.org>
Wed, 10 Sep 2014 17:10:45 +0000 (13:10 -0400)
committerEric Blake <eblake@redhat.com>
Wed, 17 Sep 2014 17:40:15 +0000 (11:40 -0600)
commit78503276c1337bf0b2703b99599c92268e551eb7
tree813e6398e8a988c41bed1469686b94b92ea926df
parent6bdf14150e99ca8921a4017bb9502325e200815b
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 own
networks).

This patch attempts to catch the problem earlier - at install
time. During the %post install script for
libvirt-daemon-config-network, we use a case statement to look through
the output of "ip route show" for a route that exactly matches
192.168.122.0/24, and if found we search for a similar route that
*doesn't* match (e.g. 192.168.124.0/24) (note that the search starts
with "124" instead of 123 because of reports of people already
modifying their L1 host's network to 192.168.123.0/24 in an attempt to
solve exactly the problem we are also trying to solve).  When we find
an available route, we just replace all occurrences of "122" in the
default.xml that is being created with the newly found 192.168
subnet. This could obviously be made more complicated - examine the
template defaul.xml to automatically determine the existing network
address and mask rather than hard coding it in the specfile, 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" occurrence of the
problems detailed in:

  https://bugzilla.redhat.com/show_bug.cgi?id=811967

(cherry picked from commit 5f71959667e4902d738a849e7c9391e794fccf22)
libvirt.spec.in