From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: Use getaddrinfo for migration Date: Fri, 02 Mar 2012 14:25:36 +0400 Message-ID: <4F50A020.9030502@msgid.tls.msk.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Wolf , kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, laine@redhat.com, Anthony Liguori To: Amos Kong Return-path: Received: from isrv.corpit.ru ([86.62.121.231]:44108 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753046Ab2CBKZj (ORCPT ); Fri, 2 Mar 2012 05:25:39 -0500 In-Reply-To: <4F503561.5080906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Thanks, /mjt From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Pgf-0007AC-Ch for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:26:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3PgI-0000hx-ET for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:26:08 -0500 Received: from isrv.corpit.ru ([86.62.121.231]:58591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3PgI-0000gL-3Z for qemu-devel@nongnu.org; Fri, 02 Mar 2012 05:25:46 -0500 Message-ID: <4F50A020.9030502@msgid.tls.msk.ru> Date: Fri, 02 Mar 2012 14:25:36 +0400 From: Michael Tokarev MIME-Version: 1.0 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> In-Reply-To: <4F503561.5080906@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Use getaddrinfo for migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amos Kong Cc: Kevin Wolf , kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , laine@redhat.com 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. Thanks, /mjt