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