Re: [libvirt] libvirt default network

On 02/11/2014 10:28 AM, Thierry Parmentelat wrote: 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 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... Here's the commit: commit a13051b2242a32b024811c064ddb10b14f559513 Author: Laine Stump <laine(a)laine.org&gt; 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). Note that the change in provider for /usr/share/libvirt/network/default.xml happened sometime after 1.1.3. 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) Certainly not intentional. 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!).