Bug 782814

Summary: Don't use default VNC port 5900 -- collides with remote desktop tools
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: libvirtAssignee: Martin Kletzander <mkletzan>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: alex.williamson, berrange, clalancette, crobinso, dallan, dougsland, itamar, jdenemar, jforbes, laine, libvirt-maint, mkletzan, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-02 12:28:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Kamil Páral 2012-01-18 10:17:37 EST
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:

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):

How reproducible:

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 10:53:45 EST

*** This bug has been marked as a duplicate of bug 772290 ***
Comment 2 Kamil Páral 2012-01-18 11:15:38 EST
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 11:45:08 EST
Fair enough and sorry for not reading your BZ more closely.
Comment 4 Daniel Berrange 2012-01-19 06:27:06 EST
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 09:04:40 EDT
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 18:32:19 EDT
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 18:35:55 EDT
(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 04:09:26 EDT
(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 04:16:26 EDT
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 12:28:31 EDT
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 04:18:26 EDT
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.