[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] qemu: configurable VNC port boundaries for domains



On Wed, May 23, 2012 at 10:31:12AM +0100, Daniel P. Berrange wrote:
> On Tue, May 22, 2012 at 11:00:16AM -0400, Dave Allan wrote:
> > On Tue, May 22, 2012 at 04:10:03PM +0200, Martin Kletzander wrote:
> > > The defines QEMU_VNC_PORT_MIN and QEMU_VNC_PORT_MAX were used to find
> > > free port when starting domains. As this was hardcoded to the same
> > > ports as default VNC servers, there were races with these other
> > > programs. This patch includes the possibility to change the default
> > > starting port as well as the maximum port in qemu config file.
> > 
> > Hi Martin,
> > 
> > Two design comments:
> > 
> > 1) https://bugzilla.redhat.com/show_bug.cgi?id=782814 requests that
> > the default port be changed to avoid conflicts, which seems reasonable
> > to me.
> 
> I disagree - for as long as KVM and Xen have existed, all guests have
> had ports starting at 5900 & we should not be changing that. libvirt
> should be checking for a clash before starting a guest, so there should
> not be any functional problem here.

I'm not sure how libvirt does this today, but passing the port in the
command line is inherently raceful. Either pass the open socket to qemu,
or let qemu choose the port by itself.

> Moving to another port range is
> merely a nicety that we don't need todo by default, merely give admins
> the ability.
> 
> > 
> > 2) I agree with the config option since most applications on the
> > system will want the system defaults.  However, IMO in this case an
> > application writer should be given the option in the XML to override
> > the system default.
> 
> I don't really think this is worth while either. I don't really think
> that apps need / want the ability to override the system ranges here
> on a per guest basis

Yep, that's true for vdsm too (within ovirt). I can tell why host-wide
config is useful, but not why the range should be VM-specific.

Regards,
Dan.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]