Red Hat Bugzilla – Full Text Bug Listing
|Summary:||allow libvirt.so to be installed without libvirtd|
|Product:||[Fedora] Fedora||Reporter:||Steven Dake <sdake>|
|Component:||libvirt||Assignee:||Daniel Veillard <veillard>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||agk, berrange, cfeist, clalance, crobinso, fdinitto, itamar, lhh, markmc, rjones, swhiteho, veillard, virt-maint|
|Fixed In Version:||libvirt-0.7.0-1.fc12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-08-07 10:00:27 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Steven Dake 2009-07-02 17:48:49 EDT
Description of problem: the fence package depends on libvirt libvirt sets up a virtual bridge interface by default in the virtual machine which then causes networking within the virtual machine to fail to the outside network. Version-Release number of selected component (if applicable): rawhide How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Comment 1 Fabio Massimo Di Nitto 2009-07-03 00:33:08 EDT
I have been testing fencing agents for 2 Fedora releases with this setup and never seen this problem (nor anybody else). I have VM's running libvirt with default setup and libvirt is installed by default in fedora even before fence-agents. Are you sure this is not a regression in libvirt?
Comment 2 Fabio Massimo Di Nitto 2009-07-03 01:18:33 EDT
Actually.. I have been thinking a bit more. If there is a bug it's in libvirt. As a general user I should be able to install libvirt within a VM without breaking the world. libvirt starts automatically the bridge. Automatic startup is strongly discouraged by Fedora policies. If libvirt default clashes with the host, then libvirt needs to detect proper default. fence-agents needs libvirt for xvm operations both inside and outside VMs.
Comment 3 Steven Dake 2009-07-03 01:26:19 EDT
reassigning to libvirt.
Comment 4 Mark McLoughlin 2009-07-03 11:35:22 EDT
bug #235961 is a similar bug Not starting libvirtd automatically is an interesting possible solution. I don't totally agree that starting it by default is "strongly discouraged" e.g in https://fedoraproject.org/wiki/Packaging:SysVInitScript all I can see is: "Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs." I do think that both libvirtd and the default network should be enabled when you install the Virtualization group through anaconda/PackageKit, though. I think the only way to do that is by having both enabled by default
Comment 5 Fabio Massimo Di Nitto 2009-07-03 12:32:34 EDT
The question you want to ask yourself is: what benefit does the user have by starting up the bridge by default? as long as no guests are configured there is very little point to have the bridge up. You also don't know how the user wants the bridge configured. My suggestion would be to have the default network configured (so users can see the example in /etc/libvirtd/) but not started by default. libvirtd I believe could still start without problems. This would probably be a decent compromise for new installations, no matter if it's done by meaning of yum or anaconda or any other tools. You really don't want to take the way of special casing what package manager is in use that day. It will just make your life a lot more complicated than it needs to be. virsh could suggest that a bridge should be enabled by default at guest creation time. Just my 2c Fabio
Comment 6 Steven Dake 2009-07-03 13:45:03 EDT
Back to the root of the problem, a bridge is started in a virtual machine when libvirt is installed in that vm. That causes the virtual machine networking not to work when using bridged virtio. The libvirt package is a dependency for fenced which causes all of cluster not to work. Any package that has libvirt as a dependency in a virtual machine will inadvertantly result in the loss of the vm operation on the part of the administrator without any notification of what the problem is. Regards -steve
Comment 7 Daniel Berrange 2009-07-03 17:47:05 EDT
Actually the real root problem is that the code which starts a virtual network does not do any IP address validation. It should be doing checks to ensure the requested virtual network does not clash with any other existing interface. Fixing this would addres the problem seen here In addition, before F12 comes out we are also likely to change the way we package the libvirt RPM, such that libvirt.so is in a RPM of its own, separate from libvirtd, or virsh. This will also avoid the problem of fence scripts linking to libvirt, because they will no longer pull in the daemon. IMHO this bug should be used to track addition of IP address validation.
Comment 8 Fabio Massimo Di Nitto 2009-07-05 03:12:42 EDT
Please split the ip address validation in its own bug or this one will become an uncloseable placeholder for one too many bugs. Address validation is an extremely complex task to perform as interfaces might be up or down at the time the daemon is installed or executed. For e.g. a ppp interface or vpn could bring up a route that clashes with the bridge and there is no guarantee that it's up at installation/validation time. Those tasks are better left to the sys/net admin.
Comment 9 Mark McLoughlin 2009-07-06 08:52:09 EDT
(In reply to comment #7) > IMHO this bug should be used to track addition of IP address validation. bug #235961 is better for tracking that this bug can be closed if we split libvirt.so out from libvirtd
Comment 10 Mark McLoughlin 2009-07-06 08:54:56 EDT
(In reply to comment #5) > what benefit does the user have by starting up the bridge by default? Having NAT networking always available to users without requiring any configuration is a huge benefit. > as long as no guests are configured there is very little point to have the > bridge up. I agree that not starting the default network until a guest wants to use it is a fairly reasonable suggestion.
Comment 11 Daniel Berrange 2009-07-06 09:29:33 EDT
> I agree that not starting the default network until a guest wants to use it is > a fairly reasonable suggestion. That is not possible, since it will break any Xen driver guests using the default network, since we have no way to hook into Xen's startup process.
Comment 12 Richard W.M. Jones 2009-07-17 05:25:45 EDT
I just had the same problem installing a RHEL 5.4 beta guest on a Fedora host. The problem is pernicious, because the basic install goes through and works fine. It's *only* later when you install the libvirt package in the guest for something that the install breaks. But I agree that the solutions in comment 7 or comment 9 would seem to be the way to go (I only need the client side of libvirt in my guest).
Comment 13 Mark McLoughlin 2009-08-07 10:00:27 EDT
(In reply to comment #9) > (In reply to comment #7) > > > IMHO this bug should be used to track addition of IP address validation. > > bug #235961 is better for tracking that > > this bug can be closed if we split libvirt.so out from libvirtd I think this is resolved in F-12 - the libvirt-client RPM just provides the library, and it does not require the daemon to be installed