]> xenbits.xensource.com Git - libvirt.git/commitdiff
* src/xend_internal.c src/xml.c: applied patch from Jim Fehlig
authorDaniel Veillard <veillard@redhat.com>
Mon, 10 Apr 2006 08:32:34 +0000 (08:32 +0000)
committerDaniel Veillard <veillard@redhat.com>
Mon, 10 Apr 2006 08:32:34 +0000 (08:32 +0000)
  for lifecycle events
* docs/format.html docs/libvir.html: added the associated docs for
  the new constructs
* TODO: small update
Daniel

ChangeLog
TODO
docs/format.html
docs/libvir.html
src/xend_internal.c
src/xml.c

index f34b2ce9ed515883456c9c4cb5b5a22aeb2ff3b5..97206d5cdc459c1322e29b76cb5e0246a1e7501f 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+Mon Apr 10 09:32:29 CEST 2006 Daniel Veillard <veillard@redhat.com>
+
+       * src/xend_internal.c src/xml.c: applied patch from Jim Fehlig
+         for lifecycle events
+       * docs/format.html docs/libvir.html: added the associated docs for
+         the new constructs
+       * TODO: small update
+
 Sun Apr  9 13:10:34 EDT 2006 Daniel Veillard <veillard@redhat.com>
 
        * TODO src/hash.[ch] src/internal.h src/libvirt.c src/xend_internal.c
diff --git a/TODO b/TODO
index a6c51ab594486f070a738724bbc8b7fa6d168ca3..0055bd36f91db4ee8efee87ab0bc472534078419 100644 (file)
--- a/TODO
+++ b/TODO
@@ -2,7 +2,7 @@ TODO:
 - Create() API, how do we best keep flexibility and allow various
   specific environment and space for evolution (VMX)
 - track change of xend API & XML-RPC
-- API for the Node: extracting informations, selecting scheduling policy
+- API for the Node: selecting scheduling policy
 - better resources allocation APIs (%CPU, set memory)
 - DTD/RNG/XSD schemas for the XML Domain descriptions
 - in python bindings raise an exception if a lookup or connection fails
@@ -31,7 +31,7 @@ Would-be-nice TODO:
 - man page for virsh and the libraries entry points
 - support for QEmu and other virtualization engines
 - more documentation and examples on using the toolkit
-- examples and docs for the principle in the error handling code
+- examples for the error handling code
 
 Cleanup:
 - now that libxml2 is linked in, drop hash.[ch] and get back to libxml2 ones ?
@@ -47,4 +47,6 @@ Done:
 - UUID based lookup and naming
 - Error API similar to libxml2 structured API
 - extract error messages from the Xend rpc
+- API for the Node: extracting informations
+- docs for the principle in the error handling code
 - thread protection, reentrancy, refcounting, etc ...
index f3fe7a6c20fd2e9f90e61d07bcab93a6debb1c76..d0c30125509c09eb019b33b0d01701c06eaf9c6e 100644 (file)
@@ -63,6 +63,22 @@ children in no specific order:</p><ul><li>source: indicating the bridge name</li
   <li>ip: the optional IP address provided in the address attribute</li>
   <li>script: the script used to bridge the interfcae in the Domain 0</li>
   <li>target: and optional target indicating the device name.</li>
-</ul><p>While the format may be extended in various ways as support for more
+</ul><p>Life cycle actions for the domain can also be expressed in the XML format,
+they drive what should be happening if the domain crashes, is rebooted or is
+poweroff. There is various actions possible when this happen:</p><ul><li>destroy: The domain is cleaned up (that's the default normal processing
+    in Xen)</li>
+  <li>restart: A new domain is started in place of the old one with the same
+    configuration parameters</li>
+  <li>preserve: The domain will remain in memory until it is destroyed
+    manually, it won't be running but allows for post-mortem debugging</li>
+  <li>rename-restart: a variant of the previous one but where the old domain
+    is renamed before being saved to allow a restart</li>
+</ul><p>The following could be used for a Xen production system:</p><pre>&lt;domain&gt;
+  ...
+  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
+  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
+  &lt;on_crash&gt;rename-restart&lt;/on_crash&gt;
+  ...
+&lt;/domain&gt;</pre><p>While the format may be extended in various ways as support for more
 hypervisor types and features are added, it is expected that this core subset
 will remain functional in spite of the evolution of the library.</p></div></div><div class="linkList2"><div class="llinks2"><h3 class="links2"><span>main menu</span></h3><ul><li><a href="index.html">Home</a></li><li><a href="news.html">Releases</a></li><li><a href="intro.html">Introduction</a></li><li><a href="architecture.html">libvirt architecture</a></li><li><a href="downloads.html">Downloads</a></li><li><a href="format.html">XML Format</a></li><li><a href="python.html">Binding for Python</a></li><li><a href="errors.html">Handling of errors</a></li><li><a href="FAQ.html">FAQ</a></li><li><a href="bugs.html">Reporting bugs and getting help</a></li><li><a href="html/index.html">API Menu</a></li><li><a href="examples/index.html">C code examples</a></li><li><a href="ChangeLog.html">Recent Changes</a></li></ul></div><div class="llinks2"><h3 class="links2"><span>related links</span></h3><ul><li><a href="https://www.redhat.com/archives/libvir-list/">Mail archive</a></li><li><a href="https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&amp;component=libvirt&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=MODIFIED&amp;short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr">Open bugs</a></li><li><a href="http://hg.berrange.com/libraries/sys-virt">Perl bindings</a></li><li><a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen project</a></li><li><form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><input name="query" type="text" size="12" value="Search..." /><input name="submit" type="submit" value="Go" /></form></li><li><a href="http://xmlsoft.org/"><img src="Libxml2-Logo-90x34.gif" alt="Made with Libxml2 Logo" /></a></li></ul><p class="credits">Graphics and design by <a href="mail:dfong@redhat.com">Diana Fong</a></p></div></div><div id="bottom"><p class="p1"></p></div></div></body></html>
