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

[Christophe de Dinechin]

> On 21 Apr 2017, at 11:26, Daniel P. Berrange <berrange at 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 at 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 at redhat.com <mailto:libvir-list at redhat.com>
> https://www.redhat.com/mailman/listinfo/libvir-list <https://www.redhat.com/mailman/listinfo/libvir-list>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170421/65ca6dca/attachment-0001.htm>