Re: [libvirt] [PATCH] Avoid a race when restoring a qemu domain.
On 04/07/2010 03:38 PM, Eric Blake wrote:
On 04/07/2010 12:39 PM, Laine Stump wrote:
> 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.
>
Is there a BZ number or anything else we can list in the commit message
showing that we've informed the qemu folks about their lack of a
reliable notification that they are ready for the restore?
No, good point. I need to understand the capabilities (and lack) of
what's there before I can file a coherent bug report, but it definitely
should be filed. (I arrived at this "fix" by asking around for advice
when I encountered the problem, rather than by analyzing the code myself.)
ACK. But can you squash this in first? Otherwise, the
usleep(1000000)
will silently become a no-op on mingw, rather than sleeping for a second.
As far as I know, qemu_driver.c would never be compiled with mingw,
since it only goes into libvirtd, and mingw is only used to build
client-side code.
Of course there are many other uses of usleep in the code, and some of
them may actually be in client-side code (I haven't checked) but making
them work properly should be a separate commit.
At any rate, I don't think I'll be committing this just yet - I sent the
patch to the list expecting there might be differences of opinion, but
figured we had to start a discussion about what should be done somewhere.
diff --git i/bootstrap.conf w/bootstrap.conf
index ac2f8e6..d55dc71 100644
--- i/bootstrap.conf
+++ w/bootstrap.conf
@@ -56,6 +56,7 @@ strsep
sys_stat
time_r
useless-if-before-free
+usleep
vasprintf
verify
vc-list-files