[libvirt] MemoryPeek() is slow

[Richard W.M. Jones]

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.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top