search for: pmemsav

Hello Everyone, I am working on a grad school project for virtual introspection. I have a vm running (with 512mb of memory) and want to access the pmemsave function through virsh with the qemu-monitor-command. I am typing the following: virsh qemu-monitor-command --hmp Shawn 'pmemsave 0 536870912 image.dump' Shawn is the name of my vm and image.dump is the name of my output file. No matter what I do, I keep getting: Could not open &...

...xecution (in paused state). What do I need is the complete linear memory image, byte per byte, nothing special; I will give this output to tools and parsers like Volatility to get the value from it. I looked around and the only way to get the memory in such a way is using the QEMU monitor command `pmemsave`. I am using libvirt through its Python bindings and the virDomainQemuMonitorCommand seems not to be exposed by the API so, as suggested in some mails I read into the mailig list, I switched to virDomainMemoryPeek. Using this function keeps up to 14-16 seconds to read 512Mb of memory with the 64K...

...t; is running under. If (by default) your qemu processes run under > root:root so will the coredump. > I changed default settings but it didn't work. I can see the qemu processes now belonging to my user but yet the core dump is root:root. I used to generate such file with plain QMP 'pmemsave' command and it was creating it under libvirt-qemu group which was a bit better. This new command is way more handy but if I can't sort this issue out I'll need to fallback to the previous one. I set in /etc/libvirt/qemu.conf the keys user = "myuser" group = "mygroup&q...

On 04/27/2017 04:31 PM, Stefano Ricci wrote: > Here is the backtrace of the libvirt process just started [Just a side note, you shouldn't top post on technical lists. Gmail sucks at this.] > > https://pastebin.com/R66myzFp Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but it takes ages to init. In the debug logs you might see the actual command line that

...> "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": > "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": > "qmp_capabilities"}, {"name": "pmemsave"}, {"name": "object-del"}, > {"name": "object-add"}, {"name": "netdev_del"} ....... > So it would not look like a qemu bug. Well, this does not prove that qemu replies to all commands issued by libvirt. For that we would need...

...ning under. If (by default) your qemu processes run under >> root:root so will the coredump. > > I changed default settings but it didn't work. I can see the qemu processes now belonging to my user but yet the core dump is root:root. I used to generate such file with plain QMP 'pmemsave' command and it was creating it under libvirt-qemu group which was a bit better. This new command is way more handy but if I can't sort this issue out I'll need to fallback to the previous one. > > I set in /etc/libvirt/qemu.conf the keys > > user = "myuser" &gt...

...uot;name": "query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": "qmp_capabilities"}, {"name": "pmemsave"}, {"name": "object-del"}, {"name": "object-add"}, {"name": "netdev_del"} ....... So it would not look like a qemu bug. Stefano

Greetings, I am dumping a guest VM memory for inspection using the command "virDomainCoreDumpWithFormat" and the created files appear to belong to root (both user and group). I have searched around but didn't find any answer. Is there a way to instruct QEMU to create those files under a different user? Thank you.

...uot;query-acpi-ospm-status"}, {"name": "qom-set"}, {"name": >> "qom-list-types"}, {"name": "qom-list"}, {"name": "qom-get"}, {"name": >> "qmp_capabilities"}, {"name": "pmemsave"}, {"name": "object-del"}, >> {"name": "object-add"}, {"name": "netdev_del"} ....... >> So it would not look like a qemu bug. > > Well, this does not prove that qemu replies to all commands issued by > libvirt. F...

...;}, {"name": "system_reset"}, {"name": "system_powerdown"}, {"name": "device_add"}, {"name": "device_del"}, {"name": "cpu"}, {"name": "memsave"}, {"name": "pmemsave"}, {"name": "migrate"}, {"name": "migrate_cancel"}, {"name": "migrate_set_speed"}, {"name": "client_migrate_info"}, {"name": "migrate_set_downtime"}, {"name": "netdev_add&q...