On 19.09.2012 14:59, Martin Kletzander wrote:
On 09/19/2012 12:16 PM, Michal Privoznik wrote:
> On 19.09.2012 11:43, Michal Privoznik wrote:
>> Currently, we mark domain PAUSED (but not emit an event)
>> just before we issue 'stop' on monitor; This command can
>> take ages to finish, esp. when domain's doing a lot of
>> IO - users can enforce qemu to open files with O_DIRECT
>> which doesn't return from write() until data reaches the
>> block device. Having said that, we report PAUSED even if
>> domain is not paused yet.
>> ---
>>
>> The event is emitted correctly after all operations returns though.
>> But if mgmt app would 'virsh domstate $dom' as we are issuing
'stop'
>> monitor command it could get spurious results.
>
> Just for the record, qemu 'stop' command is guaranteed to NOT return
> until after all disks are synced. It is not that kind of command which
> just requests an operation an returns immediately (like 'shutdown' or
> something).
>
> This bug really confuses the enemy - esp. when mgmt application asks
> from another thread, it may get PAUSED domain state even though qemu is
> still syncing the disks or monitor command hasn't been issued at all or
> is about to fail.
>
That sounds reasonable. Reporting PAUSED when the domain is _being_
stopped and even if the operation might still fail is less sensible to
me as well. It would be nice to have a STOPPING state, but that's idea
for a longer period of time and more places in the code consequently
heading towards more problems etc.
So ACK for this version.
Martin
Thanks, pushed now.
Michal