Re: [libvirt] [PATCH 2/2] Make monitor timeout configurable
On 06/22/2011 09:47 AM, Daniel P. Berrange wrote:
This makes the monitor timeout limit configurable via
the qemu.conf configuration file.
* src/conf/capabilities.h: Allow private data to be passed to
the virDomainObjPtr private allocation function
* src/libxl/libxl_driver.c, src/lxc/lxc_driver.c,
src/test/test_driver.c, src/uml/uml_driver.c,
src/vmware/vmware_driver.c: Update for API change in
capabilities
* src/qemu/qemu.conf, src/qemu/test_libvirtd_qemu.aug,
Do we have any html documentation for conf files, or is the mention in
qemu.conf of the new option sufficient?
+++ b/src/qemu/qemu.conf
@@ -287,3 +287,15 @@
# this
#
# lock_manager = "fcntl"
+
+# To change the amount of time we wait for a reply
+# from the QEMU monitor. QEMU monitor replies should
+# be pretty quick (< 5 seconds), but if the host is
+# seriously badly loaded this may take more time.
Double adverb 'seriously badly' doesn't sound very professional, but I
don't know that I have a better suggestion.
+ p = virConfGetValue (conf, "monitor_timeout");
+ CHECK_TYPE ("monitor_timeout", VIR_CONF_LONG);
+ if (p) driver->monTimeout = p->l;
arbitrary user value...
@@ -494,7 +495,7 @@ int qemuDomainObjBeginJob(virDomainObjPtr obj)
if (virTimeMs(&now) < 0)
return -1;
- then = now + QEMU_JOB_WAIT_TIME;
+ then = now + (priv->monTimeout * 1000ull);
which can then lead to integer overflow. We should have some sanity
checking on the user's input. Perhaps just cap things that if the
multiply would overflow, then just change driver->monTimeout to -1
(anyone with that large of a timeout won't be alive to wait around to
see that we stopped short of infinity :); as well as have code that
special cases -1 as a request to block rather than time out.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)