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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
