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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)
-- 
1.6.6.1

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]