Bug 557103

BTW, Fedora 12 selinux includes /home/*/VirtualMachines as a correctly labeled place to put virtual images.

Using a storage pool in /home isn't really a good default option for the current virt configuration, since the VMs are run by the system wide libvirtd instance. It would be equivalent to default sharing out httpd web pages from a regular users home directory.

The proper solution here is to move towards using qemu:///session for default desktop virt. With qemu:///session, libvirtd is run as the regular user, which avoids all sorts of integration issues like file/media permissions, sound not working, etc. , but comes with its own pain points like networking configuration.

Might as well use this bug to track that work.

*** Bug 559005 has been marked as a duplicate of this bug. ***

Moving to upstream tracker

Now that gnome-boxes exists and uses qemu:///session, virt-manager might not be destined to default to qemu:///session. I'll have to give it some thought. But support should definitely be improved, and step one at least is exposing system vs. session in the UI.

*** Bug 845604 has been marked as a duplicate of this bug. ***

*** Bug 892765 has been marked as a duplicate of this bug. ***

Eh, I changed my mind, I don't think there's much to do here. If people have specific suggestions we can try to address them but we aren't ever going to be using qemu:///session I don't think

It mostly works for me, as long as I do simple things (create a VM, start/stop, no network changes). So it would be nice if this would be easier to setup. For instance, have "Add Connection" propose qemu://session. It is not broken enough for me to invest time in fixing it. It is just a bit unconfortable to have to explain to other people how to workaround this (quite unnecessary) virt-manager limitation.

(In reply to Marc-Andre Lureau from comment #9)
> It mostly works for me, as long as I do simple things (create a VM,
> start/stop, no network changes). So it would be nice if this would be easier
> to setup. For instance, have "Add Connection" propose qemu://session. It is
> not broken enough for me to invest time in fixing it. It is just a bit
> unconfortable to have to explain to other people how to workaround this
> (quite unnecessary) virt-manager limitation.

Oh, I forgot we talked about this before :)

There is reasoning behind it: the differences between session and system are simultaneously huge and subtle. virt-manager mostly works for session, yes. but if someone is expecting 'normal' virt-manager VM behavior, suddenly things are different: networking, various root requiring device options, 'where all my pre-existing vms (that are actually on qemu:///system), etc. We've already had quite smart people complaining about each of those things, and that was with them explictly opting in by passing qemu:///session on the command line. Sticking it in the UI adds an extra element of truly clueless people selecting it without knowing the repercussions and hey why can't my VMs do what your VMs do, or bug reports that get 20 comments deep before I realize they are using session.

That said, I guess if we added a 'Use session instance' checkbox to the 'add connection' dialog, only visible if hv == qemu, that when selected added a little warning box to the dialog concisely saying 'some things won't work, limited networking mode' then that's actually more helpful then the current state since people will be on the look out for caveats. Reopening

that sounds reasonable to me too.

This is upstream now: rather than a checkbox, the hypervisor combo box has an explicit 'qemu user session' option that shows the warning