RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 999291 - Improve documentation of --attach command line option
Summary: Improve documentation of --attach command line option
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jonathon Jongsma
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 999925 999926
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-21 05:56 UTC by CongDong
Modified: 2015-03-05 13:37 UTC (History)
11 users (show)

Fixed In Version: virt-viewer-0.6.0-2.el7
Doc Type: Bug Fix
Doc Text:
The manpage documentation for the commandline --attach option was difficult to understand. This has been improved.
Clone Of:
: 999292 (view as bug list)
Environment:
Last Closed: 2015-03-05 13:37:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0295 0 normal SHIPPED_LIVE virt-viewer bug fix and enhancement update 2015-03-05 17:33:00 UTC

Description CongDong 2013-08-21 05:56:53 UTC 
Description of problem:
Parameter "--attach", the results are the same whether I add it or not.
And the man page makes me confused.

Version-Release number of selected component (if applicable):
# rpm -qa libvirt virt-viewer
virt-viewer-0.5.7-1.el7.x86_64
libvirt-1.1.1-2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Check the man page : # man virt-viewer
2. Prepare a server with a running guest, configure tcp for libvirt authentication
  Server :
  1)add configurations  in /etc/libvirt/libvirtd.conf

  listen_tls = 0
  listen_tcp = 1
  auth_tcp = "sasl"

  2) add sasl user
  # saslpasswd2 -a libvirt test
  (input your passwd)
  # sasldblistusers2 -f /etc/libvirt/passwd.db
  test.nay.redhat.com: userPassword

  3) uncomment LIBVIRTD_ARGS="--listen" in /etc/sysconfig/libvirtd
  
  4) restart libvirtd


3. On client:
# virt-viewer -a -c qemu+tcp://$ip/system $vm
# virt-viewer -c qemu+tcp://$ip/system $vm

Actual results:
1. -a, --attach
           Use libvirt to directly attach to a local display, instead of making a TCP/UNIX socket
           connection. This avoids the need to authentication with the remote display, if
           authentication with libvirt is already allowed.  This option does not work with remote
           displays.
   As the man pange says: This option does not work with remote displays.
   But if the option can only be used to the local guest, I think it's same with "virt-viewer $vm".
   And it's better to add an example here.

3. The results of two commands are same. An authentication required dialog will popup.

Expected results:
1. The man page should be understand more easily.
2. virt-viewer can connect the guest directly with option '-a'. The authentication required dialog shouldn't popup

Additional info:
Comment 2 Christophe Fergeau 2013-11-04 11:12:06 UTC 
(In reply to CongDong from comment #0)

> 
> Expected results:
> 1. The man page should be understand more easily.
> 2. virt-viewer can connect the guest directly with option '-a'. The
> authentication required dialog shouldn't popup


Bug #999292 addresses 2), I'm retitling this bug to make it more explicit that it's about improving --attach documentation
Comment 3 Marc-Andre Lureau 2013-12-10 23:06:39 UTC 
Daniel, you are probably best placed to write some doc about this option. 1) I don't know what it is, 2) I am not native english 3) you can just commit that upstream right away, you are maintainer :)
Comment 5 Daniel Berrangé 2014-01-29 16:27:16 UTC 
https://www.redhat.com/archives/virt-tools-list/2014-January/msg00234.html
Comment 7 Jonathon Jongsma 2014-07-10 02:34:49 UTC 
fixed by rebase to 0.6.0
Comment 9 CongDong 2014-07-23 02:35:30 UTC 
VERIFY with: virt-viewer-0.6.0-1.el7.x86_64

Steps are same with description.

Result:
step1, man page for option "attach" is not updated.

Step3, The results of two commands are same. An authentication required dialog will popup.

As the result, the problem is still there, so set ASSIGNED.
Comment 10 Jonathon Jongsma 2014-08-04 17:26:11 UTC 
Apparently this commit was not in 0.6.0 after all.  I'll make a new build with this patch soon.
Comment 12 zhoujunqin 2014-08-06 08:22:58 UTC 
Hi Jonathon Jongsma,
when i try to verify this issue with package:
virt-viewer-0.6.0-3.el7.x86_64
i met the following problems, please help have a look, thanks.

