A couple possible solutions:
1) Use virt-what at rpm install time: if we are running in a VM, change the default network to 192.168.123.1. Doesn't help existing users. Problems with doubly nested virt.
2) Have libvirt listen to networkmanager changes, and if we see a route pop up that conflicts with a running virtual network, shut down the virtual network. Pretty scary to just stop the network, not positive it's possible (haven't looked at the NM api).

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

colin: systemd has a conditional for that, in fact: ConditionVirtualization= . It might be cleaner to use that. Just this in the .service file would achieve what you wanted (it'll stop the service starting up if we're running in a KVM):
ConditionVirtualization=!kvm

(In reply to Adam Williamson from comment #4)
> colin: systemd has a conditional for that, in fact: ConditionVirtualization=
> . It might be cleaner to use that. Just this in the .service file would
> achieve what you wanted (it'll stop the service starting up if we're running
> in a KVM):
>
> ConditionVirtualization=!kvm
The problem is that it is valid to use libvirt inside a VM; for many reasons:
1) libvirt can manage containers, containers can run in a VM
2) You may want to test libvirt, and having to override the systemd unit file to explicitly disable the ConditionVirtualization would be annoying
3) Nested virt is coming
So I think we need a solution that makes the whole thing more dynamic - *only* when you start Boxes do you get the nested libvirt, for example.
(This is all doubly ironic because Boxes uses qemu:///session which doesn't even make use of the NAT network libvirt starts for qemu:///system)

So...another option. Right now the libvirt.service file has a comment saying it doesn't do socket activation because libvirt wants to spawn any guests configured to autostart.
But what if libvirt wrote out unit files for these guests, with e.g.:
ExecStart=virsh -c qemu:///system start foo
Then they'd socket activate libvirtd.
And in the normal case of not having any guests configured to autostart, libvirtd wouldn't start either.

fwiw, I'm seeing this (I think it's this) in Rawhide lives ATM. Just built one to test something else, and on some boots of that live image in a VM, I have a running dnsmasq process belonging to libvirtd.service in the guest and can't get out to the internet. (On other boots of the same live image, no dnsmasq process, and internet access works).

saw this in bare metal install of f21 workstation-live-(rawhide)x86_64 20140604 from DVD
only bridged networking available I set up wired and wireless in running live DVD first and it did not transfer settings to install. Unable to add in settings/network in gnome - no eth0 or wireless in (+) add drop down.

so, yeah, s/occasionally/often/ . I did a whole bunch of F21/F22 live image boots to test https://bugzilla.redhat.com/show_bug.cgi?id=1121301 on Friday, and hit this bug more often than not. Any chance anyone might feel like fixing it?
For anyone playing along at home, to get networking working, do:
ip link set virbr0 down
brctl delbr virbr0

