Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
On 04/26, Dave Anderson wrote:
> Yes. And to remind, MEMORY-IMAGE@ADDRESS (which is even documented in crash.8 as
> "raw RAM dumpfile that has no header information") doesn't work on
x86-64, because
> ramdump_to_elf() fails with "unsupported machine type".
Correct. It's only supported the architectures listed because they are the only
architectures used by the companies who wrote and support the facility. If somebody
comes along and makes it work with x86_64, it can easily be added. Nobody has.
>
> So imo 08/10 (which is the trivial preparation) and 09/10 make sense anyway, this
> doesn't need the previous LOCAL_ACTIVE patches.
>
> Yes, let me repeat that 09/10 asks for cleanup (the change in main.c). This is
> because I fail to understand this "if (is_ramdump())" block in main(), it
looks
> simply wrong to me, but this is off-topic right now.
Right, it is confusing. There are two ways to utilize their ramdump files.
You can take the ramdump file and either:
(1) use the -o option to create a new vmcore containing an ELF header prepended to the
ramdump file, and then access it like the kdump clone that it is. At that point,
the original ramdump file can be deleted.
(2) create a temporary in-memory ELF header for accessing the ramdump during the
crash session.
I see. What I can't understand is why (2) sets KDUMP but switches to
pc->readmem = read_ramdump() instead of read_kdump(), even if it creates the same
elf vmcore.
> > If we're *just* talking about supporting live system
access of a QEMU/KVM guest,
> > then it should have nothing to do with ramdump.c.
>
> See above. But as for "live" ramdump's I do not see another use-case
except qemu
> running with memory-backend-file.
Sorry Oleg, but I'm afraid that I seem to be regressing...
Me too ;)
I don't understand the difference between what you call a
"raw" and a "live" ramdump?
Let's get back to basics. Is is possible for the crash utility to simply issue
readmem
requests for physical memory to whatever magic you've got running on the live guest,
and have it satisfy the request? So that it would be essentially the same thing as
reading from /dev/mem, /proc/kcore or /dev/crash?
Or is there always going to have to be an actual dumpfile somewhere?
OK. So I am running the rhel7 guest on my Fedora machine and I pass the following
(additional) options to qemu:
-object memory-backend-file,id=MEM,size=128m,mem-path=/tmp/MEM,share=on \
-numa node,memdev=MEM \
so in this (trivial) case /tmp/MEM represents the physical memory as it seen by
the guest.
Now suppose that this guest crashes and qemu exits. In this case the "live"
mode
makes no sense, if nothing else it is slower.
So I can do
$ crash path-to-rhel7-vmlinux raw:/tmp/MEM@0
on the host, and it works. Sure, not that useful. I could do dump-guest-memory
from qemu before exiting and use the generated kvm dump.
"live" ramdump is a bit more interesting. I can do
$ crash path-to-rhel7-vmlinux live:/tmp/MEM@0
and debug the live guest running under qemu, when it is not going to stop/crash.
Just like I can use /bin/crash to debug the host kernel using /dev/crash, but
this guest is obviously "remote", so we need those LOCAL_ACTIVE changes in 1-7
to make it work.
Oleg.