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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