1. manpage check
# man virt-viewer
       -a, --attach
           Instead of making a direct TCP/UNIX socket connection to the remote display, ask libvirt to
           provide a pre-connected socket for the display. This avoids the need to authenticate with
           the remote display server directly. This option will only work when connecting to a guest
           that is running on the same host as the virt-viewer program. If attaching to the guest via
           libvirt fails, virt-viewer will automatically fallback to trying a regular direct TCP/UNIX
           socket connection.

I think string "fallback to trying" may has syntax error, should be "fallback to try".

2. function check for "-a" option
  Prepare a host with a running guest, configure tcp for libvirt authentication
  1)add configurations in /etc/libvirt/libvirtd.conf

  listen_tls = 0
  listen_tcp = 1
  auth_tcp = "sasl"

  2) add sasl user
  # saslpasswd2 -a libvirt test
  (input your passwd)
  # sasldblistusers2 -f /etc/libvirt/passwd.db
  test.nay.redhat.com: userPassword

  3) uncomment LIBVIRTD_ARGS="--listen" in /etc/sysconfig/libvirtd
  
  4) restart libvirtd

  5) As the manual page said:" This option will only work when connecting to a guest that is running on the same host as the virt-viewer program."

# virt-viewer -a -c qemu+tcp://$ip/system $vm
# virt-viewer -c qemu+tcp://$ip/system $vm

The results of two commands are same. An authentication required dialog will popup.

so please help check whether my step is right or not, if not, please give me some suggestion to verify it, thanks.
Comment 13 Jonathon Jongsma 2014-08-06 14:21:23 UTC 
(In reply to zhoujunqin from comment #12)
> Hi Jonathon Jongsma,
> when i try to verify this issue with package:
> virt-viewer-0.6.0-3.el7.x86_64
> i met the following problems, please help have a look, thanks.
> 
> 1. manpage check
> # man virt-viewer
>        -a, --attach
>            Instead of making a direct TCP/UNIX socket connection to the
> remote display, ask libvirt to
>            provide a pre-connected socket for the display. This avoids the
> need to authenticate with
>            the remote display server directly. This option will only work
> when connecting to a guest
>            that is running on the same host as the virt-viewer program. If
> attaching to the guest via
>            libvirt fails, virt-viewer will automatically fallback to trying
> a regular direct TCP/UNIX
>            socket connection.
> 
> I think string "fallback to trying" may has syntax error, should be
> "fallback to try".

In this case, I think 'trying' is fine.

> 
> 2. function check for "-a" option
>   Prepare a host with a running guest, configure tcp for libvirt
> authentication
>   1)add configurations in /etc/libvirt/libvirtd.conf
> 
>   listen_tls = 0
>   listen_tcp = 1
>   auth_tcp = "sasl"
> 
>   2) add sasl user
>   # saslpasswd2 -a libvirt test
>   (input your passwd)
>   # sasldblistusers2 -f /etc/libvirt/passwd.db
>   test.nay.redhat.com: userPassword
> 
>   3) uncomment LIBVIRTD_ARGS="--listen" in /etc/sysconfig/libvirtd
>   
>   4) restart libvirtd
> 
>   5) As the manual page said:" This option will only work when connecting to
> a guest that is running on the same host as the virt-viewer program."
> 
> # virt-viewer -a -c qemu+tcp://$ip/system $vm
> # virt-viewer -c qemu+tcp://$ip/system $vm
> 
> The results of two commands are same. An authentication required dialog will
> popup.
> 
> so please help check whether my step is right or not, if not, please give me
> some suggestion to verify it, thanks.


This bug is only about the documentation. So as long as the documentation issue is fixed, the bug should be closed. If the functionality itself does not work as expected, you should open a new bug.  But the documentation suggests that it only works if virt-viewer and the guest are on the same system. Is $ip the local machine? Perhaps you should try with qemu:///system rather than qemu+tcp://$ip/system? I'm afraid that I don't have a lot of knowledge about this feature.
Comment 14 Jonathon Jongsma 2014-08-06 14:32:38 UTC 
> This bug is only about the documentation. So as long as the documentation
> issue is fixed, the bug should be closed. If the functionality itself does
> not work as expected, you should open a new bug.  

