4:02 a.m.
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(a)redhat.com>
---
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)
+#define QEMU_REMOTE_PORT_MIN 1024
#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;
cfg->webSocketPortMin = QEMU_WEBSOCKET_PORT_MIN;
cfg->webSocketPortMax = QEMU_WEBSOCKET_PORT_MAX;
--
2.9.3
4:20 a.m.
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(a)redhat.com>
---
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.
+#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".
#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. Additionally, we tend to shoot to support 4k VMs which would
prevent to do so.
Peter
4:26 a.m.
On Fri, Apr 21, 2017 at 11:20:11AM +0200, Peter Krempa 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(a)redhat.com>
> ---
> 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.
> +#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".
> #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. Additionally, we tend to shoot to support 4k VMs which would
prevent to do so.
I'm not really convinced we want to change anything here. Typical desktop
virt usage via GNOME Boxes would be using session mode libvirt and so any
auto-started VMs would happen after Vino has already claimed port 5900.
The privileged libvirtd is targetted at server virt usage where you would
not have a desktop installed on the same machine. In remaining scenarios
its already possible to just edit qemu.conf to tweak local setup as desired.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:43 a.m.
On Fri, Apr 21, 2017 at 10:26:09AM +0100, Daniel P. Berrange wrote:
On Fri, Apr 21, 2017 at 11:20:11AM +0200, Peter Krempa 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(a)redhat.com>
> > ---
> > 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.
>
> > +#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".
>
> > #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. Additionally, we tend to shoot to support 4k VMs which would
> prevent to do so.
I'm not really convinced we want to change anything here. Typical desktop
virt usage via GNOME Boxes would be using session mode libvirt and so any
auto-started VMs would happen after Vino has already claimed port 5900.
The privileged libvirtd is targetted at server virt usage where you would
not have a desktop installed on the same machine. In remaining scenarios
its already possible to just edit qemu.conf to tweak local setup as desired.
A reminder from the past - we first introduced this qemu.conf setting for
the VNC port, in direct response to the same issue wrt to Vino. When we
did that we explicitly decided to *keep* 5900 as the first port we start
from, in order to avoid a semantic change to existing users of QEMU. ie
we don't want a libvirt upgrade to renumber all VNC ports for existing
deployed VMs, because this has non-trivial chance of breaking some existing
deployments. eg user has 10 VMs on their host, and they've opened ports
5900-5909 in their firewall. If we change first port to 5901, that user
will loose access to one of their VMs until they change their firewall
settings to match.
Given that this is the 1st time we had this complaint about Vino and QEMU
reappear since we added these qemu.conf settings in 2012, I don't think we
should change anything. We would be fixing a problem for small set of
users exchange for creating problems for other users. The qemu.conf setting
is a suitable workaround for when people do hit this problem.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:52 a.m.
On 21 Apr 2017, at 11:26, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
On Fri, Apr 21, 2017 at 11:20:11AM +0200, Peter Krempa 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(a)redhat.com>
>> ---
>> 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.
>
>> +#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".
>
>> #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. Additionally, we tend to shoot to support 4k VMs which would
> prevent to do so.
I'm not really convinced we want to change anything here. Typical desktop
virt usage via GNOME Boxes would be using session mode libvirt and so any
auto-started VMs would happen after Vino has already claimed port 5900.
There are too many limitations with session-mode VMs, like not being able to connect to
them easily from outside.
I also disagree with you assessment of “typical”. I have three auto-start VMs for my build
ring (basically, Linux, Windows and macOS). Because they are part of a build ring, I need
to be able to connect to them from outside (Jenkins launches jobs on them). I don’t see
that setup as outlandish for the typical open-source developer.
The privileged libvirtd is targetted at server virt usage where you
would
not have a desktop installed on the same machine. In remaining scenarios
its already possible to just edit qemu.conf to tweak local setup as desired.
My objection is to require tweaks to qemu.conf from the less experienced users so that the
more advanced sysadmins don’t have to…
Regards,
Christophe
Regards,
Daniel
--
|: https://berrange.com <https://berrange.com/> -o-
https://www.flickr.com/photos/dberrange <https://www.flickr.com/photos/dberrange>
:|
|: https://libvirt.org <https://libvirt.org/> -o-
https://fstop138.berrange.com <https://fstop138.berrange.com/> :|
|: https://entangle-photo.org <https://entangle-photo.org/> -o-
https://www.instagram.com/dberrange <https://www.instagram.com/dberrange> :|
--
libvir-list mailing list
libvir-list(a)redhat.com <mailto:libvir-list@redhat.com>
https://www.redhat.com/mailman/listinfo/libvir-list
<https://www.redhat.com/mailman/listinfo/libvir-list>
4:43 a.m.
On 21 Apr 2017, at 11:20, Peter Krempa <pkrempa(a)redhat.com>
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(a)redhat.com>
> ---
> 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
5 a.m.
On Fri, Apr 21, 2017 at 11:43:52AM +0200, Christophe de Dinechin wrote:
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.
4k ports for VNC still leaves 60k for other services, which allows another
17 ports per QEMU instance. The only way you're going to hit that limit
with 4k VMs is if you run the in-QEMU RBD client against a ceph server
that has lots of monitor hosts, at which point avoiding 4k ports from VNC
is going to have negligble benefit. So there's no real problem here for
common deployments.
If VNC were to be a problem though you would just put QEMU VNC onto
a UNIX socket, and run a websockets proxy to expose the VNC servers over
a single HTTP service.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2772
days inactive
2772
days old
6 comments
3 participants
participants (3)
-
Christophe de Dinechin -
Daniel P. Berrange -
Peter Krempa