[libvirt-users] virDomainMemoryPeek: bad behavior under workload

[NoxDaFox]

On 31/08/12 18:20, Daniel P. Berrange wrote:
> On Fri, Aug 31, 2012 at 08:09:46AM -0700, Daniel P. Berrange wrote:
>> On Fri, Aug 31, 2012 at 03:23:18PM +0300, NoxDaFox wrote:
>>> Here's the typical output:
>>>
>>>    File "/home/nox/workspace/NOX/src/NOX/hooks.py", line 134, in trigger
>>>      hook.trigger(event)
>>>    File "/home/nox/workspace/NOX/src/NOX/hooks.py", line 33, in trigger
>>>      self.handlers[event]()
>>>    File "/home/nox/workspace/NOX/hooks/volatility.py", line 81, in memory_dump
>>>      for block in Memory(self.ctx):
>>>    File "/home/see/workspace/NOX/src/NOX/lib/libtools.py", line 179, in next
>>>      libvirt.VIR_MEMORY_PHYSICAL)
>>>    File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1759, in memoryPeek
>>>      ret = libvirtmod.virDomainMemoryPeek(self._o, start, size, flags)
>>> SystemError: error return without exception set
>> Hmm, that's a peculiar message to see - I can't find anywhere in the
>> libvirt code that uses that particular messages, so I'm not sure what
>> has gone wrong here.
> Oh, I think this might  be a python message. Our C binding does
>
>
>      LIBVIRT_BEGIN_ALLOW_THREADS;
>      c_retval = virDomainMemoryPeek(domain, start, size, buf, flags);
>      LIBVIRT_END_ALLOW_THREADS;
>
>      if (c_retval<  0)
>          goto cleanup;
>
>      py_retval = PyString_FromStringAndSize(buf, size);
>
> cleanup:
>      VIR_FREE(buf);
>      return py_retval;
> }
>
>
> In the 'c_retval<  0' check, I think we should have been doing
>
>     if (c_retval<  0) {
>        py_retval = VIR_PY_NONE;
>        goto cleanup;
>     }
>
> so we actually return Python's idea of None, rather than C's NULL,
> at which point you'd probably see the real error message from
> libvirt/QEMU
>
> Daniel
I looked more deeply into the code and I agree with you about the reason 
of that weird behavior when the error shows.
What I don't get is why the error should show.
I made more tests on different platforms and the behavior seems more 
random than expected.

What I'm doing is iterate over the memory, repeatedly calling the 
memoryPeek() command on memory blocks of 64Kb as libvirt's RPC driver is 
limited to this size.
Everything happens from separate processes peeking memory of separate 
virtual machines in suspended state during all the process; this means 
that whatever is happening on the guests is not running at the moment, 
neither the guest itself.

Do you know which version of QEMU is supporting the dump-guest-memory?

NoxDaFox