11:02 a.m.
I have some code that allows this. See the following mail thread:
http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
The questions are:
1. Does remote access have a specification?
2. Is it supported?
3. Should the code be part of xen or crash?
-Don Slutz
8:09 a.m.
----- Original Message -----
I have some code that allows this. See the following mail thread:
http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
The questions are:
1. Does remote access have a specification?
If you're talking about the remote.c file in the crash sources, no,
there's nothing other than the remote.c file itself.
2. Is it supported?
It's been deprecated for almost 10 years now. I don't understand how
you have been able to even get it to build, never mind work as the mail
thread indicates? But I don't know anything about xen_crash, xentrace,
or how it even interacts with the crash utility? It looks like it might
replace the old "crashd" daemon that was built as part of the old remote
access facility?
3. Should the code be part of xen or crash?
I don't know. Xen support is no longer something I'm actively involved
with since Red Hat dropped support for it. Since then, Xen support in
the crash utility has primarily come from Daniel Kiper from Oracle and
Petr Tesarik from SUSE. They are both on the list, and should see this
message, but I'll cc them in this response as well.
Thanks,
Dave
2:22 p.m.
On 10/16/13 09:09, Dave Anderson wrote:
----- Original Message -----
> I have some code that allows this. See the following mail thread:
>
> http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
>
> The questions are:
>
>
> 1. Does remote access have a specification?
If you're talking about the remote.c file in the crash sources, no,
there's nothing other than the remote.c file itself.
Ok, looks like I will need
to write something up.
> 2. Is it supported?
It's been deprecated for almost 10 years now. I don't understand how
you have been able to even get it to build, never mind work as the mail
thread indicates?
crash is still building remote.c in 7.0.2-0 and still accepts the
command line option:
don-760:~/rpmbuild/BUILD/crash-7.0.2>./crash -d99 localhost:5001
crash 7.0.2
Copyright (C) 2002-2013 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for
details.
server: [localhost]
port: [5001]
file1: [(null)]
file2: [(null)]
127.0.0.1
don-760.cloudswitch.com: Unknown host
crash: connect [don-760.cloudswitch.com:5001] failed
don-760:~/rpmbuild/BUILD/crash-7.0.2>
But I don't know anything about xen_crash, xentrace,
or how it even interacts with the crash utility? It looks like it might
replace the old "crashd" daemon that was built as part of the old remote
access facility?
Yes, that is the case. My guess is that using crashd was more pain the help.
However the big plus in the case is that the guest (domU) is paused while crash is running
and so can be seen more like a dump and not a active system. I have found that crash has
some issues between active, remote, and dump modes; but most of them are speed related or
start-up like guessing the kernel version.
> 3. Should the code be part of xen or crash?
I don't know. Xen support is no longer something I'm actively involved
with since Red Hat dropped support for it. Since then, Xen support in
the crash utility has primarily come from Daniel Kiper from Oracle and
Petr Tesarik from SUSE. They are both on the list, and should see this
message, but I'll cc them in this response as well.
Thanks,
Dave
I think david.vrabel(a)citrix.com is also involved now (adding to CC list).
-Don Slutz
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:49 a.m.
On Tue, 15 Oct 2013 12:02:51 -0400
Don Slutz <dslutz(a)verizon.com> wrote:
I have some code that allows this. See the following mail thread:
http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
The questions are:
1. Does remote access have a specification?
2. Is it supported?
I have never even made it to work. But since there's now some new use
for it, I wouldn't object reviving the code.
3. Should the code be part of xen or crash?
I think it should be part of xen, because it needs the xen development
files, which would be a new dependency for the crash utility. Also, the
development cycle is more aligned with xen than crash.
Just my two cents,
Petr T
2:25 p.m.
On 10/16/13 09:49, Petr Tesarik wrote:
On Tue, 15 Oct 2013 12:02:51 -0400
Don Slutz <dslutz(a)verizon.com> wrote:
> I have some code that allows this. See the following mail thread:
>
> http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
>
> The questions are:
>
> 1. Does remote access have a specification?
> 2. Is it supported?
I have never even made it to work. But since there's now some new use
for it, I wouldn't object reviving the code.
Good.
> 3. Should the code be part of xen or crash?
I think it should be part of xen, because it needs the xen development
files, which would be a new dependency for the crash utility. Also, the
development cycle is more aligned with xen than crash.
Just my two cents,
Petr T
That is why I started with it in xen. Not sure where it will end up.
-Don Slutz
12:03 p.m.
Hi,
Sorry for late reply but I am very busy now.
On Thu, Oct 17, 2013 at 03:25:25PM -0400, Don Slutz wrote:
On 10/16/13 09:49, Petr Tesarik wrote:
>On Tue, 15 Oct 2013 12:02:51 -0400
>Don Slutz <dslutz(a)verizon.com> wrote:
>
>>I have some code that allows this. See the following mail thread:
>>
>>http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
>>
>>The questions are:
>>
>> 1. Does remote access have a specification?
>> 2. Is it supported?
>I have never even made it to work. But since there's now some new use
>for it, I wouldn't object reviving the code.
>
Good.
>> 3. Should the code be part of xen or crash?
>I think it should be part of xen, because it needs the xen development
>files, which would be a new dependency for the crash utility. Also, the
>development cycle is more aligned with xen than crash.
>
>Just my two cents,
>Petr T
That is why I started with it in xen. Not sure where it will end up.
I do not know protocol details but I think that it is worth checking
gdbsx tool from Xen (xen/tools/debugger/gdbsx) and gdb protocol spec
(you could expose GDB interface from QEMU so it could be useful in HVM
case). Maybe crash protocol is very similar or even identical with GDB
protocol because a large part of crash is GDB itself.
Daniel
11:37 a.m.
On Tue, Oct 22, 2013 at 07:03:19PM +0200, Daniel Kiper wrote:
Hi,
Sorry for late reply but I am very busy now.
On Thu, Oct 17, 2013 at 03:25:25PM -0400, Don Slutz wrote:
> On 10/16/13 09:49, Petr Tesarik wrote:
> >On Tue, 15 Oct 2013 12:02:51 -0400
> >Don Slutz <dslutz(a)verizon.com> wrote:
> >
> >>I have some code that allows this. See the following mail thread:
> >>
> >>http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
> >>
> >>The questions are:
> >>
> >> 1. Does remote access have a specification?
> >> 2. Is it supported?
> >I have never even made it to work. But since there's now some new use
> >for it, I wouldn't object reviving the code.
> >
> Good.
> >> 3. Should the code be part of xen or crash?
> >I think it should be part of xen, because it needs the xen development
> >files, which would be a new dependency for the crash utility. Also, the
> >development cycle is more aligned with xen than crash.
> >
> >Just my two cents,
> >Petr T
> That is why I started with it in xen. Not sure where it will end up.
I do not know protocol details but I think that it is worth checking
gdbsx tool from Xen (xen/tools/debugger/gdbsx) and gdb protocol spec
(you could expose GDB interface from QEMU so it could be useful in HVM
case). Maybe crash protocol is very similar or even identical with GDB
protocol because a large part of crash is GDB itself.
Ugh... I was in a hurry and forgot about final statement. Sorry for that.
So we could just use existing solutions if they are compatible with
protocol used by crash.
Daniel
9:17 p.m.
Sorry for the late reply. I was off attending the Xen Developer
Conference, and then testing out the latest kexec code, and am just
getting back to this,
On 10/23/13 12:37, Daniel Kiper wrote:
On Tue, Oct 22, 2013 at 07:03:19PM +0200, Daniel Kiper wrote:
> Hi,
>
> Sorry for late reply but I am very busy now.
>
> On Thu, Oct 17, 2013 at 03:25:25PM -0400, Don Slutz wrote:
>> On 10/16/13 09:49, Petr Tesarik wrote:
>>> On Tue, 15 Oct 2013 12:02:51 -0400
>>> Don Slutz <dslutz(a)verizon.com> wrote:
>>>
>>>> I have some code that allows this. See the following mail thread:
>>>>
>>>> http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
>>>>
>>>> The questions are:
>>>>
>>>> 1. Does remote access have a specification?
>>>> 2. Is it supported?
>>> I have never even made it to work. But since there's now some new use
>>> for it, I wouldn't object reviving the code.
>>>
>> Good.
>>>> 3. Should the code be part of xen or crash?
>>> I think it should be part of xen, because it needs the xen development
>>> files, which would be a new dependency for the crash utility. Also, the
>>> development cycle is more aligned with xen than crash.
>>>
>>> Just my two cents,
>>> Petr T
>> That is why I started with it in xen. Not sure where it will end up.
> I do not know protocol details but I think that it is worth checking
> gdbsx tool from Xen (xen/tools/debugger/gdbsx) and gdb protocol spec
> (you could expose GDB interface from QEMU so it could be useful in HVM
> case). Maybe crash protocol is very similar or even identical with GDB
> protocol because a large part of crash is GDB itself.
I can see using gdbsx and
gdb. However I have found crash to be easier
in lots of cases. I could have used xg from here if I did not already
have code based on xenctx.
Ugh... I was in a hurry and forgot about final statement. Sorry for
that.
No problem.
So we could just use existing solutions if they are compatible with
protocol used by crash.
Daniel
The only existing solution that I know of is:
xl dump-core <Domain> <filename>
crash <filename>
But this way does require disk space, and the delay while writing the
file. For me it took ~2 minutes to write out a 3G core file. I also do
not see the current registers being saved in the core file.
-Don Slutz
4025
days inactive
4060
days old
devel@lists.crash-utility.osci.io
7 comments
4 participants
participants (4)
-
Daniel Kiper -
Dave Anderson -
Don Slutz -
Petr Tesarik