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@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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/