Bug 749750 - RFE: serialize connection opening (so autostarting qemu + lxc doesn't prompt twice)
Summary: RFE: serialize connection opening (so autostarting qemu + lxc doesn't prompt ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
: 753163 852046 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-28 08:35 UTC by zhpeng
Modified: 2014-07-06 19:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-01 15:46:02 UTC
Embargoed:


Attachments (Terms of Use)
virt manager log (6.19 KB, text/plain)
2011-10-28 08:36 UTC, zhpeng
no flags Details

Description zhpeng 2011-10-28 08:35:53 UTC
Description of problem:
auto-start connect local hyper-visor lxc and qemu, one of them will fail when use a non-root user.

Version-Release number of selected component (if applicable):
virt-manager-0.9.0-7.el6

How reproducible:
always

Steps to Reproduce:
1. login a non-root user like redhat.
2. open virt-manager
3. add 2 localhost connections: lxc and qemu/kvm and click "Autoconnect"
4. close the virt-manager and re-open it. virt-manager will ask you for root password twice, one for qemu/kvm , one for lxc
5. input root password and authenticate.
6. one of the two connections will fail.

debug info:
see attachment.

Actual results:
see above

Expected results:
both lxc and qemu/kvm will connect succeed.

Additional info:

Comment 1 zhpeng 2011-10-28 08:36:58 UTC
Created attachment 530626 [details]
virt manager log

Comment 2 Cole Robinson 2011-12-09 21:43:05 UTC
Not urgent, and given reduced capacity for virt-manager/virtinst, just moving this to the upstream tracker.

Not sure what the cause of this is though, probably needs some digging.

Comment 3 Cole Robinson 2012-01-30 03:02:18 UTC
I think we just need to serialize connection opening, since trying to open a bunch at once doesn't really help any.

Comment 4 Cole Robinson 2012-02-07 21:23:00 UTC
*** Bug 753163 has been marked as a duplicate of this bug. ***

Comment 5 Cole Robinson 2012-10-14 01:01:37 UTC
*** Bug 852046 has been marked as a duplicate of this bug. ***

Comment 6 Jan Pokorný [poki] 2012-10-15 07:06:25 UTC
Arriving here from [bug 852046] observed with Fedora 17, I haven't
encountered an issue with one of the two connections (initiated at
about the same time) failing.

Also it is perfectly reasonable to ask per each connection as the user
may decide not to connect to the particular one.  In order to do it,
however, it must be known which specific connection the current auth.
dialog is for (main point of [bug 852046]).

Comment 7 Cole Robinson 2012-10-19 16:06:40 UTC
> Also it is perfectly reasonable to ask per each connection as the user
> may decide not to connect to the particular one.

It's fine to ask for both connections, but doing it simultaneously doesn't make much sense, because in fact the authentication is allowing access to both. If you want to open both the password is actually only required once. This is just how libvirt uses policykit at the moment.

In order to do it,
> however, it must be known which specific connection the current auth.
> dialog is for (main point of [bug 852046]).

Yeah I can't think of a way to make that happen short of overriding the gnome polkit dialog with our own and finding a way to stick in extra info. The way libvirt and policykit work together means that we can't get any extra info to that dialog.

Comment 8 Jan Pokorný [poki] 2012-10-19 16:17:03 UTC
Understood.  So IIUIC, the solution for now seems to be fire the dialog
just once, covering all the connections.  Definitely better than
needlessly multiple-times, even though the granularity is lacking.

Comment 10 Cole Robinson 2014-02-01 15:46:02 UTC
Upstream now serializes connection opening, so closing


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