On Tue, Jul 23, 2013 at 05:22:36PM -0700, Matt Wilson wrote:

On Mon, Jul 22, 2013 at 11:33:15AM -0700, Greg KH wrote:

quoted

On Mon, Jul 22, 2013 at 11:24:46AM -0700, H. Peter Anvin wrote:

quoted

On 07/22/2013 10:20 AM, Eric W. Biederman wrote:

quoted

quoted

quoted

Also, in any virtualized environment the hypervisor can do a better job
for things like kdump, simply because it can provide two things that are
otherwise hard to do:

1. a known-good system state;
2. a known-clean kdump image.

As such, I do encourage the virtualization people to (also) develop
hypervisor-*aware* solutions for these kinds of things.

In general I agree but if you could not change hypervisor
and/or dom0 (e.g. you are using cloud providers which are
stick to old versions of Xen) then you have no choice.

Which tends to be where kexec on panic comes in most cases.  Getting
platform vendors to do something sane tends to be a multi-year political
effort of dubious worth while just solving the problem locally actually
gets the problem solved for those who care.

It should not be a "one or the other" issue.

I don't care about kdump, I care about kexec on domU for people who are
running on cloud providers with old versions of Xen so that they can
control what kernel they can boot, when they want to boot it.  If kdump
works as well, that's just a bonus, but it's down on the list of things
for me to be concerned about.

Many Xen-based cloud providers provide a mechanism for users to boot
the kernels they want. For example you can use PV-GRUB on EC2
instances to boot a kernel that is stored within an AMI.

For more info:
  http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedkernels.html

Yes, that's quite true, but some don't, or they make it difficult to do
so.  Using kexec also allows you to "be the bootloader" and decide on
_which_ kernel you want to boot, independant of what cloud provider you
use, something that lots of people want in their quest to not dependant
on any one company.

thanks,

greg k-h