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.
There is no race wrt starting multiple VMs, since between the
time libvirt allocates the VNC port, and starts QEMU, it holds
the global driver lock. This prevents any other VM start attempts
racing for port numbers. You do have a tiny race wrt starting
VMs vs end user starting plain VNC servers, but this is really
tiny & for a RHEV-H style VDSM deployment non-existant.
Daniel
--
|: