On Wed, Feb 10, 2010 at 10:49:40AM +0100, Jiri Denemark wrote:
> Currently the timeout for reading startup output is 3 seconds.
If the
> host is under any sort of load, we can easily trigger this. Lets bump
> it to 30 seconds.
>
> Since the polling loop checks to see if the process has died, we shouldn't
> erroneously hit this timeout if qemu bombs (only if it is stuck in some
> infinite loop).
>
> Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
> ---
> src/qemu/qemu_driver.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
It wouldn't be hard to make it fail even with 30 seconds timeout but then it
doesn't really make sense to try to start a new guest on a host which is under
such a big load. I think we should be fine with 30 seconds unless we want to
optimize for stuck qemu.
Hum, 30 seconds sounds a lot to me, I hope this won't mean a user
waiting for a 30 second timeout in some weird cases. But we were hitting
the 3s one way too easilly, going all th way to 30 should allow to
detect if/when this timeout reflects at the user level and clean those case
up
so ACK,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/