Increasingly there’s a need for libvirt networking to work inside a virtual machine that is already running on the default network (192.168.122.0/24). The immediate practical case where this comes up is while testing nested virtualization: start a guest (L1) with default libvirt networking, and if you need to install libvirt again on it to run a (nested) guest (L2), there’ll be routing conflict because of the existing default route — 192.168.122.0/24. Up until now, I tried to avoid this by creating a new libvirt network with a different IP range (or manually edit the default libvirt network).
To alleviate this routing conflict, Laine Stump (libvirt developer) now pushed a patch (with a tiny follow up) to upstream libvirt git. (Relevant libvirt bug with discussion.)
I ended up testing the patch last night, it works well.
Assuming your physical host (L0) has the default libvirt network route:
$ ip route show | grep virbr 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
Now, start a guest (L1) and when you install libvirt (which has the said fix) on it, it notices the existing route of 192.168.122.0/24 and creates the default network on the next free network range (starting its search with 192.168.124.0/24), thus avoiding the routing conflict.
$ ip route show default via 192.168.122.1 dev ens2 proto static metric 1024 192.168.122.0/24 dev ens2 proto kernel scope link src 192.168.122.62 192.168.124.0/24 dev virbr0 proto kernel scope link src 192.168.124.1
Relevant snippet of the default libvirt network (you can notice the new network range):
$ virsh net-dumpxml default | grep "ip address" -A4
<ip address='192.168.124.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.124.2' end='192.168.124.254'/>
</dhcp>
</ip>
So, please test it (build RPMs locally from git master or should be available in the next upstream libvirt release, early October) for your use cases and report bugs, if any.
[Update: On Fedora, this fix is available from version libvirt-1.2.8-2.fc21 onwards.]
Kashyap Chamarthy 