kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amos Kong <akong@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>, Kevin Wolf <kwolf@redhat.com>,
	kvm@vger.kernel.org, quintela@redhat.com, jasowang@redhat.com,
	qemu-devel@nongnu.org,
	Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	laine@redhat.com
Subject: Re: [Qemu-devel] Use getaddrinfo for migration
Date: Mon, 05 Mar 2012 16:03:35 +0800	[thread overview]
Message-ID: <4F547357.5020802@redhat.com> (raw)
In-Reply-To: <20120302104140.GC2740@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.

  reply	other threads:[~2012-03-05  8:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10  6:26 [PATCH 0/4] support to migrate with IPv6 address Amos Kong
2012-02-10  6:27 ` [PATCH 1/4] Use getaddrinfo for migration Amos Kong
2012-02-24  9:08   ` [Qemu-devel] " Kevin Wolf
2012-03-02  3:33     ` Amos Kong
2012-03-02 10:28       ` [Qemu-devel] " Kevin Wolf
2012-02-24  9:34   ` Kevin Wolf
2012-03-02  2:50     ` Amos Kong
2012-03-02 10:21       ` Kevin Wolf
2012-03-02 10:25       ` Michael Tokarev
2012-03-02 10:41         ` [Qemu-devel] " Daniel P. Berrange
2012-03-05  8:03           ` Amos Kong [this message]
2012-02-10  6:27 ` [PATCH 2/4] net/socket: allow ipv6 for net_socket_listen_init and socket_connect_init Amos Kong
2012-02-24  9:25   ` [Qemu-devel] " Kevin Wolf
2012-02-10  6:27 ` [PATCH 3/4] net: split hostname and service by last colon Amos Kong
2012-02-24  9:29   ` [Qemu-devel] " Kevin Wolf
2012-03-02  3:38     ` Amos Kong
2012-03-02  9:58       ` Amos Kong
2012-03-02 10:35         ` Kevin Wolf
2012-03-02 19:54           ` Laine Stump
2012-03-05  8:57             ` Kevin Wolf
2012-03-05  8:59               ` Amos Kong
2012-03-05  9:06                 ` Kevin Wolf
2012-02-10  6:27 ` [PATCH 4/4] net: support to include ipv6 address by brackets Amos Kong
2012-02-24  9:40 ` [Qemu-devel] [PATCH 0/4] support to migrate with IPv6 address Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F547357.5020802@redhat.com \
    --to=akong@redhat.com \
    --cc=aliguori@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=laine@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).