RE: [Patch][RFC] Support "xm dump" (is Re: Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Akio Takebe <takebe_akio@jp.fujitsu.com>]

Hi, Simon

>Two things:
>
>1. I'm not convinced 'xm crash' is needed - 'xm destroy' will do this
>(and if you want
>   a dump, do 'xm dump' followed by 'xm destroy')
>
What do you mean?
I think we cannot dump with "xm destroy" now.
"xm destory" only call the following domain_kill().
void domain_kill(struct domain *d)
{
    domain_pause(d);

    if ( test_and_set_bit(_DOMF_dying, &d->domain_flags) )
        return;

    gnttab_release_mappings(d);
    domain_relinquish_resources(d);
    put_domain(d);

    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
}

Will anyone add crash option in "xm destory" in the feature?

>2. I don't see the point of the --noreboot option on 'xm dump' -- I
>think this command
>   should simply live-dump the specified domain - as above you can use
>other commands
>   to cause the domain to restart afterwards.
>
Ordinary dump features have atomatically rebooting features.
(e.g. diskdump, kdump, and so on)
So I think this is necessary.

>3. There's no need to pause the domain to dump it - I actually wrote a
>little utility
>   to live dump a guest (based on xenconsoled and attached) and it seems
>to work
>   quite nicely! This could easily be morphed into the 'xm dump' command
>- it just
>   didn't occur to me at the time!
>
Your xendump command is dump feature without pause.
In the case without pause, domain's memory is modified while dumping. 
I think both w/o and w pause are needed.

Best Regards,

Akio Takebe