Not entirely sure of the reproducer for this, but after my F18 system had been up for some time and I'd been using VMs periodically, I switched to virt-manager and found it not connected to libvirt. systemctl showed libvirt as having crashed. Trying to start it again either directly or via systemctl causes an immediate core dump. Attached is the trace from just running /usr/sbin/libvirtd through gdb.
Created attachment 607701 [details] backtrace from gdb
This is a known issue - we are waiting for a build of libvirt against netcf-0.2.2 in order to consistently use libnl-3 across the library (the crash you are seeing is a combination of libnl-1 from libvirt and libnl-3 from netcf). In the meantime, downgrade netcf (that is, the netcf from updates-testing is unusable unless you also pair it with the to-be-built libvirt 0.10.0).
Discussed in this thread: https://www.redhat.com/archives/libvir-list/2012-August/msg01704.html
*** Bug 852387 has been marked as a duplicate of this bug. ***
*** Bug 852717 has been marked as a duplicate of this bug. ***
I just downloaded libvirt-0.10.1-2.fc18 from koji and it works fine for me.
Actually, it could be caused either by having new libvirt + old netcf, or by having old libvirt + new netcf. (in this context, "new" means "built with libnl3-devel" and "old" means "built with libnl-devel (aka 1.1)"). As far as I can see the f18 repos are stuck at libvirt-0.10.0rc0, which is an "old" build, f18 stable is at netcf-0.2.1 ("old") and f18 updates-testing is at netcf-0.2.2 ("new"). (The libvirt-0.10.1-2 build Adam is talking about is only in koji, not in any repo yet.). My guess is that anyone just updating with yum and *not* including updates-testing will have no problems, but someone updating with yum including updates-testing will crash due to netcf being "too new". On the other hand, someone who builds/installs libvirt manually and takes netcf from the repo *without* updates-testing will crash due to libvirt being too new. There is currently a freeze in place, so nothing new can move to stable, however I think we can still put a new libvirt into updates-testing, which should solve the problem for everyone except those who don't have updates-testing, yet want to build libvirt locally. Said update should include the specfile change I mention in Bug 853381 (which I think is a separate bug - that bug seems to be about having an old netcf, while this bug seems to be about having an old libvirt).
*** Bug 856524 has been marked as a duplicate of this bug. ***
An update has been submitted, and will be in the updates-testing repo "soon" (usually completed within a day I think): https://admin.fedoraproject.org/updates/libvirt-0.10.1-2.fc18 updating with that will solve the problem (although it doesn't include the patch in Bug 853381 to force a netcf update, the people at this bug are those who've already updated netcf anyway).
Installed virtualization with 'yum --disablerepo=updates-testing install @virtualization' enable/start libvirtd.service and this is the result. backtrace_rating: 4 Package: libvirt-daemon-0.10.0-0rc0.2.fc18 OS Release: Fedora release 18 (Spherical Cow)
Created attachment 614137 [details] File: backtrace
libvirt-0.10.1-4.fc18 has been pushed to the Fedora 18 stable repository. It solves the problem described here by linking against libnl-3 rather than libnl-1.