[Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

[Oleg Nesterov]

On 04/26, Dave Anderson wrote:
>
> > Yes. And to remind, MEMORY-IMAGE at 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 at 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 at 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.