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@xxxxxxxxxx> > > --- > > 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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list