[libvirt] MemoryPeek() is slow

[Jun Koi]

On Wed, Jul 22, 2009 at 7:02 PM, Richard W.M. Jones<rjones at redhat.com> wrote:
> On Tue, Jul 21, 2009 at 07:39:07PM +0900, Jun Koi wrote:
>> Hi,
>>
>> I play around with MemoryPeek() API on QEMU. While it works well, I
>> found that it is too slow.
>>
>> That is expected because of the way it works: we always need to save
>> memory to a file, and read it in again, and that is too inefficient.
>
> Yes this is correct, and works that way because of how the qemu
> 'memsave' command works.
>
> Also there is a limit on the size of each peek (64K?) which is due to
> the libvirt remote protocol, specifically the max message size.
>
>> I am trying to figure out a better way to do this. To do that, clearly
>> we need to re-architecture QEMU for this: We must have another way to
>> read memory from outside the QEMU process.
>>
>> Anybody could suggest a solution for this problem? I am willing to
>> spend time on this feature to improve the situation.
>
> A better virDomainMemoryPeek / QEMU memsize would have the following
> features:
>
> (1) Allow large chunks of memory to be snapshotted all in one go.
> We'd still have to fetch them piece-by-piece because of the max
> message size in the libvirt remote protocol, but at least the single
> large snapshot would be more consistent.
>
> (2) Don't use the temporary file (?)
>
> (3) Be faster, eg. in the non-remote case.
>
> (4) Work with Xen and other hypervisors ...
>
> (5) Work with physical memory, virtual memory and registers.
>

On (5): that requires another API, not this virDomainMemoryPeek()

I agreed on (1), (2), (3) & (4).

For now, I want to improve the situation on QEMU (thus, KVM) first.
One obvious way is to transfer data directly from QEMU driver to QEMU
using a particular IPC. How about having an Unix domain socket for
this purpose?

I imagine that we need to have a separate socket, opened and managed
by QEMU interface.

Idea?

Thanks,
J