Bug 800893 - libvirtd startup install not working (package names changed?)
Summary: libvirtd startup install not working (package names changed?)
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-07 13:27 UTC by Stef Walter
Modified: 2013-02-07 16:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-07 14:18:30 UTC
Type: ---


Attachments (Terms of Use)
Screenshot of problem (32.59 KB, image/png)
2012-03-07 13:27 UTC, Stef Walter
no flags Details

Description Stef Walter 2012-03-07 13:27:06 UTC
Created attachment 568287 [details]
Screenshot of problem

Description of problem:

When opening virt-manager for the first time I see a dialog containing the following messages:

Unable to connect to libvirt.

internal error Unable to locate libvirtd daemon in $PATH

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
    flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: internal error Unable to locate libvirtd daemon in $PATH


Version-Release number of selected component (if applicable):

Installed Packages
Name        : virt-manager
Arch        : noarch
Version     : 0.9.1
Release     : 2.fc17


How reproducible:

Every time.

Steps to Reproduce:
1. Install virt-manager on clean FC17 system.
2. Open virt-manager
  
Actual results:

Technical error message with stack trace.

Expected results:

Dialog that notes that libvirtd is not installed with button to install it via package-kit.

Or even better, make libvirtd a dependency of virt-manager so it "just works TM".

Additional info:

Comment 1 Cole Robinson 2012-04-02 21:14:30 UTC
Hmm, virt-manager has packagekit code to do just that. Maybe libvirt package layout changed in f17 and we need to tweak things...

Comment 2 RedHat-User 2012-06-14 14:31:01 UTC
The same thing happens to me on a fresh Fedora 17 x86_64 net-install.  I have the following installed:

libvirt-client-0.9.11.3-1.fc17.x86_64
libvirt-python-0.9.11.3-1.fc17.x86_64
qemu-common-1.0-17.fc17.x86_64
qemu-kvm-1.0-17.fc17.x86_64
qemu-system-x86-1.0-17.fc17.x86_64
virt-manager-0.9.1-3.fc17.noarch
virt-manager-common-0.9.1-3.fc17.noarch

I installed libvirt-daemon-kvm.x86_64 (with its 9 dependencies, 1 of which is libvirt-daemon.x86_64) and executed "sudo /etc/init.d/libvirtd start".  Only then was I able to successfully start the Virtual Machine Manager without the error.

Comment 3 Daniel Berrangé 2012-06-14 14:34:54 UTC
(In reply to comment #1)
> Hmm, virt-manager has packagekit code to do just that. Maybe libvirt package
> layout changed in f17 and we need to tweak things...

Yes, package layout changed, but it should be fully backwards compatible. ie if virt-manager was installing the 'libvirt' RPM in previous Fedora, it should have exactly same effect in current Fedora. The main 'libvirt' RPM has deps on all the new sub-RPMs that would be required. Also the 'libvirtd' service name is still the same as before, albeit we have a systemd init script now.

Comment 4 RedHat-User 2012-06-14 16:19:27 UTC
(In reply to comment #2)
===
> I installed libvirt-daemon-kvm.x86_64 (with its 9 dependencies, 1 of which
> is libvirt-daemon.x86_64)
===

I don't know if this should be a dependancy of libvrit-daemon, but I noticed libvirt-daemon-config-network did not get installed.  Thus, guest machines could not use NAT for network connectivity.

Comment 5 Daniel Berrangé 2012-06-14 16:23:16 UTC
(In reply to comment #4)
> (In reply to comment #2)
> ===
> > I installed libvirt-daemon-kvm.x86_64 (with its 9 dependencies, 1 of which
> > is libvirt-daemon.x86_64)
> ===
> 
> I don't know if this should be a dependancy of libvrit-daemon, but I noticed
> libvirt-daemon-config-network did not get installed.  Thus, guest machines
> could not use NAT for network connectivity.

'libvirt' depends on libvirt-daemon-config-network as before. libvirt-daemon explicitly avoids a requirement, since this config is intended to be optional for people who don't want the libvirt NAT network present.

Comment 6 RedHat-User 2012-06-17 06:02:38 UTC
(In reply to comment #5)
===
> 'libvirt' depends on libvirt-daemon-config-network as before. libvirt-daemon
> explicitly avoids a requirement, since this config is intended to be
> optional for people who don't want the libvirt NAT network present.
===

Thank you.  That makes sense; I can see plenty of reasons why people would not need NAT networking for their virtual guests.

I originally tried installing KVM with just "yum -y install qemu-kvm virt-manager".  I thought that had worked in Fedora 15 to install everything necessary along with the optional packages like the package that gives NAT support.

Reading through this page[1] of the _Fedora 13 Virtualization Guide_, I see I should have used "yum install kvm virt-manager libvirt libvirt-python python-virtinst" to get everything I need.

[1]The latest Fedora virtualization guide; none available for Fedora 14, 15, 16, or 17, as far as I can see -- <http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Installing_the_virtualization_packages-Installing_KVM_packages_on_an_existing_Red_Hat_Enterprise_Linux_system.html>

Thanks again.

Comment 7 Cole Robinson 2012-07-07 14:18:30 UTC
I can't reproduce this on F17 GA. Installing virt-manager on a fresh install, it will offer to install qemu-system-x86 and libvirt packages, which is still sufficient to make KVM guests work. Closing as WORKSFORME

Comment 8 Hal Annen 2013-02-07 16:27:49 UTC
This should not be closed. I experienced the exact same behavior on fresh install of F17 x64 (and all updates) after installing VMM via GUI Add/Remove Software.


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