index 594b1b1b7fa635eebc934fc1688d3f0559baf3db..b4886092c15b4ca6f505e4cf90382c561c6b0f31 100644 (file)
@@ -309,6 +309,29 @@ children in no specific order:</p>
   <li>target: and optional target indicating the device name.</li>
 </ul>
 
+<p>Life cycle actions for the domain can also be expressed in the XML format,
+they drive what should be happening if the domain crashes, is rebooted or is
+poweroff. There is various actions possible when this happen:</p>
+<ul>
+  <li>destroy: The domain is cleaned up (that's the default normal processing
+    in Xen)</li>
+  <li>restart: A new domain is started in place of the old one with the same
+    configuration parameters</li>
+  <li>preserve: The domain will remain in memory until it is destroyed
+    manually, it won't be running but allows for post-mortem debugging</li>
+  <li>rename-restart: a variant of the previous one but where the old domain
+    is renamed before being saved to allow a restart</li>
+</ul>
+
+<p>The following could be used for a Xen production system:</p>
+<pre>&lt;domain&gt;
+  ...
+  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
+  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
+  &lt;on_crash&gt;rename-restart&lt;/on_crash&gt;
+  ...
+&lt;/domain&gt;</pre>
+
 <p>While the format may be extended in various ways as support for more
 hypervisor types and features are added, it is expected that this core subset
 will remain functional in spite of the evolution of the library.</p>
index ac2f2f118f1b4db0b6e6941aee6f2de6b3c79734..baa2ed397fc6ecab5146f681ff12c3209c2a01a9 100644 (file)
@@ -1400,6 +1400,16 @@ xend_parse_sexp_desc(struct sexpr *root)
                       (int) (sexpr_u64(root, "domain/maxmem") << 10));
     virBufferVSprintf(&buf, "  <vcpu>%d</vcpu>\n",
                       sexpr_int(root, "domain/vcpus"));
+    tmp = sexpr_node(root, "domain/on_poweroff");
+    if (tmp != NULL)
+       virBufferVSprintf(&buf, "  <on_poweroff>%s</on_poweroff>\n", tmp);
+    tmp = sexpr_node(root, "domain/on_reboot");
+    if (tmp != NULL)
+       virBufferVSprintf(&buf, "  <on_reboot>%s</on_reboot>\n", tmp);
+    tmp = sexpr_node(root, "domain/on_crash");
+    if (tmp != NULL)
+       virBufferVSprintf(&buf, "  <on_crash>%s</on_crash>\n", tmp);
+
     virBufferAdd(&buf, "  <devices>\n", 12);
     for (cur = root; cur->kind == SEXPR_CONS; cur = cur->cdr) {
         node = cur->car;
index 82d67adbf4d0f69d3aa7405289d57aa3a0a48571..c2669dd46b569e0198571bdfba0f36e0ad7bbf75 100644 (file)
--- a/src/xml.c
+++ b/src/xml.c
@@ -877,6 +877,30 @@ virDomainParseXMLDesc(const char *xmldesc, char **name)
     }
     xmlXPathFreeObject(obj);
 
+    obj = xmlXPathEval(BAD_CAST "string(/domain/on_poweroff[1])", ctxt);
+    if ((obj != NULL) && (obj->type == XPATH_STRING) &&
+        (obj->stringval != NULL) && (obj->stringval[0] != 0)) {
+       virBufferVSprintf(&buf, "(on_poweroff '%s')", obj->stringval);
+       bootloader = 1;
+    }
+    xmlXPathFreeObject(obj);
+
+    obj = xmlXPathEval(BAD_CAST "string(/domain/on_reboot[1])", ctxt);
+    if ((obj != NULL) && (obj->type == XPATH_STRING) &&
+        (obj->stringval != NULL) && (obj->stringval[0] != 0)) {
+       virBufferVSprintf(&buf, "(on_reboot '%s')", obj->stringval);
+       bootloader = 1;
+    }
+    xmlXPathFreeObject(obj);
+
+    obj = xmlXPathEval(BAD_CAST "string(/domain/on_crash[1])", ctxt);
+    if ((obj != NULL) && (obj->type == XPATH_STRING) &&
+        (obj->stringval != NULL) && (obj->stringval[0] != 0)) {
+       virBufferVSprintf(&buf, "(on_crash '%s')", obj->stringval);
+       bootloader = 1;
+    }
+    xmlXPathFreeObject(obj);
+
     /* analyze of the os description */
     virBufferAdd(&buf, "(image ", 7);
     obj = xmlXPathEval(BAD_CAST "/domain/os[1]", ctxt);