From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Pvu-0005L5-6s for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:41:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3Pvo-0003OE-Te for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:41:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Pvo-0003Nu-L3 for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:41:48 -0500 Date: Fri, 2 Mar 2012 10:41:40 +0000 From: "Daniel P. Berrange" Message-ID: <20120302104140.GC2740@redhat.com> References: <20120210062608.13397.43361.stgit@dhcp-8-167.nay.redhat.com> <20120210062700.13397.6305.stgit@dhcp-8-167.nay.redhat.com> <4F475988.10603@redhat.com> <4F503561.5080906@redhat.com> <4F50A020.9030502@msgid.tls.msk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F50A020.9030502@msgid.tls.msk.ru> Subject: Re: [Qemu-devel] Use getaddrinfo for migration Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: Kevin Wolf , kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , laine@redhat.com, Amos Kong On Fri, Mar 02, 2012 at 02:25:36PM +0400, Michael Tokarev wrote: > Not a reply to the patch but a general observation. > > I noticed that the tcp migration uses gethostname > (or getaddrinfo after this patch) from the main > thread - is it really the way to go? Note that > DNS query which is done may block for a large amount > of time. Is it really safe in this context? Should > it resolve the name in a separate thread, allowing > guest to run while it is doing that? > > This question is important for me because right now > I'm evaluating a network-connected block device driver > which should do failover, so it will have to resolve > alternative name(s) at runtime (especially since list > of available targets is dynamic). > > From one point, _usually_, the delay there is very > small since it is unlikely you'll do migration or > failover overseas, so most likely you'll have the > answer from DNS handy. But from another point, if > the DNS is malfunctioning right at that time (eg, > one of the two DNS resolvers is being rebooted), > the delay even from local DNS may be noticeable. Yes, I think you are correct - QEMU should take care to ensure that DNS resolution can not block the QEMU event loop thread. There is the GLib extension (getaddrinfo_a) which does async DNS resolution, but for sake of portability it is probably better to use a thread to do it. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|