Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
* As basis for documenting --format, I recommend the "virsh" manual:
> --format /string/ is used to specify the format of 'memory-only' dump, and
> /string/ can be one of them: /elf/, /kdump-zlib/ (kdump-compressed format with
> zlib-compressed), /kdump-lzo/ (kdump-compressed format with
> lzo-compressed), /kdump-snappy/ (kdump-compressed format with
> snappy-compressed).
* For documenting "dump-guest-memory.py", I recommend two sources as basis:
(1) The commit message of the patch that introduced the script:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3e16d14fd93c
(2) The current built-in help text from the script:
http://git.qemu.org/?p=qemu.git;a=blob;f=scripts/dump-guest-memory.py
Namely:
> Extract guest vmcore from qemu process coredump.
>
> The two required arguments are FILE and ARCH:
> FILE identifies the target file to write the guest vmcore to.
> ARCH specifies the architecture for which the core will be generated.
>
> This GDB command reimplements the dump-guest-memory QMP command in
> python, using the representation of guest memory as captured in the qemu
> coredump. The qemu process that has been dumped must have had the
> command line option "-machine dump-guest-core=on" which is the default.
>
> For simplicity, the "paging", "begin" and "end" parameters of the QMP
> command are not supported -- no attempt is made to get the guest's
> internal paging structures (ie. paging=false is hard-wired), and guest
> memory is always fully dumped.
>
> Currently aarch64-be, aarch64-le, X86_64, 386, s390, ppc64-be,
> ppc64-le guests are supported.
>
> The CORE/NT_PRSTATUS and QEMU notes (that is, the VCPUs' statuses) are
> not written to the vmcore. Preparing these would require context that is
> only present in the KVM host kernel module when the guest is alive. A
> fake ELF note is written instead, only to keep the ELF parser of "crash"
> happy.
>
> Dependent on how busted the qemu process was at the time of the
> coredump, this command might produce unpredictable results. If qemu
> deliberately called abort(), or it was dumped in response to a signal at
> a halfway fortunate point, then its coredump should be in reasonable
> shape and this command should mostly work.
Thanks!