Bug 513494

virt-manager doesn't depend on qemu/kvm because it isn't strictly tied to that: you could have no hypervisor on the local machine, and want to manage a remote server.

virt-manager show only ask for root authentication to connect to the libvirt uri 'qemu:///system': it doesn't have necessary root privs to actually start the libvirtd service.

All that said, I'm completely down for any way we can make this case easier. When we get the tools to move people more towards running qemu:///session (the per user connection, as opposed to the system wide, root requiring qemu:///system), we start the daemon on demand. But aside from that I don't have any ideas.

To expand on what Cole says...

There are two modes for libvirt drivers

 - Privileged, so called 'system' mode  (eg, qemu:///system). Named after DBus system bus since there is one instance per host. libvirtd runs as root. RPM install sets it to start on boot. User needs to authenticate via PolicyKit with root password. This is primarily intended for server deployment use cases

 - Unprivileged, so called 'session' mode (eg qemu:///session). Named after Dbus session bus sicne there is one instance per user account. libvirtd run as the user. libvirtd is auto-started on demand. User does not need to authenticate at all. THis is primarily intended for desktop deployment use cases


THe main problem we have at this time, is that the unprivileged 'session' instance cannot get any useful networking access like bridging or NAT. It is limited to Slirp networking which is majorly crap. Thus virt-manager currently uses qemu:///system for everything.  We need to figure out how to solve this networking problem for qemu:///session, at which point virt-manager can use that for local desktop use cases, at which point all Mairin's initial complaints should be addressed.  It is possible that NetworkManager might be able to help us out in this area, since it is apparently getting the ability to configure bridges in the near future....

Hi Cole & Dan,

1) re virtmanager not depending on either qemu or xen or whatever other hypervisors - that makes sense that they aren't dependencies, but at the same time, it does make for a bad user experience when out-of-the box (in many cases) the application won't work at all. could the error message offer to give you the option to configure a remote hypervisor and even maybe tying into package kit to offer up installation of the available hypervisor of your choice? (kind of how if you try to play an mp3 and don't have the codec installed, package kit offers to look for the codec for you and install if you want?) 

2) it sounds like NetworkManager network bridge configuration is the best solution to the other issue.

Thanks for the prompt responses to the bug!

For the out of the box configuration, if you select the 'Virtualization' group in anaconda you'll automatically get both virt-manager & KVM added to your install, so it is supposed to work properly.  Similarly post-install you ought to be able to do a 'yum groupinstall Virtualization' and get KVM + virt-manager.  The main problem is people who just request a direct install of virt-manager on its own.

If the user wants to use a local hypervisor connection, we could try & hook up with packagekit and ask it what's installed / offer to install kvm.

Hi everyone - it sounds like the same issues I ran into several weeks ago are still around. Based on Dan's last comment, It would seem reasonable that requesting a direct install of virt-manager should go ahead and get KVM as a dependency. even if its not technically true, for a vast majority of users it will be. Its the old 80/20 rule. Is there any harm in this? 

Secondly, on the libvirtd issue, I think we have to find a solution to getting proper networking for 'session' mode. What we are after here is to not require root authentication to simply run a VM locally.

One of the primary goals driving the ongoing UX improvements for virt-manager is to enable desktop usage for novices. The issues issues Máirín and I encountered represent a complete fail for this type of user. Their next step is to buy vmware.

(In reply to comment #5)
> Hi everyone - it sounds like the same issues I ran into several weeks ago are
> still around. Based on Dan's last comment, It would seem reasonable that
> requesting a direct install of virt-manager should go ahead and get KVM as a
> dependency. even if its not technically true, for a vast majority of users it
> will be. Its the old 80/20 rule. Is there any harm in this? 
>

Even if we do this, we have other problems. You install virt-manager, and it pulls in kvm and libvirt. The kvm kernel modules need to be loaded, and libvirtd needs to be started. Running in usermode solves the latter, but how to achieve the former without requiring root access? And currently, the root authentication that the user provides is for libvirt only, which doesn't have the ability to load the kernel modules, so do we have the user authenticate twice?

What happens in F13/F14 when xen host makes a comeback? If the user wants to use virt-manager to manage xen on the localhost, should they be forced to install kvm? If we drop the KVM dep in the future, won't that actually be worse?

I like the idea of packagekit integration: virt-manager starts for the first time, doesn't detect any usable HV, pops up a dialog asking whether to install a HV or manually set up a connection. Maybe we could find a way via package kit to offer to start libvirtd/load the kvm modules (or does packagekit unilaterally just recommend a reboot for these cases)?

The short term solution is to have this failure case offer more help to the user. We can try and see if libvirtd is running and the kvm modules are loaded, and offer instructions how to fix these problems. Maybe write up a wiki page to point them at, or (gasp) actually update the virt-manager help pages? :) Any suggestions?

There's no problem there. PackageKit is running privileged, and the kvm modules are loaded in the %post script of the RPM. So virt-manager asks for 'kvm' to be installed, and it'll just do the right thing.  With Xen you'll have to ask the user to reboot, due to need to install the hypervisor, but then people don't use Xen for desktop virt, so its not really worth worrying about that

Hi Cole,

"What happens in F13/F14 when xen host makes a comeback? If the user wants to
use virt-manager to manage xen on the localhost, should they be forced to
install kvm? If we drop the KVM dep in the future, won't that actually be
worse?"

You already suggested something along these lines now that I read through your whole message, but, you could have a first-run style wizard that says something like,

===

You've installed virt manager but you currently do not have the software needed to run a virtual guest on this system. You still will be able to run virtual guests hosted by other systems.

What would you like to do?:

(o) Enable this system to host virtual machines locally.
    [ ] Install KVM virtualization. (recommended)
    [ ] Install Xen virtualization.

( ) Connect to guests hosted by other systems.

=== 

And depending on the user's choices for the first oneyou could make a call to package kit to install the necessary packages, displaying some kind of progress dialog in the meantime. 

If the user chooses the second option give them a wizard that walks them through adding a remote hypervisor...

Right, the 'xen' scenario is only an issue with the hard kvm dependency: if we add that dep now, it will only put us in a tighter spot when there are other viable hypervisors in fedora.

Marking as an RFE and provisionally putting it on the Fedora 13 target

Okay, some work on this is now upstream:

http://hg.fedorahosted.org/hg/virt-manager/rev/437cb7da4c97

On first run, we ask PackageKit if 'libvirt' and 'qemu-system-x86' (the KVM package) are installed locally. If one of them isn't we ask the user if they would like to install, then launch the install if they agree.

The one remaining issue (provided everything works :) ) is that libvirtd isn't started. I've tried to detect this and pop up a dialog giving them several ways they can remedy this, but that's the best I can come up with.

Either way, I'll make sure this gets into F13.

virt-manager-0.8.3-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/virt-manager-0.8.3-2.fc13

virt-manager-0.8.3-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update virt-manager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/virt-manager-0.8.3-2.fc13

virt-manager-0.8.3-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.