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.
>
> 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... 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).
>
> ------------
> 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)
> ..
> </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.
> 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!).
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list