(In reply to Adam Williamson (Red Hat) from comment #14)
> so, yeah, s/occasionally/often/ . I did a whole bunch of F21/F22 live image
> boots to test https://bugzilla.redhat.com/show_bug.cgi?id=1121301 on Friday,
> and hit this bug more often than not. Any chance anyone might feel like
> fixing it?
>
> For anyone playing along at home, to get networking working, do:
>
> ip link set virbr0 down
> brctl delbr virbr0
The libvirty way is:
sudo virsh net-destroy default
sudo virsh net-autostart --disable default
Will fix things to not mess up on reboot as well. But not sure if those commands will make network connectivity magically return or if NetworkManager will need a restart.
I just sent a mail to libvir-list asking for ideas and/or volunteers:
http://www.redhat.com/archives/libvir-list/2014-July/msg01379.html

Note that I don't recommend this workaround for people who have pre-existing machines in GNOME Boxes - it fixes network for new machines but makes old machines (that are configured for bridged networking and not usermode networking) to fail to boot :(

(I think it wouldn't hurt to have Fedora bug too to track this
since this is affecting F21Alpha guests frequently.)
Anyway what is the simplest workaround for F21 Alpha?
"yum remove libvirt-client; reboot"?
(I mean assuming one doesn't want guest virt.)
Should this issue be an F21 Alpha blocker or Common_Bug at least?
When one hits this for the first time it is not very obvious
what is going on...

jens: virt stuf is beta (not alpha) blocking by policy (all the criteria are at beta). I support alpha FE in theory, but it seems like it's not a simple bug to fix or it'd've been fixed by now, so I suspect any fix that comes will be too large for a freeze exception at this point.

I was thinking about this again last night. In the past we've tried the following things:
1) add code to libvirt to prevent starting a virtual network if it creates a route that conflicts with an existing route (same subnet + netmask).
2) split the default network config off into a separate sub package (libvirt-daemon-config-network) and tell people setting up "spins" that when they want libvirt installed, but don't want the mess caused by the default network, they shouldn't install that package.
Both of these items were useful, but didn't solve the problem - (1) is ineffective because the guest's network interface is often configured to use dhcp, and libvirt is often started prior to dhclient acquiring the conflicting IP address (and there is no reasonable way to know beforehand if that is going to happen. (2) doesn't work because many people running nested virtt actually *do* want the default virtual network to exist, so it seems that nobody has actually removed libvirt-daemon-config-network from their list of packages.
People have also proposed a) not installing the default network config if running in a virtual guest, and b) changing the address of the default network if running in a virtual guest. (a) doesn't seem useful, since as I said many people really do want a default network in those cases, and (b) could have exactly the opposite of the desired effect if someone had already modified their L1 host's default network config (in anticipation of this problem) to, for example, 192.168.123.0/24, and our "fix" also happened to use 192.168.123.0/24 for the guest's default network.
So how about this:
We modify the rpm script that creates the default network so that it checks for conflicting routes at install time, and if there is a conflict, it searches through the 192.168.x.0/24 networks (starting at 122, for historical reasons) until it finds one that has no currently conflicting route. I'm guessing that during install, the guest will already have its network interfaces configured and up, so we wouldn't run into the same runtime race we have now, and I'm also assuming that at least 99% of people installing an OS will keep the network config they used during installation.
Does this sound like an acceptable solution? If so, I'll look into implementing that - we already modify the default network's <uuid> element in the "%post daemon-config-network" section of the rpm, so it wouldn't be a huge leap to modify the network address as well (although it could be a bit complicated to do with a bash script :-P)

We've thought of doing that before, but one of the limitations of that is that it does not help pre-built cloud images, since the place you are building those is not the same as the place you are deploying them.

(In reply to Laine Stump from comment #25)
> so it seems that nobody has actually removed libvirt-daemon-config-network from their list of packages.
libvirt-deamon-config-network is a gnome-boxes dependency so it will be installed by default (at least on Workstation) - it is required for bridged networking which works much better than usermode networking. People running Workstation on real hardware should be able to enjoy fast networking in their VM without having to install extra packages.

(In reply to Daniel Berrange from comment #27)
> We've thought of doing that before, but one of the limitations of that is
> that it does not help pre-built cloud images, since the place you are
> building those is not the same as the place you are deploying them.
Ugh. Right. I would hope that someone creating a pre-built cloud image would take the time to do more tweaking to the image though, perhaps manually forcing the address to something different.
And in the meantime, although what I'm suggesting doesn't fix the problem for pre-built cloud images, I don't think it would *hurt* anything in that case, would it? So in the end it wouldn't fix the problem for everyone, but could fix it for many of them.
(In reply to Elad Alfassa from comment #28)
> libvirt-deamon-config-network is a gnome-boxes dependency so it will be
> installed by default (at least on Workstation) - it is required for bridged
> networking which works much better than usermode networking. People running
> Workstation on real hardware should be able to enjoy fast networking in
> their VM without having to install extra packages.
So you're saying that gnome-boxes is installed by default on Fedora Workstation, correct?
This is a good example of why the idea of "don't install the default network config package" wasn't a generally useful solution.

(In reply to Laine Stump from comment #29)
> (In reply to Elad Alfassa from comment #28)
> > libvirt-deamon-config-network is a gnome-boxes dependency so it will be
> > installed by default (at least on Workstation) - it is required for bridged
> > networking which works much better than usermode networking. People running
> > Workstation on real hardware should be able to enjoy fast networking in
> > their VM without having to install extra packages.
>
> So you're saying that gnome-boxes is installed by default on Fedora
> Workstation, correct?
>
> This is a good example of why the idea of "don't install the default network
> config package" wasn't a generally useful solution.
It is certainly useful from the POV or OpenStack or oVirt, both of which have deployment approaches that avoid pulling in the default network. Fedora Workstation isn't the only usage scenario we need to care about.

er, oh. and I don't think it'll cover non-live ('traditional') installs either, as libvirt is not going to be running in the anaconda environment. option b) above actually seems viable to me, if you pick a sufficiently non-likely alternative network. People are fairly predictable; I suspect those who thought ahead would be very likely to a) increment by 1 (123), b) double (244), c) bump one digit (132 or 222)...something pattern-y like that. So if you choose something completely odd - and literally odd, humans like even numbers - like 197, I suspect it'd work fine for a very large number of cases.
It does presumably depend on systemd's virt detection and thus may not help some obscure virt environments, might have bugs where the virt detection doesn't fire, but I think it'd fly for rather a lot of the cases.
Also, on 1):
"and libvirt is often started prior to dhclient acquiring the conflicting IP address (and there is no reasonable way to know beforehand if that is going to happen)"
this seems like something that should be vulnerable to attack? what's the problem with using service ordering here, so libvirt comes up after network is up? yes, it could result in a delay to libvirt init when network config is messily broken, but that doesn't seem like the end of the world.

