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

> 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().
I mean that if you want to crash a domain and collect a dump, you can do
''xm dump'' followed by ''xm destroy'' or
''xm reboot'' -- there''s no need to
add another command to do the combination.
> >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.
xm dump foo
xm reboot foo

does the job nicely -- why complicate things by adding extra
options/commands
> 
> >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.
Hmm... perhaps although I''m not convinced -- I understand that memory
can change during the dump and therefore there can be some
inconsistencies in the dump, HOWEVER, pausing the domain doesn''t ensure
all the data structures are consistent either - it pretty much just
stops the VM wherever is happens to be so the memory can still be
inconsistent. 

I also think there is an issue with pausing -- unless I am mistaken,
pause requires code to run in the domain - if the domain is glued up
this cant run and the pause will hang (and lets face it, the usual
reason for dumping a domain is because something is wrong; definitely a
good idea to minimize the amount of work you expect from the domain in
this case).

FWIW, my opinion is that it isn''t necessary to pause.

/simgr


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Simon
>I mean that if you want to crash a domain and collect a dump, you can do
>''xm dump'' followed by ''xm destroy'' or
''xm reboot'' -- there''s no need to
>add another command to do the combination.
OK, I understand.
>> >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.
>
>xm dump foo
>xm reboot foo
OK.
>
>does the job nicely -- why complicate things by adding extra
>options/commands
>
>> 
>> >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.
>
>Hmm... perhaps although I''m not convinced -- I understand that
memory
>can change during the dump and therefore there can be some
>inconsistencies in the dump, HOWEVER, pausing the domain doesn''t
ensure
>all the data structures are consistent either - it pretty much just
>stops the VM wherever is happens to be so the memory can still be
>inconsistent. 
>
>I also think there is an issue with pausing -- unless I am mistaken,
>pause requires code to run in the domain - if the domain is glued up
>this cant run and the pause will hang (and lets face it, the usual
>reason for dumping a domain is because something is wrong; definitely a
>good idea to minimize the amount of work you expect from the domain in
>this case).
>
>FWIW, my opinion is that it isn''t necessary to pause.
>
I don''t agree it. It is necessary to pause for dumping domU''s
core,
because debugging is difficut with the unpause core.

But I think we can resolve the issue with the following way.
- If we want to get dump with pause
  1. xm pause foo
  2. xm dump foo
  3. xm reboot foo (if want to reboot)

- If we want to get live dump w/o pause
  1. xm dump foo

BTW, I try to make your xendump.c, but cannot compile it.
Could you post the Makefile?
I''d like to use your xendump.

Best Regards,

Akio Takebe


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

FWIW, it occurred to me that if you wanted to test whether a domain
could correctly restart after a power failure it might be convenient to
be able to dump and reboot in one atomic operation such that the dump
captured the state of the system exactly as it was when it went down.

This would make it easier to debug any problems discovered after the
subsequent reboot.

I don''t know whether this use-case is significant enough for you to
want
to take it into account.

On Fri, 2006-08-04 at 18:58 +0900, Akio Takebe wrote:
> Hi, Simon
> 
> >I mean that if you want to crash a domain and collect a dump, you can
do
> >''xm dump'' followed by ''xm destroy''
or ''xm reboot'' -- there''s no need to
> >add another command to do the combination.
> OK, I understand.
> 
> >> >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.
> >
> >xm dump foo
> >xm reboot foo
> OK.
> 
> >
> >does the job nicely -- why complicate things by adding extra
> >options/commands
> >
> >> 
> >> >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.
> >
> >Hmm... perhaps although I''m not convinced -- I understand that
memory
> >can change during the dump and therefore there can be some
> >inconsistencies in the dump, HOWEVER, pausing the domain
doesn''t ensure
> >all the data structures are consistent either - it pretty much just
> >stops the VM wherever is happens to be so the memory can still be
> >inconsistent. 
> >
> >I also think there is an issue with pausing -- unless I am mistaken,
> >pause requires code to run in the domain - if the domain is glued up
> >this cant run and the pause will hang (and lets face it, the usual
> >reason for dumping a domain is because something is wrong; definitely a
> >good idea to minimize the amount of work you expect from the domain in
> >this case).
> >
> >FWIW, my opinion is that it isn''t necessary to pause.
> >
> I don''t agree it. It is necessary to pause for dumping
domU''s core,
> because debugging is difficut with the unpause core.
> 
> But I think we can resolve the issue with the following way.
> - If we want to get dump with pause
>   1. xm pause foo
>   2. xm dump foo
>   3. xm reboot foo (if want to reboot)
> 
> - If we want to get live dump w/o pause
>   1. xm dump foo
> 
> BTW, I try to make your xendump.c, but cannot compile it.
> Could you post the Makefile?
> I''d like to use your xendump.
> 
> Best Regards,
> 
> Akio Takebe
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel