[libvirt] [PATCH] Avoid a race when restoring a qemu domain.
Laine Stump
laine at laine.org
Thu Apr 8 03:42:11 UTC 2010
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
>
>
More information about the libvir-list
mailing list