I see the problem with the live image composes (which is similar to the problem Daniel points out with pre-built cloud images), but in the case of non-live installs, libvirtd does *not* need to be running during the time that anaconda is installing packages. The only assumption is that the system on which the installation is taking place has ifup'ed its network interfaces so that the "%post libvirt-daemon-config-network" section of the specfile will see the conflict when it runs a short script looking for "192.168.122.0/24" in the output of "ip route show". I've coded this up and it does work.
BTW, my option (b) above (change the address of the default network to some fixed alternate when installing in a virtual machine) would not work for the case of a live image compose unless the live image compose was itself taking place in a virtual machine (but then the address would be "wrong" for the cases where someone booted the live image on real hardware).
Bah. There simply is no silver bullet for this problem :-/
I just posted an RFC patch upstream that does what I'm suggesting, so feel free to rip it apart there as well:
https://www.redhat.com/archives/libvir-list/2014-September/msg00581.html

Is the live image composed in a vm or on bare metal? Would it work to try something as simple as running virt-what as part of the rpm install script, and if bare metal use 192.168.122.0 vs. known virtual use 192.168.123.0?

yeah, I realized after posting that I was wrong about traditional installs, they would work with your patch.
The live image compose environment is actually mock - a mock chroot in a koji run. This rather strongly limits the amount of messing about we can do with the live compose environment.
I was reading b) as a *run-time* thing, not an *install-time* thing, BTW - I was kinda imagining a setup where the default network's on-disk configuration doesn't specify a subnet but says something like 'default', and then at each boot the environment is checked and that's turned into 122 or 197 (or whatever) depending on the test.

here's another trial balloon - what if libvirt networks were started on demand, not at boot? don't bring it up until a VM that uses it is started?
that would avoid the problem entirely for people who don't actually run any nested VMs, and for people who do, it would be much more likely that the main network stack would be up at that point, and you could check for conflicts?

