<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>  <style>  </style> </head> <body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'> <div class=Section1 style='layout-grid:15.6pt'> Thanks Daniel for the info.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Looking forward to your reply.<o:p></o:p> <o:p> </o:p> static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,<o:p></o:p> unsigned int flags) {<o:p></o:p> struct qemud_driver *driver = conn->privateData;<o:p></o:p> virDomainDefPtr def;<o:p></o:p> virDomainObjPtr vm = NULL;<o:p></o:p> virDomainPtr dom = NULL;<o:p></o:p> virDomainEventPtr event = NULL;<o:p></o:p> <o:p> </o:p> virCheckFlags(VIR_DOMAIN_START_PAUSED, NULL);<o:p></o:p> <o:p> </o:p> qemuDriverLock(driver); <== <o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> Guangya<o:p></o:p> <o:p> </o:p> -----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Tuesday, November 09, 2010 9:47 PM To: Guangya Liu Cc: <st1:PersonName w:st="on">libvir-list@redhat.com</st1:PersonName> Subject: Re: [libvirt] race condtion in getting VNC port for libvirt <o:p> </o:p> On Sun, Nov 07, 2010 at 08:53:32PM +0800, Guangya Liu wrote:<o:p></o:p> > Hi,<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > We are encountering a problem of race conditions for getting VNC port<o:p></o:p> > when VM start up.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > In a very powerful hypervisor, if we try to start up more than 1 VM<o:p></o:p> > concurrently, then there might be some VMs failed to start up due to VNC<o:p></o:p> > port confilict.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > We searched libvirt bugs and found that some one report the problem and<o:p></o:p> > we have give a fix, but the fix can not resolve the problem.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > http://osdir.com/ml/libvir-list/2010-05/msg00530.html<o:p></o:p> > <o:p></o:p> > https://build.opensuse.org/package/view_file?file=vnc-race-3.patch&packa<o:p></o:p> > ge=libvirt&project=Virtualization:openSUSE11.3<o:p></o:p> <o:p> </o:p> This patch is already merged in current GIT repos.<o:p></o:p> <o:p> </o:p> > The bitmap test-and-set operation is not atomic, so that there still is<o:p></o:p> > a time-window in which a VNC port could be reserved for two caller. <o:p></o:p> <o:p> </o:p> The virBitmap APIs for getting & setting don't need to be atomic, because<o:p></o:p> they are only called when the QEMU driver mutex is held, which ensures<o:p></o:p> serialization of VM startup.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Daniel<o:p></o:p> -- <o:p></o:p> |: Red Hat, Engineering, <st1:City w:st="on"><st1:place w:st="on">London</st1:place></st1:City> -o- http://people.redhat.com/berrange/ :|<o:p></o:p> |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|<o:p></o:p> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|<o:p></o:p> |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|<o:p></o:p> </div> </body> </html>