Skip to contentSkip to conversation

making "xm dump-core" paralell

RFC PATCH In review Rikiya Ayukawa 3 participants 3 messages Sep 27, 2007

lore
Share & tools
lore

Rikiya Ayukawa

author
#0 lore raw

RFC PATCH 1/1 making "xm dump-core" paralell

Hi,

xm has a subcommand "dump-core", which dumps the core image of the domainU to the file.
This subcommand is useful, but it has the problem that xend can't deal with other xm commands while dealing with "dump-core".

The attached patch fixes this problem. ( for cset#15880:a00cc97b392a )

Details of the attached patch are as follows:
- Add xc_dumpcore program. This program only calls xc_domain_dump() in libxc to dump the core image of a domainU.
- Change xend to make a xc_dumpcore process when it deal with "dump-core". the xend's thread which make the process waits for the process to finish dumping the core image.
- Make XendDumpLock to avoid that xend dumps the same domainU twice or more at the same time. XendDumpLock read/write lock informaition of "dump-core" from/to xenstore.
- dump-core has --live and --crash options. These options send requests to pause/unpause, destroy the domainU. I move the code into dumpcore thread because xm cannot use the options well at the sencond dump-core request.

TODO:
- Xend should be fixed not to destory the domainU that it is dumping by "xm destoroy." There are some other xm commands needed this kind of the special care but I don't implement them at this moment yet.
So, for example, if you run "xm dump-core <domid>" and run "xm destroy <same domid>" immediately, I don't know what happen (system may crash).

I would like you to give me comments.
Thank you.

Signed-off-by Rikiya Ayukawa <[email protected]>

Rikiya Ayukawa

tools/python/xen/xend/XendConstants.py +16 -0
diff -r a00cc97b392a -r b7c1cfb4969a tools/python/xen/xend/XendConstants.py
@@ -120,3 +120,19 @@ VTPM_DELETE_SCRIPT = '/etc/xen/scripts/v
 
 XS_VMROOT = "/vm/"
 
+
+#
+# Dumpcore constants
+#
+
+DUMPCORE_REASON_CRASH = "crash"
+DUMPCORE_REASON_XMCOM = "xm dump-core"
+
+# basepath = /local/domain/<domid>/XSPATH_DUMPCORE_BASE/
+XSPATH_DUMPCORE_BASE = "dump_core_lock"
+
+# basepath/XSPATH_DUMPCORE_THREAD_ID
+XSPATH_DUMPCORE_THREAD_ID = "thread_id"
+
+# basepath/XSPATH_DUMPCORE_REASON
+XSPATH_DUMPCORE_REASON = "reason"
tools/python/xen/xend/XendDomain.py +2 -1
diff -r a00cc97b392a -r b7c1cfb4969a tools/python/xen/xend/XendDomain.py
@@ -44,6 +44,7 @@ from xen.xend.XendConstants import DOM_S
 from xen.xend.XendConstants import DOM_STATE_RUNNING, DOM_STATE_SUSPENDED
 from xen.xend.XendConstants import DOM_STATE_SHUTDOWN, DOM_STATE_UNKNOWN
 from xen.xend.XendConstants import TRIGGER_TYPE
+from xen.xend.XendConstants import DUMPCORE_REASON_CRASH, DUMPCORE_REASON_XMCOM
 from xen.xend.XendDevices import XendDevices
 from xen.xend.XendAPIConstants import *
 

@@ -1223,7 +1224,7 @@ class XendDomain:
             log.info("Domain core dump requested for domain %s (%d) "
                      "live=%d crash=%d.",
                      dominfo.getName(), dominfo.getDomid(), live, crash)
-            return dominfo.dumpCore(filename)
+            return dominfo.dumpCore(filename, DUMPCORE_REASON_XMCOM, live, crash)
         except Exception, ex:
             raise XendError(str(ex))
tools/python/xen/xend/XendDomainInfo.py +79 -7

125 lines not on this page · raw message

tools/python/xen/xend/XendDumpLock.py new file +217 -0

217 lines not on this page · raw message

tools/python/xen/xm/main.py +2 -13
diff -r a00cc97b392a -r b7c1cfb4969a tools/python/xen/xm/main.py
@@ -1286,19 +1286,8 @@ def xm_dump_core(args):
     else:
         filename = None
 
-    if not live:
-        server.xend.domain.pause(dom)
-
-    try:
-        print "Dumping core of domain: %s ..." % str(dom)
-        server.xend.domain.dump(dom, filename, live, crash)
-    finally:
-        if not live:
-            server.xend.domain.unpause(dom)
-
-    if crash:
-        print "Destroying domain: %s ..." % str(dom)
-        server.xend.domain.destroy(dom)
+    print "Dumping core of domain: %s ..." % str(dom)
+    server.xend.domain.dump(dom, filename, live, crash)
 
 def xm_rename(args):
     arg_check(args, "rename", 2)
tools/xcutils/Makefile +1 -1
diff -r a00cc97b392a -r b7c1cfb4969a tools/xcutils/Makefile
@@ -22,7 +22,7 @@ CFLAGS += -Wp,-MD,.$(@F).d
 CFLAGS += -Wp,-MD,.$(@F).d
 PROG_DEP = .*.d
 
-PROGRAMS = xc_restore xc_save readnotes
+PROGRAMS = xc_restore xc_save readnotes xc_dumpcore
 
 LDLIBS   = -L$(XEN_LIBXC) -L$(XEN_XENSTORE) -lxenguest -lxenctrl -lxenstore
tools/xcutils/xc_dumpcore.c new file +45 -0

45 lines not on this page · raw message

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#1 lore raw
Quoted 2 lines · Rikiya Ayukawa

- Add xc_dumpcore program. This program only calls xc_domain_dump() in libxc to dump the core image of a domainU.

Why?

regards
john

#2 lore raw
In reply to Rikiya Ayukawa
Quoted 8 lines · Rikiya Ayukawa

Hi,

xm has a subcommand "dump-core", which dumps the core image of the domainU to the file.
This subcommand is useful, but it has the problem that xend can't deal with other xm commands while dealing with "dump-core".

The attached patch fixes this problem. ( for cset#15880:a00cc97b392a )

It seems rather a lot of code to do something which should be quite simple? You seem to have two reasons for doing a dump (xm dump-core, crash), and the locking protocol seems to know about those somehow -- what's that about?

-- Keir