Re: [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory

[Eric Blake]

On 11/24/2015 04:37 AM, Fam Zheng wrote:

>> I think the patch should be dropped, and periodic progress reports
>> should be emitted from within the dump loops that do the heavy lifting.
>>
>> For the ELF format dumps, that loop appears to reside in dump_iterate()
>> [dump.c].
>>
>> For the compressed format dumps, the loop seems to live in
>> write_dump_pages() [dump.c].
> 
> This is a good idea!
> 
> What I'm not sure is where to report the progress. Can it be the monitor where
> the dump-guest-memory command was issued? In other words, do we support 
> raising
> events before the previous command returns? If yes, can libvirt handle this
> correctly? (But the worst case is using another channel to communicate the
> progress, it is ad-hocery but it must be better than all the risk and effort 
> to
> enable multi-threaded dump.)
> 
> Eric, Markus, have any idea with the progress reporting?

I'm fairly certain we support raising events prior to completion of a
synchronous command; what I'm not sure of is whether the event hits the
wire right away or whether it piles up waiting for the next synchronous
command completion.  If the latter, then we need to rework it (since the
whole point of this exercise is that we are trying to give progress of a
long-running synchronous command that hasn't completed yet).  But we
only have the one monitor connection for libvirt - the only way to pass
events through a second channel is to open a second monitor connection,
but that feels wrong to make libvirt have to track two monitors.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature