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:
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?
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.
reassigning to libvirt.
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
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
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
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.
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.
(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
(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.
> 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.
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).
(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