This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 509458 - allow libvirt.so to be installed without libvirtd
allow libvirt.so to be installed without libvirtd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
 
Reported: 2009-07-02 17:48 EDT by Steven Dake
Modified: 2016-04-26 17:04 EDT (History)
13 users (show)

See Also:
Fixed In Version: libvirt-0.7.0-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-07 10:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.