On Wed, Sep 10, 2014 at 01:54:00PM -0400, Laine Stump wrote:
> 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}.
Thanks for writing this patch, Laine.
> 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, for one, certainly welcome this change. I used to hit this case when
setting up nested virtualization with libvirt -- although, by now I
instinctively create a non-default libvirt network on my physical host
(L0), so my guest hypervisor (L1) can use the default libvirt network
without conflicts while running the nested guest (L2).
ACK for the idea, FWIW.
> 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.
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list