From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4StT-0003cU-O2 for qemu-devel@nongnu.org; Mon, 05 Mar 2012 03:03:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4StR-0000TC-Jg for qemu-devel@nongnu.org; Mon, 05 Mar 2012 03:03:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4StR-0000T3-As for qemu-devel@nongnu.org; Mon, 05 Mar 2012 03:03:41 -0500 Message-ID: <4F547357.5020802@redhat.com> Date: Mon, 05 Mar 2012 16:03:35 +0800 From: Amos Kong 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> <4F50A020.9030502@msgid.tls.msk.ru> <20120302104140.GC2740@redhat.com> In-Reply-To: <20120302104140.GC2740@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: "Daniel P. Berrange" Cc: Kevin Wolf , kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com, Michael Tokarev , qemu-devel@nongnu.org, Anthony Liguori , laine@redhat.com On 02/03/12 18:41, Daniel P. Berrange wrote: > 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. I've prepared a V2 according to Kevin's comment, https://github.com/kongove/qemu/commits/master But I don't know how to process the getaddrinfo issue, which steps should be done by a thread? anyone can give a hint? thanks. == migrate steps == 0. main_loop, qemu_iohandler_poll 1. get migration command from qemu monitor 2. parse host/port, get an address list by getaddrinfo() 3. connect server 4. check status and return to main_loop (step 0) (VMstate data is transmitted in background) main_loop_wait() ... \- do_migrate() \- tcp_start_outgoing_migration() \- tcp_client_start() \- parse_host_port_info() \- getaddrinfo() -- Amos.