[libvirt] [PATCH] Avoid a race when restoring a qemu domain.

Laine Stump laine at laine.org
Wed Apr 7 18:39:35 UTC 2010

This patch adds a 1 second sleep after telling qemu to start the
restore operation and before telling qemu to start up the
CPUs. Without this sleep, my hardware would end up with the CPUs
started before the restore was started, leading to random (but never
good) behavior. Apparently this is caused by slow hardware, as I
haven't heard of anyone else experiencing this problem.

A sleep is a very inelegant way to eliminate the problem, but it's
apparently the only way currently available to us.

Note that sleep durations as low as 250msec were successful in
eliminating the bad behavior; I made it 1 sec. just for extra safety.
 src/qemu/qemu_driver.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 60fa95a..1270c84 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5965,6 +5965,13 @@ static int qemudDomainRestore(virConnectPtr conn,
     /* If it was running before, resume it now. */
     if (header.was_running) {
         qemuDomainObjPrivatePtr priv = vm->privateData;
+        /* pause 1 second to allow qemu time to start the restore,
+         * otherwise it may start the CPUs before the restore, and end
+         * up in a "nondeterminate" state.
+         */
+        usleep(1000000);
         qemuDomainObjEnterMonitorWithDriver(driver, vm);
         if (qemuMonitorStartCPUs(priv->mon, conn) < 0) {
             if (virGetLastError() == NULL)

More information about the libvir-list mailing list