Hello Laine; please see inline — many thanks for the feedback in any case — Thierry On 11 Feb 2014, at 11:48, Laine Stump <laine@xxxxxxxxx> wrote: > On 02/11/2014 10:28 AM, Thierry Parmentelat wrote: >> Hi >> >> This is in echo to a message originally sent on libvirt-users, but having not received any answer yet so we figured we would try this list instead > > For this question, either list is appropriate, it's just that nobody has > gotten around to answering the mail sent to libvirt-users (yesterday > afternoon) yet. Since monitoring of the lists is done on a volunteer > basis, that's not uncommon. I’m sorry if it sounded like I was blaming or anything, not at all, I perfectly understand the delay, it’s just that I was really thinking this was the right list and not the -users one. :) > >> >> So, we use libvirt on various flavours of fedora; with fedora18 we were using libvirt-1.0.4, that we rebuilt using a slightly modified version of mainstream specfile >> Under fedora20 we’ve first tried using the libvirt version that comes with vanilla fedora - 1.1.3 - but are seeing glitches that apparently are fixed in 1.2.1, so we’re giving this a shot >> >> The problem we have is, right after installation of our libvirt rpm, the ‘default’ network is not known to the system: >> [root@vnode07 ~]# virsh -c lxc:// net-dumpxml default >> error: failed to get network 'default' >> error: Network not found: no network with matching name ‘default' >> >> While the ‘source’ file for this default network did ship with the rpm >> [root@vnode07 ~]# rpm -qf /usr/share/libvirt/networks/default.xml >> libvirt-daemon-driver-network-1.2.1-0.x86_64 > > (I had already written a message saying that things hadn't changed in > this area "for awhile", but before sending it saw your message pointing > out that /usr/share/libvirt/networks/default.xml was provided by > libvirt-daemon-driver-network, while I had thought it was provided by > libvirt-daemon. So I looked at historic "yum provides" information and > saw that it *previously* was provided by libvirt-daemon, and is now > provided by libvirt-daemon-driver-network *and* I believe it was *me* > that made this change :-0. It's amazing how much I can forget… yeah, well you’re not alone on that land, unfortunately, and it’s not getting any better ;) > Here's > the commit: > > commit a13051b2242a32b024811c064ddb10b14f559513 > Author: Laine Stump <laine@xxxxxxxxx> > Date: Fri Dec 13 17:03:26 2013 +0200 > > specfile: fix make rpm when with_driver_modules is 1 > > > Aside from the missing dependency you missed in your reply to yourself, > the convoluted nature of the install, and/or difference in behavior > between a fresh install and an upgrade may explain what you're seeing. > > During the "%install" step of an rpm build, the specfile copies the > default network config from /etc/libvirt/qemu/networks/default.xml to > /usr/share/libvirt/networks/default.xml in the rpmbuild install staging > area (See line 1484 in the latest upstream libvirt.spec.in.), and that > file is packaged in the libvirt-daemon-driver-network package (See ~line > 1951). Then during the "%post" step of an actual install of the > libvirt-daemon-config-network sub-package (~line 1690), *only if there > is currently no file at /etc/libvirt/qemu/networks/default.xml*, the > file in /usr/share/libvirt/networks/default.xml is copied to /etc and a > new uuid is generated and put in the file. > > (Note that if you've set the specfile to *not* separately configure > modules, then /usr/share/libvirt/networks/default.xml *is* still > provided by the libvirt-daemon package (which contains libvirt-daemon-* > in that case), handled ~line 1879) > > Of course this is just copying the config file - any currently running > libvirtd process will not have been informed of this new file (libvirtd > is well documented to not like having its config files modified behind > its back). So until/unless libvirtd is restarted, this new network won't > be seen. > > So there are four possible points where your new default network > definition may not be seen: > > 1) possibly you aren't installing the "libvirt-daemon-config-network" > sub-package (until a couple Fedora versions ago, this was a part of the > main libvirt package). > > 2) Even if you do have libvirt-daemon-config-network installed and are > upgrading libvirt, if a default network is already in place on the > system, an upgrade will not overwrite this existing network. > > 3) as you've pointed out, possibly you're missing the > libvirt-daemon-driver-network package somehow? > > 4) Even if you are installing/upgrading libvirt-daemon-config-network > and the system doesn't already have a default network in place, *if > libvirt-daemon-config-network package is installed/updated after the > libvirt-daemon package is installed/updated (i.e. libvirtd has already > been restarted), then the newly placed default.xml will not be > recognized until the libvirtd service is again restarted. (actually it > appears that yum (or maybe rpm) is smart enough to do upgrade the files > from all packages before running any %post scripts, so that may not be a > problem). I value your explanations very much however it seems that in our case: . this is observed in a test framework, and we run into this problem right after installing for the first time, there’s no upgrading in the loop . I should probably have added the extract below to the report this is captured at build-time when preparing the image that these nodes will be running as you can see the post install snippet responsible for creating the /etc/libvirt/… stub fails because at that time, the source from /usr/share/libvirt is not available yet Installing : libvirt-client-1.2.1-0.x86_64 242/340 Installing : libvirt-python-1.2.1-0.x86_64 243/340 ... Installing : libvirt-daemon-1.2.1-0.x86_64 249/340 Installing : libvirt-daemon-driver-secret-1.2.1-0.x86_64 250/340 Installing : libvirt-daemon-driver-nodedev-1.2.1-0.x86_64 251/340 Installing : libvirt-daemon-config-network-1.2.1-0.x86_64 252/340 /var/tmp/rpm-tmp.4piryn: line 3: /usr/share/libvirt/networks/default.xml: No such file or directory ln: failed to create symbolic link '/etc/libvirt/qemu/networks/autostart/default.xml': No such file or directory warning: %post(libvirt-daemon-config-network-1.2.1-0.x86_64) scriptlet failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm package libvirt-daemon-config-network-1.2.1-0.x86_64 Installing : libvirt-daemon-driver-uml-1.2.1-0.x86_64 253/340 Installing : libvirt-daemon-config-nwfilter-1.2.1-0.x86_64 254/340 Installing : ebtables-2.0.10-11.fc20.x86_64 255/340 Installing : libvirt-daemon-driver-nwfilter-1.2.1-0.x86_64 256/340 ... Installing : libvirt-daemon-driver-network-1.2.1-0.x86_64 276/340 Installing : libvirt-daemon-driver-lxc-1.2.1-0.x86_64 277/340 >> ------------ >> What we used to have with 1.0.4 and 1.1.3 at that same point (right after yum install) is > > Note that the change in provider for > /usr/share/libvirt/network/default.xml happened sometime after 1.1.3. > >> [root@vnode05 ~]# virsh -c lxc:// net-dumpxml default >> <network connections='1510’> > > 1510 connections? Wow! That's a lot of guest interfaces! As a matter of > fact, a Linux host bridge can only support 256 (or maybe it's 255 or > 254) attached interfaces, so I'm curious how you manage that. (BTW, if > you're defining the network with a connections attribute, it should be > ignored, since it is a read-only attribute that starts at 0 when the > network is started, and is maintained by libvirtd itself as guest > interfaces are connected/disconnected) right, the figure stunned me as well, and I am determined to give this a look at some point; but first things first ((also the node itself runs as a kvm/qemu instance, might this have an impact on the figure ?)) now, does this count like, the number of containers that tap into this device, or like the name says, network connections at e.g. the TCP level ? > >> .. >> </network> >> >> — >> So, I’m confident we can tweak our specfile to get this to work by adding something like net-define / net-autostart / net-start somewhere near the post install script of the daemon package or something >> >> However we would appreciate some insight as to how this would happen in the first place; is this an intentional change on your end ? > > Certainly not intentional. It thought as much > >> or did we screw that up somehow ? if so, I could not find out precisely how this network definition is supposed to take place when the package gets installed, any hint / insight on that would be much appreciated >> > > Based on my description above, if you find anything that would make the > whole mess operate more cleanly and/or correctly, please send a patch to > libvir-list (using git send-email please!). will do; I’m currently playing with a one-liner that adds the Requires: directive as I described if that works I’ll send a separate message thanks again — Thierry -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list