Bug 1293878 - The vnc guest name shows incorrect when connected by remote-viewer a connection file
The vnc guest name shows incorrect when connected by remote-viewer a connecti...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.8
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Virt Viewer Maint
Virtualization Bugs
:
Depends On:
Blocks: 1293879
  Show dependency treegraph
 
Reported: 2015-12-23 05:45 EST by mxie@redhat.com
Modified: 2016-05-10 17:20 EDT (History)
8 users (show)

See Also:
Fixed In Version: virt-viewer-2.0-10.el6
Doc Type: Bug Fix
Doc Text:
Cause: virt-viewer didn't try to set the display name when connecting to VNC guest. Consequence: The name of the VNC guest was not set. Fix: Set the guest name when connecting to a VNC guest. Result: Guest name is showed properly.
Story Points: ---
Clone Of:
: 1293879 (view as bug list)
Environment:
Last Closed: 2016-05-10 17:20:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot1 (499.10 KB, image/png)
2015-12-23 05:45 EST, mxie@redhat.com
no flags Details
screenshot2 (1.25 MB, image/png)
2015-12-23 05:46 EST, mxie@redhat.com
no flags Details

  None (edit)
Description mxie@redhat.com 2015-12-23 05:45:03 EST
Created attachment 1108933 [details]
screenshot1

Description of problem:
The vnc guest name shows incorrect when connected by remote-viewer a connection file

Version-Release number of selected component (if applicable):
virt-viewer-2.0-9.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Prepare a vnc guest name "rhel6.7" and edit xml as below
 <graphics type='vnc' port='5901' autoport='no' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
 </graphics>

2.Start the vnc guest
#virsh start rhel6.7

3.Create an ini file,name "test.ini", format like following:
[virt-viewer]
type=vnc
host=localhost
port=5901

4.remote-viewer the connection file "test.ini" to connect the vnc guest 
#remote viewer test.ini

Actual results:
The vnc guest could be connected but guest's name shows the connection file's name, pls refer to screenshot1

Expected results:
The vnc guest could be connected and guest's name shows correct 

Addtional info:
The spice guest could show name correctly when connected by remote-viewer an connection file

Steps as below:
1.Prepare a spice guest name "2OS" and edit xml as below
 <graphics type='spice' port='5900' autoport='no' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
 </graphics>

2.Start the spice guest
#virsh start 2OS

3.Create an ini file,name "test.ini", format like following:
[virt-viewer]
type=spice
host=localhost
port=5900

4.remote-viewer the connection file "test.ini" to connect the spice guest and the spice guest shows name correctly, pls refer to screenshot2
#remote viewer test.ini
Comment 1 mxie@redhat.com 2015-12-23 05:46 EST
Created attachment 1108934 [details]
screenshot2
Comment 3 Fabiano Fidêncio 2015-12-23 06:00:01 EST
Okay. It's already fixed upstream by this commit: 772698a8a6e34c0b5051a3519f9284313426c1ca (Set guest name when using VNC)
Also, for completeness, we most likely would like to have this commit as well: fc2add5827c359ced244c4e0a9cb36d24c24ee83 (Set uuid when using VNC)
Comment 5 mxie@redhat.com 2016-01-04 00:56:57 EST
I can reproduce the bug with build:
virt-viewer-2.0-9.el6.x86_64

Try to verify this bug with build:
virt-viewer-2.0-10.el6.x86_64

Steps to Reproduce:
1.Prepare a vnc guest name "rhel6.7" and edit xml as below
 <graphics type='vnc' port='5901' autoport='no' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
 </graphics>

2.Start the vnc guest
#virsh start rhel6.7

3.Create an ini file,name "test.ini", format like following:
[virt-viewer]
type=vnc
host=localhost
port=5901

4.remote-viewer the connection file "test.ini" to connect the vnc guest 
#remote viewer test.ini

Result now:
The vnc guest could be connected and guest's name shows QEMU(rhel6.7)

Hi Fidencio,

Whether the guest's name shows QEMU(rhel6.7) instead of "rhel6.7" could be accepted?
Comment 6 Fabiano Fidêncio 2016-01-04 03:12:12 EST
(In reply to mxie@redhat.com from comment #5)
> I can reproduce the bug with build:
> virt-viewer-2.0-9.el6.x86_64
> 
> Try to verify this bug with build:
> virt-viewer-2.0-10.el6.x86_64
> 
> Steps to Reproduce:
> 1.Prepare a vnc guest name "rhel6.7" and edit xml as below
>  <graphics type='vnc' port='5901' autoport='no' listen='127.0.0.1'>
>       <listen type='address' address='127.0.0.1'/>
>  </graphics>
> 
> 2.Start the vnc guest
> #virsh start rhel6.7
> 
> 3.Create an ini file,name "test.ini", format like following:
> [virt-viewer]
> type=vnc
> host=localhost
> port=5901
> 
> 4.remote-viewer the connection file "test.ini" to connect the vnc guest 
> #remote viewer test.ini
> 
> Result now:
> The vnc guest could be connected and guest's name shows QEMU(rhel6.7)
> 
> Hi Fidencio,
> 
> Whether the guest's name shows QEMU(rhel6.7) instead of "rhel6.7" could be
> accepted?

This is what's provided by gtk-vnc widget. If, for some reason, you believe that having "rhel6.7" instead of "QEMU(rhel6.7)" for vnc would be better, please, open a bug on gtk-vnc and set as dependency of this one. (TBH, I don't think we would have the bug approved for 6 cycle, maybe for the 7 one it's okay ...)
Comment 7 mxie@redhat.com 2016-01-04 04:13:04 EST
Thanks for Fidencio's quick reply 

According to commnet6 and Fidencio's reply, although the guest's name shows QEMU(rhel6.7) instead of "rhel6.7" is not very perfect, we all could understand the meaning of guest's name which means qemu start the guest "rhel6.7", so move the bug from ON_QA to VERIFIED.
Comment 9 errata-xmlrpc 2016-05-10 17:20:51 EDT
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-2016-0832.html

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