[libvirt] race condtion in getting VNC port for libvirt

[Daniel P. Berrange]

On Wed, Nov 10, 2010 at 01:21:24AM +0800, Guangya Liu wrote:
> Thanks Daniel for the info.
> 
>  
> 
> But I still have a question, since we already make the call
> qemudDomainCreate synced, why do we need to introduce a bitmap to
> resolve the problem of getting VNC port conflict error? If
> qemudDomainCreate is synced, then there should not any problem with VNC
> port.

Previously, libvirt would call bind() on port numbers until it found
one free, then close() the socket & launch QEMU telling it to open
that port again. Thus there is a race between libvirt finding a free
port with bind()+close() for the first VM, and QEMU actually opening
it, where libvirt could then start looking for another port for a
second VM. The libvirt driver lock doesn't solve that, because the code
involves a separate QEMU process with is outside the context of the
lock

With the bitmap code, libvirt now records that it assigned this
port number to a VM, so when libvirt goes to start a second VM
it won't reuse this port, even if the first QEMU hasn't yet got
around to opening it.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|