Bug 782814 - Don't use default VNC port 5900 -- collides with remote desktop tools
Summary: Don't use default VNC port 5900 -- collides with remote desktop tools
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Kletzander
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-18 15:17 UTC by Kamil Páral
Modified: 2013-09-03 08:18 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-02 16:28:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kamil Páral 2012-01-18 15:17:37 UTC
Description of problem:
libvirt should not use default VNC port 5900 for its virtual machines. It should use a completely different range of ports (e.g. start at 6900). Current behavior causes too many problems with current remote desktop solutions. E.g. vino-server integrated into Gnome uses port 5900 by default. If it is started (or restarted) after some VM is started, it fails to bind to the port and the user can't connect to his/her machine.

A lot of bugs are related to this bad design choice:
https://bugzilla.redhat.com/show_bug.cgi?id=725679
https://bugzilla.redhat.com/show_bug.cgi?id=772290

To be clear, I do not suggest to implement some configuration option to change the default VNC start port (like in bug 772290). That is useless for non-technical users, they won't google for their issues and then edit configuration files, they just know their remote desktop is broken. I suggest to change the *default* setting from 5900 to any other port number.

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

How reproducible:
always

Steps to Reproduce:
1. start some VM, it binds to port 5900
2. start vino-server, observe it fails to bind to 5900 (obviously)
3. observe that you can't connect with vnc viewer
4. user is angry, software sucks

Comment 1 Dave Allan 2012-01-18 15:53:45 UTC

*** This bug has been marked as a duplicate of bug 772290 ***

Comment 2 Kamil Páral 2012-01-18 16:15:38 UTC
I kindly request that you don't make this a duplicate. As I stated in the description, I don't ask to have manually configurable option for this (as in bug 772290), I ask you to change the default. That is a separate issue (that would also solve bug 772290 as some others as a side effect, yes) and it probably requires much less work.

Comment 3 Dave Allan 2012-01-18 16:45:08 UTC
Fair enough and sorry for not reading your BZ more closely.

Comment 4 Daniel Berrangé 2012-01-19 11:27:06 UTC
Changing the default port number is a significant change in behaviour of libvirt, that may well not be desirable for existing deployments. So any change in default port range, *must* be accompanied by the ability to make the port range configurable, to allow users to revert to the old port range.

Thus, from an implementation POV, I do consider this bug to be a duplicate of bug 772290

*** This bug has been marked as a duplicate of bug 772290 ***

Comment 5 Kamil Páral 2012-08-29 13:04:40 UTC
Bug 772290 is now solved and the port range is configurable. But the default start port hasn't been changed yet, and according to bug 772290 comment 13, it's not even the purpose of that bug. So I'm reopening this one again to track the issue of changing the default port.

Comment 6 Cole Robinson 2013-08-30 22:32:19 UTC
Really, are we going to ever change the default here? The actual number of complaints I've seen about this over the years have been tiny, and I guarantee changing the default will generate its own set of complaints.

Libvirt tries to be a good citizen by checking port collisions before assigning a port number to a VM, so if vino etc. is already running we won't conflict with them. And the default port range is now configurable for F19+ so for users that care enough there is a workaround. Coupled with the fact that virt-manager and boxes don't even use VNC by default anymore, I really don't think this is worth the potential fallout of changing.

So my vote is WONTFIX, but I'm interested in what other libvirt devs think

Comment 7 Cole Robinson 2013-08-30 22:35:55 UTC
(In reply to Cole Robinson from comment #6)
> Coupled with the fact
> that virt-manager and boxes don't even use VNC by default anymore, I really
> don't think this is worth the potential fallout of changing.
> 

I guess that point is pretty dumb, since it doesn't matter what is using the port, just that its occupied. But really, I'd wager that for modern distros, there's more libvirt users than vino/vncserver users, so maybe vino needs to be a bit smarter and not just give up if 5900 is occupied.

Comment 8 Jiri Denemark 2013-09-02 08:09:26 UTC
(In reply to Cole Robinson from comment #6)
> So my vote is WONTFIX, but I'm interested in what other libvirt devs think

I agree, anyone can change the port range libvirt will use if the default value doesn't work for them.

Comment 9 Martin Kletzander 2013-09-02 08:16:26 UTC
Either WONTFIX or move it to vino-server.  If somebody uses autostarted VMs he should know what it does.  The same applies for using remote viewers for VMs.  This is a thing that can be solved (for "users" that don't know anything about spice/vnc/ports) only by checking free ports in every program and making the selected port visible (as libvirt does).  If anyone wants to have this configured, than he can (per-VM, or service-wise).

Comment 10 Cole Robinson 2013-09-02 16:28:31 UTC
Okay, closing. If someone wants to try and follow up with vino, etc, I'd recommend filing a bug in bugzilla.gnome.org since that's the best way to get a response

Comment 11 Kamil Páral 2013-09-03 08:18:26 UTC
I don't think it makes sense to adjust the vnc server, vino or any other. All VNC clients connect to port 5900 by default. If you change the server behavior, you're just going to get incompatible with the default setting of all available VNC clients.

We would have to have some kind of service discovery in order to solve this reasonably, which we don't have (or at least I don't know about it).

But you're right that since virt-manager is now going with Spice by default, the possibility of collision is diminished. Furthermore, power users are able to change the libvirt port change, which is also great. This is not completely resolved, but much better than it used to be. Thanks.


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