This error is coming from polkit as explained here:

https://www.redhat.com/archives/libvir-list/2012-December/msg00976.html

If your login session didn't autolaunch a polkit agent (which happens over ssh -X), I think the only option here is for virsh to register its own agent to make this work in all cases.

pkcheck has a --use-internal-agent option which launches a text user/password prompt, but that doesn't help us since it's being run by the daemon, not the client process.

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

I think this is more serious than a mere RFE.

This makes virsh totally unusable from a text console in the default configuration.

How about "sudo virsh ..." ? I think most people do that (or, like me, just run it from a root shell).

Hm.  I could have sworn I tried sudo virsh and still couldn't get it to work.  But I can't seem to reproduce the problem now.

(In reply to David Gibson from comment #3)
> I think this is more serious than a mere RFE.
> 
> This makes virsh totally unusable from a text console in the default
> configuration.

I agree with David here. I just got a couple of reports (from seasoned Linux admins) asking what to do about these kind of issues (to run virsh to connect to remote machines as an unprivileged user). If it's this much of a hassle for regular admins, I can imagine an unsuspecting, casual linux administrator going "ugh"

To add an extra case on where running `sudo virsh ...` is not always possible is when a user is running vagrant for example. Vagrant does provide a libvirt backend driver, and vagrant is used to run as a non-privileged user.

On a CI infrastructure we can imagine Jenkins running test on a vagrant-libvirt machine, but since the host wouldn't have any X it will result in the same error initially mentionned.

(In reply to Yanis Guenane from comment #7)
> To add an extra case on where running `sudo virsh ...` is not always
> possible is when a user is running vagrant for example. Vagrant does provide
> a libvirt backend driver, and vagrant is used to run as a non-privileged
> user.
> 
> On a CI infrastructure we can imagine Jenkins running test on a
> vagrant-libvirt machine, but since the host wouldn't have any X it will
> result in the same error initially mentionned.

This bug is only about an interactive password polkit password prompt, which wouldn't really make sense in a test suite. To do something like what you propose you should probably use a polkit override, so the unprivileged vagrant user can access the system libvirt instance without auth.

What about shipping something like this below at least in %doc, with comments about dropping it in /etc/polkit-1/rules.d/ ? It would allow trusted non-root users to do `--connect qemu+ssh`, covering Kashyap's cited use case.

```
polkit.addRule(function(action, subject) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        var now = new Date();
        polkit.log("now=" + now)
        if ((action.id == "org.libvirt.unix.manage" || action.id == "org.libvirt.unix.monitor") && subject.isInGroup("virt-adm")) {
        return polkit.Result.YES;
        }
        return null;
        });
```

It seems what is desired for this bug is fixed with the changes Cole made for bug 957300.  Before I dupe it to that - I wanted to make sure you agree.

Not sure I can say if the fix for the other bug is the right one.

My main concern when filing the bug was that the error message
was not actionable (note the Summary of this bug has changed since
I filed it).

I've posted some patches upstream which will address the concerns

(now at v3): 

  http://www.redhat.com/archives/libvir-list/2016-February/msg00657.html


Patch 1 of the series adjusts the error message to be a bit more clear about which "agent" is causing the issue

Patches 2 & 3 add support for a text based authentication agent.

Patches w/ some slight adjustments (all listed within the reviews of the above link) have been pushed upstream. This will appear in what should be libvirt 1.3.3 (the March 2016 release).

v1.3.2-21-gea48397

commit ea48397b016683933104c5ce059a33443a79cdbb
Author: John Ferlan <jferlan>
Date:   Tue Feb 9 14:08:42 2016 -0500

    virsh: Add support for text based polkit authentication

Thanks John, though I think it's fine to just close as UPSTREAM once it's committed

Hi, John, I tested the patch with libvirt-1.3.3-1.fc24_v1.3.2_167_g885e34c.x86_64 , and only the error message becomes more clear. It is expected to show password prompt? Could you help me to check is there anything wrong with my test steps? Thanks a lot.

My test steps are as follows:
1.Add a non-root user and set password for the user:
 #useradd test
 #passwd test 

2.Login with test user using "ssh -X":
 #ssh -X test.0.1

3.Run "virsh -c qemu:///system" with test user:
 $virsh -c qemu:///system
2016-03-15 05:30:09.852+0000: 6141: info : libvirt version: 1.3.3, package: 1.fc24_v1.3.2_167_g885e34c (Unknown, 2016-03-15-07:03:36, localhost.localdomain)
2016-03-15 05:30:09.852+0000: 6141: info : hostname: localhost.localdomain
2016-03-15 05:30:09.852+0000: 6141: warning : virFileClose:96 : Tried to close invalid fd 7
error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'

4.Login using "ssh test.0.1" also got the same error message.

My testing usually occurs on my laptop where I initially login under my account.

Running virsh -c qemu:///system list --all there causes the GUI version of the polkit tools to kick in; however, if I simply ssh jferlan@localhost then run the same command I see the following:

$ virsh -c qemu:///system version
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: John Ferlan (jferlan)
Password: 
==== AUTHENTICATION COMPLETE ===
Compiled against library: libvirt 1.3.3
Using library: libvirt 1.3.3
Using API: QEMU 1.3.3
Running hypervisor: QEMU 2.4.1


I have no difference if I use ssh -X using this mechanism.

I can also login under my account, su to root, and ssh to my local account and get the same results.

Another QE and I also met the same problem mentioned in comment 15 on v1.3.4-169-g1617134

and i find the problem seems come from commit 0b36b0e9, and the problem is:

    agent->cmd = cmd;                    <-
    cmd = NULL;                          <--- give cmd ptr to agent->cmd here

    virCommandAddArgFormat(cmd, "%lld", (long long int) getpid());  <----but still use cmd ptr here which is NULL now.

    ... 
    if (virCommandRunAsync(cmd, NULL) < 0)  <----- still use cmd, get failure
        goto error;

And i had a try to fix it and found it works after apply my patch:

$ ssh lhaung@localhost -X
lhaung@localhost's password: 
Last login: Mon May  9 14:25:48 2016 from localhost
[lhaung@lhuang ~]$ virsh -c qemu:///system
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: root
Password: 
==== AUTHENTICATION COMPLETE ===
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh #

Commit 0b36b0e9 does look wrong.  Perhaps the subsequent lines
should be using agent->cmd instead?

Yes, that commit is totally wrong. In addition virPolkitAgentDestroy already clears the passed virCommand pointer so a simple rearrange of the code would have helped at that point. I'll post a patch to fix that.

commit 4e8b81e5c4bbc5b26032e61a8006cda0b393ef8b
Author: Peter Krempa <pkrempa>
Date:   Mon May 9 11:02:51 2016 +0200

    util: polkit: Fix polkit agent startup
    
    Commit 0b36b0e9 broke polkit agent startup when attempting to fix a
    coverity warning. Refactor it properly so that we don't need the 'cmd'
    intermediate variable.