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 772290 - RFE: Configurable VNC start port or ability to exclude use of specific ports
Summary: RFE: Configurable VNC start port or ability to exclude use of specific ports
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-06 17:16 UTC by Alex Williamson
Modified: 2013-02-21 07:07 UTC (History)
19 users (show)

Fixed In Version: libvirt-0.10.2-0rc1.el6
Doc Type: Enhancement
Doc Text:
Feature: Starting port for SPICE/VNC port allocations was made configurable. Reason: By default the automatically allocated ports for SPICE/VNC started on port 5900 which wasn't always wanted. Result (if any): Guests can have SPICE/VNC on other ports than 5900 without explicitly specifying them, thus keeping the automatic allocation in place.
Clone Of:
Environment:
Last Closed: 2013-02-21 07:07:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Alex Williamson 2012-01-06 17:16:39 UTC 
Description of problem:
I have a desktop system with remote desktop enabled.  This makes use of the default vnc port 5900.  If I have libvirt guests configured to autostart, there's a race between the first guest started and remote desktop to grab that port.

Version-Release number of selected component (if applicable):
libvirt-0.9.6-2.fc16.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create the above setup, sometimes virt-viewer can't get to the guest console
2.
3.
  
Actual results:
Races

Expected results:
A mechanism to tell libvirt to exclude specific ports

Additional info:
My guest is configured with:

type='vnc' port='-1' autoport='yes'

Yes, I could specify a port for each guest, but other than not using port 5900, I don't really care where they go and have no interesting in managing guest VNC ports.

Yes, I could change my remote desktop to use a different port, but I shouldn't have to.  That creates a burden on configuring the server and the clients to accommodate a service that can more easily use arbitrary ports.

Ideally I'd like some global configuration file where I can specify either excluded ports or a base and range of ports available to use.
Comment 1 Dave Allan 2012-01-06 19:34:47 UTC 
It wouldn't be a big deal to extend the <listen> element to supply a list of ports to exclude, although maybe there's a better way to do it that I'm not thinking of atm.
Comment 2 Dave Allan 2012-01-18 15:53:45 UTC 
*** Bug 782814 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Berrangé 2012-01-19 11:24:36 UTC 
I don't think that the <listen> element should have a range of ports - apps would just have to end up specifying the same range over & over in every guest. This is something that should be configurable in the global qemu.conf file.
Comment 4 Daniel Berrangé 2012-01-19 11:27:06 UTC 
*** Bug 782814 has been marked as a duplicate of this bug. ***
Comment 5 Kamil Páral 2012-01-19 13:19:03 UTC 
Bug 782814, which has been marked as a duplicate of this bug, asks libvirt developers to change the default port 5900 to some other port. That would also solve some other bugs. Read the bug description for more details.
Comment 6 Dave Allan 2012-05-16 17:07:21 UTC 
(In reply to comment #3)
> I don't think that the <listen> element should have a range of ports - apps
> would just have to end up specifying the same range over & over in every guest.
> This is something that should be configurable in the global qemu.conf file.

I've pretty much only heard people asking for XML; I'm fine with a global config option, but I think we should provide both.
Comment 7 Martin Kletzander 2012-07-18 15:12:50 UTC 
Patches are waiting for review upstream.
Comment 8 Laine Stump 2012-08-17 17:29:13 UTC 
For reference (since someone asked me about this issue) this is the latest rev of the patches I see upstream:

https://www.redhat.com/archives/libvir-list/2012-August/msg00807.html
Comment 9 Martin Kletzander 2012-08-20 06:46:15 UTC 
Actually, only one patch is missing review (last minor changes to the patch were added after Daniel's proposal):

https://www.redhat.com/archives/libvir-list/2012-August/msg00930.html
Comment 10 Martin Kletzander 2012-08-27 08:42:01 UTC 
Default start port for both VNC and SPICE is now configurable in /etc/libvirt/qemu.conf, thus moving to POST (based on these commits):

commit a14b4aea512d6c3a42af56207a65ef10ac4a12a1
Author: Martin Kletzander <mkletzan>
Date:   Mon Jun 18 09:58:31 2012 +0200

    qemu: Unify port-wise SPICE and VNC behavior

commit 29226beefe2ae9698443b5ebe9d94df64c94c923
Author: Martin Kletzander <mkletzan>
Date:   Mon Jun 18 10:22:07 2012 +0200

    qemu: configurable remote display port boundaries
Comment 12 Kamil Páral 2012-08-29 12:39:39 UTC 
Has the default VNC port changed?
Comment 13 Martin Kletzander 2012-08-29 12:43:15 UTC 
Not yet. It most probably will, but because this is very sensitive issue for some people, it hasn't happened yet. However that shouldn't be a problem for this bug to be solved.
Comment 14 Kamil Páral 2012-08-29 13:02:23 UTC 
Thanks. In that case I'm reopening bug 782814.
Comment 20 zhe peng 2012-09-19 08:21:09 UTC 
So sorry Martin, it works now, maybe my pc have some problem, thanks.
verify with build: libvirt-0.10.2-0rc1.el6.x86_64

step:
  1. edit /etc/libvirt/qemu.conf
  ....
remote_display_port_min = 5904
remote_display_port_max = 65535
....
and start the guest with:
.....
<graphics type='vnc' port='-1' autoport='yes'/>
.....
when guest started, check vnc port:
#virsh dumpxml $guest
.......
<graphics type='spice' port='5904' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>

check ports:
 #netstat -apn| grep 590
 tcp        0      0 127.0.0.1:5904              0.0.0.0:*                   LISTEN      17849/qemu-kvm      
tcp        0      0 0.0.0.0:5905                0.0.0.0:*                   LISTEN      17988/qemu-kvm      
tcp        0      0 :::5901                     :::*                        LISTEN      3175/vino-server    

the start port become to 5904. verification passed.
Comment 21 errata-xmlrpc 2013-02-21 07:07:38 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
Note You need to log in before you can comment on or make changes to this bug.