Bug 1332446

Summary: "virsh domdisplay" recognizes 0.0.0.0 as localhost
Product: Red Hat Enterprise Linux 7 Reporter: Fangge Jin <fjin>
Component: libvirtAssignee: Pavel Hrdina <phrdina>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: dyuan, mzhan, phrdina, pkrempa, rbalakri, yafu, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-2.0.0-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 18:44:07 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 Fangge Jin 2016-05-03 08:38:02 UTC
Description of problem:
Set spice listen address to 0.0.0.0
# virsh domdisplay rhel7.2-1030
spice://localhost:5900

Version-Release number of selected component:
libvirt-1.3.3-2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. # virsh dumpxml rhel7.2-1030
    <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

2. # virsh start rhel7.2-1030

3. # virsh dumpxml rhel7.2-1030
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

4. # virsh domdisplay rhel7.2-1030
spice://localhost:5900

5. # hostname
hp-dl388g9-02.lab.eng.pek2.redhat.com

Actual results:
As step 4

Expected results:
# virsh domdisplay rhel7.2-1030
spice://0.0.0.0:5900
or
spice://hp-dl388g9-02.lab.eng.pek2.redhat.com:5900

Comment 1 Peter Krempa 2016-05-03 08:53:22 UTC
(In reply to JinFangge from comment #0)
> Description of problem:
> Set spice listen address to 0.0.0.0
> # virsh domdisplay rhel7.2-1030
> spice://localhost:5900

This is correct as long as you are connecting to 'localhost' with virsh. (which is default)

[...]

> 
> 4. # virsh domdisplay rhel7.2-1030

The default libvirt approach is to connect to localhost, so 

> spice://localhost:5900

.. this is basically correct. If you use the URI from the same machine where you started 'virsh' it will work correctly.

> 
> 5. # hostname
> hp-dl388g9-02.lab.eng.pek2.redhat.com
> 
> Actual results:
> As step 4
> 
> Expected results:
> # virsh domdisplay rhel7.2-1030
> spice://0.0.0.0:5900

This is definitely not an expected result. This would not work.

> or

> spice://hp-dl388g9-02.lab.eng.pek2.redhat.com:5900

This is wrong too. The hostname can be different from the uri that was used to connect and thus could not be reachable.


There is still a problem with this code though. if you use virsh -c 'qemu+ssh://some.host/system' domdisplay...

the output will be still spice://localhost:5900 due to a bug in the code.

Comment 3 Pavel Hrdina 2016-06-08 11:59:49 UTC
Upstream commit:

commit 4ddde38e2ddb2849582c3b05a97947f3b7c9b1ee
Author: Pavel Hrdina <phrdina>
Date:   Mon May 30 16:35:17 2016 +0200

    virsh: domdisplay: if listen is 0.0.0.0 or [::] print address from URI

Comment 5 yafu 2016-07-12 06:41:23 UTC
Reproduce with libvirt-1.3.3-2.el7.x86_64.
Test steps:
1. # virsh dumpxml rhel7.3
    <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

2. # virsh start rhel7.3

3. # virsh dumpxml rhel7.3
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

4.#virsh -c qmeu:///system domdisplay rhel7.3 
   spice://localhost:5900

5.#hostname
intel-e31225-16-3.englab.nay.redhat.com

6.#virsh -c qemu+ssh://intel-e31225-16-3.englab.nay.redhat.com/system domdisplay rhel7.3
  spice://localhost:5900

7.#virsh -c qemu+ssh://10.66.144.29/system domdisplay rhel7.3
  spice://localhost:5900


Verified pass with libvirt-2.0.0-2.el7.x86_64.
Test steps:
1.# virsh dumpxml rhel7.3
    ...
    <graphics type='spice' autoport='yes' listen='0::'>
      <listen type='address' address='0::'/>
    </graphics>
    ...

2. #virsh start rhel7.3

3. #virsh dumpxml rhel7.3
    ...
    <graphics type='spice' port='5900' autoport='yes' listen='0::'>
      <listen type='address' address='0::'/>
    </graphics>
    ...

4.#virsh -c qmeu:///system domdisplay rhel7.3 
   spice://localhost:5900

5.#hostname
intel-e31225-16-3.englab.nay.redhat.com

6.#virsh -c qemu+ssh://intel-e31225-16-3.englab.nay.redhat.com/system domdisplay rhel7.3 
  spice://intel-e31225-16-3.englab.nay.redhat.com:5900

7.#virsh -c qemu+ssh://10.66.144.29/system domdisplay rhel7.3
spice://10.66.144.29:5900

8.#virsh -c qemu+ssh://[2620:52:0:4292:a248:1cff:feaa:1594]/system domdisplay rhel7.3
spice://[2620:52:0:4292:a248:1cff:feaa:1594]:5900

9.Start a guest with spice listen type='network':
  #virsh dumpxml rhel7.3-2
  ...
   <graphics type='spice' port='5900' autoport='yes' listen='10.0.1.1'>
      <listen type='network' address='10.0.1.1' network='br1'/>
    </graphics>
  ...

10.#virsh -c qemu+ssh://10.66.144.29/system domdisplay rhel7.3-2
   spice://10.0.1.1:5900

Comment 6 Fangge Jin 2016-09-05 09:18:10 UTC
I set graphic listen address to '0.0.0.0', and start guest. 
# netstat -tunap|grep 590
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      15390/qemu-kvm  

On another host, connect to libvirtd with ipv6 address in URI and get domain display, it returns domain display URI with ipv6 address:
# virsh -c qemu+ssh://[2620:52:0:49c4:2e76:8aff:feb0:e0c4]/system domdisplay rhel7
vnc://[2620:52:0:49c4:2e76:8aff:feb0:e0c4]:0

But actually, guest is not listening on ipv6 address

Comment 7 Pavel Hrdina 2016-09-27 08:56:48 UTC
Hi, this could be probably fixed. Please create a new BZ for the IPv6 issue.

Comment 8 Fangge Jin 2016-09-27 10:26:14 UTC
I file a new bug for the issue in comment 6 
Bug 1379649 - Virsh domdisplay returns IPv6 address while qemu is listening on IPv4

Comment 10 errata-xmlrpc 2016-11-03 18:44:07 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/RHSA-2016-2577.html