commit 335fae968928110755ec02422b6463e5676fec93
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Wed Jul 8 10:54:35 2015 -0500
General
- removed Event Loop Integration from the Connections Chapter and created a new
chapter for it
- removed Debugging section from the Connections chapter and created a new chapter
for it
- removed Security Model section from the Connections chapter and created a new
chapter for it
- added the index
en-US/Connections.xml | 137 --------------------
en-US/Debugging.xml | 122 +++++++++++++++++
en-US/Event_Loop_Integration.xml | 15 ++
..._Application_Development_Guide_Using_Python.xml | 4 +
en-US/Security_Model.xml | 15 ++
5 files changed, 156 insertions(+), 137 deletions(-)
---
diff --git a/en-US/Connections.xml b/en-US/Connections.xml
index f46cfcb..b08c64c 100644
--- a/en-US/Connections.xml
+++ b/en-US/Connections.xml
@@ -1195,141 +1195,4 @@ command -p port [-l username] hostname netcat -U socket
</section>
- <section
id="libvirt_application_development_guide_using_python-Connections-Event_Loop">
- <title>Event loop integration</title>
- <indexterm><primary>Event loop
integration</primary></indexterm>
- <para>
- Unlike the libvirt C interface, the Python libvirt module does not provide a
- mechanism for event loop integration. This is a known problem and may be
addressed
- in a future version of the libvirt module.
- </para>
- </section>
-
- <section
id="libvirt_application_development_guide_using_python-Connections-Security">
- <title>Security model</title>
- <indexterm><primary>Security model</primary></indexterm>
- <para>
- Unlike the libvirt C interface, the Python libvirt module does not provide a
- mechanism for accessing the security model. This is a known problem and may
be addressed
- in a future version of the libvirt module.
- </para>
- </section>
-
- <section
id="libvirt_application_development_guide_using_python-Connections-Debug">
- <title>Debugging / logging</title>
- <indexterm><primary>Debugging</primary></indexterm>
- <indexterm><primary>Logging</primary></indexterm>
- <para>
- Libvirt includes logging facilities to facilitate the tracing of library
- execution. These logs will frequently be requested when trying to
- obtain support for libvirt, so familiarity with them is essential.
- </para>
- <para>
- The logging facilities in libvirt are based on 3 key concepts:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Log messages - generated at runtime by the libvirt code, they
include
- a timestamp, a priority level (DEBUG = 1, INFO = 2, WARNING = 3,
ERROR = 4),
- a category, function name and line number indicating where the
- message originated from, and a formatted message.
- </para>
- </listitem>
- <listitem>
- <para>
- Log filters - patterns and priorities which control whether or
- not a particular message is displayed. The format for a filter is:
- </para>
- <para><screen>x:name</screen></para>
- <para>
- where "x" is the minimal priority level where the match
should apply, and
- "name" is a string to match against. The priority levels
are:
- </para>
- <itemizedlist>
- <listitem><para>1 (or debug) - log all
messages</para></listitem>
- <listitem><para>2 (or info) - log all non-debugging
information</para></listitem>
- <listitem><para>3 (or warn) - log only warnings and
errors - this is the default</para></listitem>
- <listitem><para>4 (or error) - log only
errors</para></listitem>
- </itemizedlist>
- <para>
- For instance, to log all debug messages to the qemu driver, the
- following filter can be used:
- </para>
- <para><screen>1:qemu</screen></para>
- <para>
- Multiple filters can be specified together by space separating them;
- the following example logs all debug messages from qemu, and logs
- all error messages from the remote driver:
- </para>
- <para><screen>1:qemu 4:remote</screen></para>
- </listitem>
- <listitem>
- <para>
- Log outputs - where to send the message once it has passed
- through filters. The format for a log output is one of the forms:
- </para>
- <para>
-<screen>x:stderr - log to stderr
-x:syslog:name - log to syslog with a prefix of "name"
-x:file:file_path - log to a file specified by "file_path"</screen>
- </para>
- <para>
- where "x" is the minimal priority level. For instance, to
log all
- warnings and errors to syslog with a prefix of "libvirtd",
the
- following output can be used:
- </para>
- <para><screen>3:syslog:libvirtd</screen></para>
- <para>
- Multiple outputs can be specified by space separating them; the
- following example logs all error and warning messages to syslog, and
- logs all debug, information, warning, and error messages to
- <filename>/tmp/libvirt.log</filename>:
- </para>
- <para><screen>3:syslog:libvirtd
1:file:/tmp/libvirt.log</screen></para>
- </listitem>
- </orderedlist>
-
- <section>
- <title>Environment Variables</title>
- <para>
- The desired log priority level, filters, and outputs are specified to
- the libvirt library through the use of environment variables:
- </para>
- <orderedlist>
- <listitem>
- <para>
- <literal>LIBVIRT_DEBUG</literal> specifies the
minimum priority level messages that
- will be logged. This can be thought of as a "global"
priority level;
- if a particular log message does not match a specific filter in
- <literal>LIBVIRT_LOG_FILTERS</literal>, it will be
compared to this global priority and
- logged as appropriate.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>LIBVIRT_LOG_FILTERS</literal> specifies the
filters to apply.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>LIBVIRT_LOG_OUTPUTS</literal> specifies the
outputs to send the message to.
- </para>
- </listitem>
- </orderedlist>
- <example>
- <title>Running virsh with environment variables</title>
- <para>
- To see more detailed information about what is going on with virsh,
- we may run it like the following:
- </para>
-<screen><command>LIBVIRT_DEBUG=error LIBVIRT_LOG_FILTERS="1:remote"
virsh list</command></screen>
- <para>
- This example will only print error messages from virsh,
<emphasis>except</emphasis> that
- the remote driver will print all debug, information, warning, and
- error messages.
- </para>
- </example>
- </section>
- </section>
</chapter>
diff --git a/en-US/Debugging.xml b/en-US/Debugging.xml
new file mode 100644
index 0000000..e118249
--- /dev/null
+++ b/en-US/Debugging.xml
@@ -0,0 +1,122 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM
"Libvirt_Application_Development_Guide_Using_Python.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="libvirt_application_development_guide_using_python-Debug">
+ <title>Debugging / Logging</title>
+ <indexterm><primary>Debugging</primary></indexterm>
+ <indexterm><primary>Logging</primary></indexterm>
+ <para>
+ Libvirt includes logging facilities to facilitate the tracing of library
+ execution. These logs will frequently be requested when trying to
+ obtain support for libvirt, so familiarity with them is essential.
+ </para>
+ <para>
+ The logging facilities in libvirt are based on 3 key concepts:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Log messages - generated at runtime by the libvirt code, they include
+ a timestamp, a priority level (DEBUG = 1, INFO = 2, WARNING = 3, ERROR =
4),
+ a category, function name and line number indicating where the
+ message originated from, and a formatted message.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Log filters - patterns and priorities which control whether or
+ not a particular message is displayed. The format for a filter is:
+ </para>
+ <para><screen>x:name</screen></para>
+ <para>
+ where "x" is the minimal priority level where the match should
apply, and
+ "name" is a string to match against. The priority levels are:
+ </para>
+ <itemizedlist>
+ <listitem><para>1 (or debug) - log all
messages</para></listitem>
+ <listitem><para>2 (or info) - log all non-debugging
information</para></listitem>
+ <listitem><para>3 (or warn) - log only warnings and errors -
this is the default</para></listitem>
+ <listitem><para>4 (or error) - log only
errors</para></listitem>
+ </itemizedlist>
+ <para>
+ For instance, to log all debug messages to the qemu driver, the
+ following filter can be used:
+ </para>
+ <para><screen>1:qemu</screen></para>
+ <para>
+ Multiple filters can be specified together by space separating them;
+ the following example logs all debug messages from qemu, and logs
+ all error messages from the remote driver:
+ </para>
+ <para><screen>1:qemu 4:remote</screen></para>
+ </listitem>
+ <listitem>
+ <para>
+ Log outputs - where to send the message once it has passed
+ through filters. The format for a log output is one of the forms:
+ </para>
+ <para>
+<screen>x:stderr - log to stderr
+x:syslog:name - log to syslog with a prefix of "name"
+x:file:file_path - log to a file specified by "file_path"</screen>
+ </para>
+ <para>
+ where "x" is the minimal priority level. For instance, to log
all
+ warnings and errors to syslog with a prefix of "libvirtd", the
+ following output can be used:
+ </para>
+ <para><screen>3:syslog:libvirtd</screen></para>
+ <para>
+ Multiple outputs can be specified by space separating them; the
+ following example logs all error and warning messages to syslog, and
+ logs all debug, information, warning, and error messages to
+ <filename>/tmp/libvirt.log</filename>:
+ </para>
+ <para><screen>3:syslog:libvirtd
1:file:/tmp/libvirt.log</screen></para>
+ </listitem>
+ </orderedlist>
+
+ <section>
+ <title>Environment Variables</title>
+ <para>
+ The desired log priority level, filters, and outputs are specified to
+ the libvirt library through the use of environment variables:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ <literal>LIBVIRT_DEBUG</literal> specifies the minimum
priority level messages that
+ will be logged. This can be thought of as a "global"
priority level;
+ if a particular log message does not match a specific filter in
+ <literal>LIBVIRT_LOG_FILTERS</literal>, it will be
compared to this global priority and
+ logged as appropriate.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>LIBVIRT_LOG_FILTERS</literal> specifies the
filters to apply.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>LIBVIRT_LOG_OUTPUTS</literal> specifies the
outputs to send the message to.
+ </para>
+ </listitem>
+ </orderedlist>
+ <example>
+ <title>Running virsh with environment variables</title>
+ <para>
+ To see more detailed information about what is going on with virsh,
+ we may run it like the following:
+ </para>
+<screen><command>LIBVIRT_DEBUG=error LIBVIRT_LOG_FILTERS="1:remote"
virsh list</command></screen>
+ <para>
+ This example will only print error messages from virsh,
<emphasis>except</emphasis> that
+ the remote driver will print all debug, information, warning, and
+ error messages.
+ </para>
+ </example>
+ </section>
+</chapter>
diff --git a/en-US/Event_Loop_Integration.xml b/en-US/Event_Loop_Integration.xml
new file mode 100644
index 0000000..22977f8
--- /dev/null
+++ b/en-US/Event_Loop_Integration.xml
@@ -0,0 +1,15 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM
"Libvirt_Application_Development_Guide_Using_Python.ent">
+%BOOK_ENTITIES;
+]>
+<chapter
id="libvirt_application_development_guide_using_python-Event_Loop">
+ <title>Event Loop Integration</title>
+ <indexterm><primary>Event loop
integration</primary></indexterm>
+ <para>
+ Unlike the libvirt C interface, the Python libvirt module does not provide a
+ mechanism for event loop integration. This is a known problem and may be
addressed
+ in a future version of the libvirt module.
+ </para>
+
+</chapter>
diff --git a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
index 39d4cbb..efe3256 100644
--- a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
+++ b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
@@ -16,5 +16,9 @@
<xi:include href="Host_Devices.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Error_Handling.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Event_Handling.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Event_Loop_Integration.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Security_Model.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Debugging.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Revision_History.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <index></index>
</book>
diff --git a/en-US/Security_Model.xml b/en-US/Security_Model.xml
new file mode 100644
index 0000000..b5d2da7
--- /dev/null
+++ b/en-US/Security_Model.xml
@@ -0,0 +1,15 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM
"Libvirt_Application_Development_Guide_Using_Python.ent">
+%BOOK_ENTITIES;
+]>
+
+<chapter
id="libvirt_application_development_guide_using_python-Security">
+ <title>Security Model</title>
+ <indexterm><primary>Security model</primary></indexterm>
+ <para>
+ Unlike the libvirt C interface, the Python libvirt module does not provide a
+ mechanism for accessing the security model. This is a known problem and may be
addressed
+ in a future version of the libvirt module.
+ </para>
+</chapter>