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.
next prev parent 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).