[libvirt] [PATCH 6/6] qemu: Allow showing the dump progress for memory only dump

John Ferlan jferlan at redhat.com
Mon Nov 20 12:22:58 UTC 2017



On 11/20/2017 03:53 AM, Jiri Denemark wrote:
> On Fri, Nov 17, 2017 at 18:17:31 -0500, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=916061
>>
>> If the QEMU version running is new enough (based on QEMU_CAPS_QUERY_DUMP)
>> we can add a 'detach' boolean to the dump-guest-memory command in order
>> to tell QEMU to run in a thread. Then, use the qemuDumpWaitForCompletion
>> in order to 'watch' the dump and save the stats into the jobInfo data
>> so that tools (such as virsh) can pick up and display the completion
>> percentage. The processing is similar to qemuMigrationWaitForCompletion
>> at least with respect to calling the query-dump in a while loop that
>> gets a micro sleep in order for qemuDomainGetJobInfo to be able to
>> pull out the changed migration stats values.
> 
> Looks like the code was inspired by our old migration flow with a lot of
> copy&paste work. However, I don't think this is necessary. Does QEMU
> provide any event when a detached dump completes? If so, we should use
> it. If QEMU does not provide the event, I think we should only add
> support for detached dump once the event is implemented in QEMU. In
> other words, we should never poll for dump progress every 50ms.
> 
> Jirka
> 

Based on the output of the related QEMU bz there is an event:


 {"execute": "dump-guest-memory", "arguments": { "detach": true,
"paging": false, "protocol": "file:/home/dump.normal"}}
{"timestamp": {"seconds": 1489391067, "microseconds": 147976}, "event":
"STOP"}
{"return": {}}
{"timestamp": {"seconds": 1489391068, "microseconds": 219429}, "event":
"DUMP_COMPLETED", "data": {"result": {"total": 2164457472, "status":
"completed", "completed": 2164457472}}}
{"timestamp": {"seconds": 1489391068, "microseconds": 219876}, "event":
"RESUME"}

 {"execute": "query-dump"}
{"return": {"total": 2164457472, "status": "completed", "completed":
2164457472}}


Yet more code to go learn I guess.

John




More information about the libvir-list mailing list