Re: [PATCH] Use port range 5901-5999 if not set in qemu.conf, avoid port 5900

[Christophe de Dinechin <dinechin@xxxxxxxxxx>]

On 21 Apr 2017, at 11:20, Peter Krempa <pkrempa@xxxxxxxxxx> wrote:

On Fri, Apr 21, 2017 at 11:02:36 +0200, Christophe de Dinechin wrote:

In order to avoid conflict with the default port (5900) for host VNC server
(vino-server for example), or to conflict with X11 (starting at port 6000),
restrict range of ports to 5901-5999 unless explicitly specified in qemu.conf.

On the other hand, if port range is explicitly specified in qemu.conf,
there is no reason not to allow ports 1024-5900 (system ports are below 1024).

Addresses https://bugzilla.redhat.com/show_bug.cgi?id=1442235

Signed-off-by: Christophe de Dinechin <dinechin@xxxxxxxxxx>
---
src/qemu/qemu_conf.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 1b704da..07f3177 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -65,9 +65,15 @@ VIR_LOG_INIT("qemu.qemu_conf");
 * This limitation is mentioned in qemu.conf, so bear in mind that the
 * configuration file should reflect any changes made to these values.
 */
-#define QEMU_REMOTE_PORT_MIN 5900
+
+// Range of available ports - Avoid ports below 1024 (system ports)

We don't use single line comments.

OK. I will change that. Ah, 1990s nostalgia! ;-)

+#define QEMU_REMOTE_PORT_MIN 1024

I don't think it's possible to use ports < 5900 due to the weird way you
specify VNC "screens”.

I considered that. But there are many use cases where you specify port manually, so this could be a feature. For example, you could manually assign ports in the range 5900-5999 for “front-end” VMs, with a convenient display number, but let “back-end VMs” be assigned automatically elsewhere, so that they don’t steal ports. That means administering a back-end VM would require you to use an explicit port number, but for normal users, they would access a front-end VM and just use a display number.

I don’t know if that makes sense or not. This could be a separate patch too. It’s not really the same problem after all.

#define QEMU_REMOTE_PORT_MAX 65535

+// Default min and max if not configured in qemu.conf
+#define QEMU_REMOTE_PORT_MIN_DEFAULT 5901
+#define QEMU_REMOTE_PORT_MAX_DEFAULT 5999
+
#define QEMU_WEBSOCKET_PORT_MIN 5700
#define QEMU_WEBSOCKET_PORT_MAX 65535

@@ -283,8 +289,8 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)

#undef SET_TLS_X509_CERT_DEFAULT

-    cfg->remotePortMin = QEMU_REMOTE_PORT_MIN;
-    cfg->remotePortMax = QEMU_REMOTE_PORT_MAX;
+    cfg->remotePortMin = QEMU_REMOTE_PORT_MIN_DEFAULT;
+    cfg->remotePortMax = QEMU_REMOTE_PORT_MAX_DEFAULT;

This can conflict basically with everything running  on non-system
ports.

This default range is 5901-5999, so this would not conflict with anything running on non-system ports, unless you specify that in qemu.conf (but then you know what you are doing)

Additionally, we tend to shoot to support 4k VMs which would prevent to do so.

I’m not sure I understood your comment. Do you mean 4000 VMs running concurrently, or 4K display? For the latter, I don’t see how port assignment matters, so I deduce you talk about running more than 99 VMs simultaneously. Can you do that without tweaks to qemu.conf? It’s really a trade-off. Experienced sysadmins will have to extend available ports in qemu.conf (and I place anybody running more than 100 VMs on a single system in that category). Regular users won’t have conflicts with vino-server or (if über-unlucky) X11. That seems like a reasonable trade-off to me.

BTW, if you really run 4K VMs on a single host, assigning one port per VM for display will become a problem anyway. There are only 64K ports available, so using 4K just for displays does not scale well, not even counting the ports you might need for the VM workloads themselves. It might be time to think about adding a VM ID directly in the protocol and having multiple connections to the same port.

Christophe

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list