Perhaps I wrote this too quickly. I guess the initial report was indeed about confusion with whether the feature actually worked or not, though the title was later changed to only mention the documentation.  Daniel, would you be able to provide some steps for testing whether this feature actually works properly or not?
Comment 15 CongDong 2014-08-20 03:26:30 UTC 
As result in comment 12 setp 1 and comment 13, the man page is already updated.
So VERIFY this.
Comment 16 CongDong 2014-08-20 05:09:06 UTC 
Hi, 
Could you help to provide the steps for testing this feature?
If it doesn't work, I will think about to file a new one.
Comment 17 tingting zheng 2015-01-19 08:01:39 UTC 
Tested with:
virt-viewer-0.6.0-12.el7.x86_64

Test whether virt-viewer --attach works.
1.Test using qemu:///system.
# virt-viewer demo -a 
For vnc guest,the screen is dark and "Connected to graphic server" shows.
For spice guest,the screen is dark and "Connecting to graphic server" shows.

If use virt-viewer demo,the guest console will be launched successfully.

2.Test using qemu+tcp://$ip/system.
On localhost prepare with a running guest, configure tcp for libvirt authentication
  1)add configurations in /etc/libvirt/libvirtd.conf

  listen_tls = 0
  listen_tcp = 1
  auth_tcp = "sasl"

  2) add sasl user
  # saslpasswd2 -a libvirt test
  (input your passwd)
  # sasldblistusers2 -f /etc/libvirt/passwd.db
  test.nay.redhat.com: userPassword

  3) uncomment LIBVIRTD_ARGS="--listen" in /etc/sysconfig/libvirtd
  
  4) restart libvirtd

# virt-viewer qemu+tcp://localhost/system demo -a 
# virt-viewer qemu+tcp://localhost/system demo 

The above command acts the same,both authtication box pop out and you need to input user/password to launch the console.

Hi,Daniel
    Would you pls help check whether the above steps are right for testing --attach option,thanks very much.
