From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amos Kong Subject: Re: [Qemu-devel] Use getaddrinfo for migration Date: Mon, 05 Mar 2012 16:03:35 +0800 Message-ID: <4F547357.5020802@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> <20120302104140.GC2740@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , Kevin Wolf , kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , laine@redhat.com To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28904 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756044Ab2CEIDo (ORCPT ); Mon, 5 Mar 2012 03:03:44 -0500 In-Reply-To: <20120302104140.GC2740@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.