(In reply to Adam Williamson (Red Hat) from comment #38)
> here's another trial balloon - what if libvirt networks were started on
> demand, not at boot? don't bring it up until a VM that uses it is started?
That doesn't work with all of the libvirt hypervisors, specifically with the XenD based virt driver guests can be started directly by talking to XenD and so libvirt has no way to hook in to start the network.

(In reply to Daniel Berrange from comment #41)
> (In reply to Adam Williamson (Red Hat) from comment #38)
> > here's another trial balloon - what if libvirt networks were started on
> > demand, not at boot? don't bring it up until a VM that uses it is started?
>
> That doesn't work with all of the libvirt hypervisors, specifically with the
> XenD based virt driver guests can be started directly by talking to XenD and
> so libvirt has no way to hook in to start the network.
Oh and it would also be a major incompatible semantic change to the libvirt APIs for (auto-)starting networks, so that pretty much rules it out.

Another use case where starting networks only on demand would break existing use of libvirt networks:
Although it is making wild assumptions, gnome-boxes has a mode that uses the qemu bridge helper to connect a network interface of a session-mode libvirt to the bridge named virbr0, e.g.:
<interface type='bridge'>
<source bridge='virbr0'/>
...
It does this because that's the only way a qemu instance started by unprivileged libvirt can have any kind of network connection other than qemu usermode networking. So a process with no ability to autostart the network is assuming that the network is already started.

Since a couple of people on libvir-list agreed that it would cause more good than harm,
V1: https://www.redhat.com/archives/libvir-list/2014-September/msg00581.html
V2: https://www.redhat.com/archives/libvir-list/2014-September/msg00797.html
I just pushed the patch I discussed above to libvirt upstream:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=5f71959667e4902d738a849e7c9391e794fccf22
Because Kashyap provided personal confirmation that some people are already pre-setting their default networks to 192.168.124.0/24 in the L1 (or is it L0?) host, I start scanning for an open subnet at 192.168.124.0/24.
Should we add that patch to the fedora rawhide (and F21) libvirt builds to see how it fares in the field?
This still leaves the problem of the Fedora Live images (and other similar pre-built images that are constructed in a different environment than that in which they eventually run). Since the live image compose is done in a minimal "mock" environment that can't have the libvirt default network turned on (or I guess even have a dummy static route added), we need to do something else either at runtime or install time. So far the thing that sounds the least damaging to other scenarios is to make libvirtd start depend on networking being completely *up* (not just started). It seems like someone may have had a reason why this shouldn't/couldn't be done though, can someone remind me of that?

(In reply to Laine Stump from comment #44)
> Since a couple of people on libvir-list agreed that it would cause more good
> than harm,
>
> V1: https://www.redhat.com/archives/libvir-list/2014-September/msg00581.html
> V2: https://www.redhat.com/archives/libvir-list/2014-September/msg00797.html
>
> I just pushed the patch I discussed above to libvirt upstream:
>
> http://libvirt.org/git/?p=libvirt.git;a=commit;
> h=5f71959667e4902d738a849e7c9391e794fccf22
>
> Because Kashyap provided personal confirmation that some people are already
> pre-setting their default networks to 192.168.124.0/24 in the L1 (or is it
> L0?) host,
It's on L0 (on physical host) - so that I could avoid the conflit on L1 (the guest hypervisor). And if L0 is already running w/ the default libvirt network, then I change the 'default' network in L1.
> I start scanning for an open subnet at 192.168.124.0/24.
>
> Should we add that patch to the fedora rawhide (and F21) libvirt builds to
> see how it fares in the field?
I just pulled the latest libvirt git master and built local RPMs and doing a little test with KVM-based nested virtualization. Result upcoming. . .

Okay, I've pushed the fix that Kashyap tested above:
commit 22048ae61dbb7876d17bcf7dbedf9e8d1cf98d4e
Author: Laine Stump <laine@laine.org>
Date: Mon Sep 15 13:30:08 2014 -0400
network: detect conflicting route even if it is the final entry
This is a followup to commit 5f719596, which checks for a route
conflicting with the standard libvirt default network subnet
(192.168.122.0/24). It turns out that $() strips the trailing newline
from the output of "ip route show", so there would be no match if the
route we were looking for was the final line of output. This can be
solved by adding ${nl} to the end of the output (just as we were
already adding it at the beginning of the output).
So this patch, along with commit 5f719596, would need to be backported to get the proper fix.
Thanks for the testing/debugging help, Kashyap!

Package libvirt-1.2.8-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-1.2.8-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10844/libvirt-1.2.8-2.fc21
then log in and leave karma (feedback).