Re: [Qemu-devel] race condition when exec'ing "qemu -incoming" followed by monitor "cont"

[Laine Stump <laine@redhat.com>]

On 04/09/2010 12:03 PM, Laine Stump wrote:
> (Please forgive (and correct!) any inaccuracies in my description of 
> qemu's workings - I've only recently started looking at it directly, 
> rather than through the lens of libvirt)
>
> libvirt implements a "domain restore" operation by:
>
> 0) start with a previously saved domain image in a file
>
> 1) open the domain image, and connect it to a pipe
>
> 2) fork, connect the pipe to stdin, and exec qemu with "-incoming 
> exec:cat"
>
> 3) execute "cont" in that qemu's monitor.

I realized after sending that I was too hasty in my reading of the code, 
and interpreted it incorrectly. The file containing the domain image is 
not sent into a pipe, but merely dup2'ed to be stdin in the child 
process. So the correct sequence of events is:

0) start with a previously saved domain image in a file

1) open the domain image

2) fork, dup2 the domain image's fd as stdin,  and exec qemu with 
"-incoming exec:cat"

3) execute "cont" in that qemu's monitor.


On 04/09/2010 12:29 PM, Paolo Bonzini wrote:
> On 04/09/2010 06:03 PM, Laine Stump wrote:
>>
>> Can someone provide any insight on why it is possible to start the CPUs
>> in the domain before the incoming migration is complete, and what we can
>> do (other than blindly sleeping) to prevent this?
>
> I would say it's a bug in QEMU, and it has to be fixed there.

My assumption would have been that, if -incoming is specified on the 
commandline, the monitor should not even be started up until the 
incoming migration is complete. Being new to qemu, though, I'm hoping 
there's something I'm missing.