Comment 18 Daniel Berrangé 2015-01-19 09:44:11 UTC 
The attach flag does not do anything when you connect to libvirt over TCP. It only has effect when using a UNIX socket connection.
Comment 19 tingting zheng 2015-02-05 09:08:43 UTC 
(In reply to Daniel Berrange from comment #18)
> The attach flag does not do anything when you connect to libvirt over TCP.
> It only has effect when using a UNIX socket connection.

If it only has effect with UNIX socket connection,why from virt-viewer manual,it says that affect TCP/UNIX socket connection.
  -a, --attach
           Instead of making a direct TCP/UNIX socket connection to the remote display, ask libvirt to provide a pre-connected socket for the display. 

I tried unix connnection by the below steps:
1. add auth_unix_rw="sasl" in the /etc/libvirt/libvirtd.conf

2.add sasl user
# saslpasswd2 -a libvirt test
(input your passwd)

3.Restart libvirtd server.
# service libvirtd restart

4.Prepare a running guest.
# virsh -c qemu+unix:///system list 
Please enter your authentication name: test
Please enter your password: 
 Id    Name                           State
----------------------------------------------------
 2     demo                           running

5.Use virt-viewer to launch guest console.
5.1 # virt-viewer -c qemu+unix:///system demo -->No password needed,guest console will be launched successfully,and direct TCP connection shows in debug info.

 # virt-viewer -c qemu+unix:///system demo --debug
(virt-viewer:26728): virt-viewer-DEBUG: Guest graphics address is 127.0.0.1:5900
(virt-viewer:26728): virt-viewer-DEBUG: Set connect info: localhost,127.0.0.1,5900,-1,unix,(null),(null),0
(virt-viewer:26728): virt-viewer-DEBUG: Error operation forbidden: read only access prevents virDomainOpenGraphics
(virt-viewer:26728): virt-viewer-DEBUG: After open connection callback fd=-1
(virt-viewer:26728): virt-viewer-DEBUG: Opening direct TCP connection to display at 127.0.0.1:5900:-1
(virt-viewer:26728): virt-viewer-DEBUG: New spice channel 0xd90b60 SpiceMainChannel 0


5.2 # virt-viewer -c qemu+unix:///system demo -a -->authtication box pop out,after input the user/password,virt-viewer coredump.

# virt-viewer -c qemu+unix:///system demo -a --debug

** (virt-viewer:26708): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-cRPYh0BqYC: Connection refused
(virt-viewer:26708): virt-viewer-DEBUG: fullscreen display 0: 0
(virt-viewer:26708): virt-viewer-DEBUG: connecting ...
(virt-viewer:26708): virt-viewer-DEBUG: Opening connection to libvirt with URI qemu+unix:///system
(virt-viewer:26708): virt-viewer-DEBUG: Add handle 6 1 0x7bc6d0
(virt-viewer:26708): virt-viewer-DEBUG: Got libvirt credential request for 2 credential(s)
(virt-viewer:26708): virt-viewer-DEBUG: Got 'test' 4 2
(virt-viewer:26708): virt-viewer-DEBUG: Got 'redhat' 6 5
(virt-viewer:26708): virt-viewer-DEBUG: Return 0
(virt-viewer:26708): virt-viewer-DEBUG: initial connect
(virt-viewer:26708): virt-viewer-DEBUG: notebook show status 0x6c7180
(virt-viewer:26708): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to bf6d8713-b158-4bf2-beeb-eebb5cad1f89
(virt-viewer:26708): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback
(virt-viewer:26708): virt-viewer-DEBUG: notebook show status 0x6c7180
(virt-viewer:26708): virt-viewer-DEBUG: Guest demo is running, determining display
(virt-viewer:26708): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0
(virt-viewer:26708): virt-viewer-DEBUG: Guest demo has a spice display
(virt-viewer:26708): virt-viewer-DEBUG: Guest graphics address is 127.0.0.1:5900
(virt-viewer:26708): virt-viewer-DEBUG: Set connect info: localhost,127.0.0.1,5900,-1,unix,(null),(null),0
(virt-viewer:26708): virt-viewer-DEBUG: Remove handle 1 6
Segmentation fault (core dumped)

(gdb) where
#0  0x00007f4caaa2ea42 in virFileClose () from /lib64/libvirt.so.0
#1  0x00007f4caab67ff6 in virNetMessageFree () from /lib64/libvirt.so.0
#2  0x00007f4caab5e97a in virNetClientProgramCall () from /lib64/libvirt.so.0
#3  0x00007f4caab36482 in callFull.isra.2 () from /lib64/libvirt.so.0
#4  0x00007f4caab3945f in remoteDomainOpenGraphics () from /lib64/libvirt.so.0
#5  0x00007f4caab1ef84 in virDomainOpenGraphics () from /lib64/libvirt.so.0
#6  0x0000000000426d30 in virt_viewer_open_connection (self=<optimized out>, fd=0x7fffd7e3c5fc)
    at virt-viewer.c:497
#7  0x000000000041389c in virt_viewer_app_default_activate (self=0x15dd140, error=0x7fffd7e3c798)
    at virt-viewer-app.c:1142
#8  0x000000000041536b in virt_viewer_app_activate (self=0x15dd140, error=0x7fffd7e3c798)
    at virt-viewer-app.c:1209
#9  0x00000000004271d2 in virt_viewer_initial_connect (app=0x15dd140, error=0x7fffd7e3c798) at virt-viewer.c:635
#10 0x0000000000426a70 in virt_viewer_connect (app=app@entry=0x15dd140) at virt-viewer.c:796
#11 0x0000000000426c8d in virt_viewer_start (app=0x15dd140) at virt-viewer.c:834
#12 0x0000000000414116 in virt_viewer_app_start (self=0x15dd140) at virt-viewer-app.c:1700
#13 0x000000000040fbc4 in main (argc=1, argv=0x7fffd7e3caf8) at virt-viewer-main.c:113
(gdb) quit

I think for UNIX socket connection,the --attach option didn't work well,would you pls help to check whether the above steps is right to test --attach option and need I file a new bug about it,thanks.
Comment 21 tingting zheng 2015-02-26 09:27:10 UTC 
For comment 19,file new bug 1196552.
Comment 23 errata-xmlrpc 2015-03-05 13:37:46 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0295.html
Note You need to log in before you can comment on or make changes to this bug.