Bug 832004

Summary: vncdisplay can't output default ip address for the vnc display
Product: Red Hat Enterprise Linux 6 Reporter: hongming <honzhang>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 6.3CC: acathrow, ajia, dallan, dyasny, dyuan, mzhan, pkrempa, rwu, veillard, ydu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.9.13-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 07:17:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description hongming 2012-06-14 09:28:27 UTC
Description of problem:
vncdisplay can't output default ip address for the vnc display

Version-Release number of selected component (if applicable):
libvirt-0.9.10-21.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.# virsh start rhel6.3
   Domain rhel6.3 started

2.# virsh dumpxml rhel6.3
...
<graphics type='vnc' port='5901' autoport='yes'/>
...

3.# virsh vncdisplay rhel6u31
:1

  
Actual results:
only output the port number for the VNC display.

Expected results:
127.0.0.1:1
Output the default ip address and port.

Additional info:

Comment 2 Alex Jia 2012-06-14 11:03:36 UTC
Michal committed a RFC request about "API to report guest IP address(es)" and committed a patch set recently on libvirt upstream, but patches haven't been ACKed now, it should be helpful for this issue.

https://www.redhat.com/archives/libvir-list/2012-June/msg00220.html

Comment 3 Peter Krempa 2012-06-14 12:07:20 UTC
That API actually won't help much as the relevant address is where the hypervisor is running. The vncdisplay command has the problem that it's only printing the address present in the domain XML that may and may not contain the correct address you have to connect to. The problem with that address is that it might even be unreachable directly from the machine virsh is running on. (Eg. when the listen address is 127.0.0.1, you won't be able to connect to the hypervisor vnc display from remote hosts.)

Comment 4 Dave Allan 2012-06-14 15:03:25 UTC
Regardless of the usefulness of the information provided, I think the output should include the IP address.

Comment 5 Michal Privoznik 2012-06-14 16:08:40 UTC
This is a bit more complex than one could initially think.

vncdisplay command simply dumpx guest XML and do bunch of XPath queries to determine IP address and listen port. However, if there is none defined in the XML, then at the domain startup we take the one defined in qemu.conf. But we cannot store it into domain XML as it will discard future changes to qemu.conf. Therefore we need to make this as transient -> insert into live XML only.

Comment 6 Michal Privoznik 2012-06-27 14:19:34 UTC
Moving to POST:

commit d7f9d827531bc843b7c5aa9d3e8c08738a1de248
Author:     Daniel P. Berrange <berrange>
AuthorDate: Mon Jun 25 12:50:52 2012 +0100
Commit:     Daniel P. Berrange <berrange>
CommitDate: Mon Jun 25 13:05:55 2012 +0100

    Include the default listen address in the live guest XML
    
    If no 'listen' attribute or <listen> element is set in the
    guest XML, the default driver configured listen address is
    used. There is no way to client applications to determine
    what this address is though. When starting the guest, we
    should update the live XML to include this default listen
    address

v0.9.13-rc1-4-gd7f9d82

Comment 9 yanbing du 2012-07-24 08:40:11 UTC
Bug verified with libvirt-0.9.13-3.el6.x86_64.

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 5     rhel6                          running
 6     rhel6-2                        running

# virsh vncdisplay rhel6
127.0.0.1:0

# virsh vncdisplay rhel6-2
127.0.0.1:1

Comment 10 errata-xmlrpc 2013-02-21 07:17:19 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.

http://rhn.redhat.com/errata/RHSA-2013-0276.html