[release-notes] Made space for the boost 1.59.0 uplift, and removed the section about Git for Fedora22
by grundblom
commit e1962f58578b1722c979f4b5ed8582a55429688d
Author: Glen Rundblom <grundblom(a)fedoraproject.org>
Date: Sun Aug 30 21:48:41 2015 -0500
Made space for the boost 1.59.0 uplift, and removed the section about Git for Fedora22
en-US/Development_Tools.xml | 42 +++---------------------------------------
1 files changed, 3 insertions(+), 39 deletions(-)
---
diff --git a/en-US/Development_Tools.xml b/en-US/Development_Tools.xml
index 59c72a7..1f63893 100644
--- a/en-US/Development_Tools.xml
+++ b/en-US/Development_Tools.xml
@@ -22,49 +22,13 @@
</para>
</section>
-<section id="sect-devel-tools-git">
- <title>Git 2.4.0</title>
+<section id="sect-devel-tools-boost">
+ <title>boost 1.59.0</title>
<para>
- Fedora 22 has includes <application>Git 2.4.0</application>. Git is a very popular version control and collaboration tool.
- The previous version of Git was 2.1.0 in Fedora 21.
+ Fedora 23 has includes <application>Boost 1.59.0</application>.
</para>
<para>
New Features:
</para>
- <para>
- <emphasis>git push --atomic</emphasis>
- </para>
- <para>
- New to Git in 2.4 and for Fedora is the <emphasis>atomic</emphasis> option. The <emphasis>--atomic</emphasis> option does an all - or - nothing push update. This can be useful for automated tools.
- An example would be adding <emphasis>--atomic</emphasis> to the end of a simple git push: <command>git push origin --atomic</command>
- For more information on how to do an atomic push please visit <ulink url ="https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more">https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more</ulink>.
- </para>
- <para>
- <emphasis>Push to Deploy</emphasis>
- </para>
- <para>
- Introduced in Git 2.3.0 and new to Fedora is the ability to push to deploy. This feature will allow someone to push a branch to a git server even if the branch is checked out on that server.
- </para>
- <para>
- <emphasis>Inverted Grep</emphasis>
- </para>
- <para>
- Inverted grep, or <command>--inverted grep</command> will let you search for items that do not match the pattern you have entered.
- Inverted grep will give the ability to do "everything else but" searching. For example, if you wanted to search the git log for everything the user grundblom did that was not grammer edits
- You could use the command: <command>git log --all --author=grundblom --invert-grep --grep=grammer </command>
- </para>
- <para>
- Other enhancements and updates have been made in the following areas:
- </para>
- <itemizedlist>
- <listitem><para>Ports</para></listitem>
- <listitem><para>UI, Workflows, and Features</para></listitem>
- <listitem><para>Performance</para></listitem>
- <listitem><para>Internal Implementation</para></listitem>
- <listitem><para>Development Support</para></listitem>
- </itemizedlist>
- <para>
- For more information about <application>Git 2.4.0</application>, please visit the release notes at: <ulink url="https://raw.github.com/git/git/master/Documentation/RelNotes/2.4.0.txt">https://raw.github.com/git/git/master/Documentation/RelNotes/2.4.0.txt</ulink>.
- </para>
</section>
</section>
\ No newline at end of file
--
docs-commits mailing list
docs-commits(a)lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/docs-commits@lists.fedoraproject...
8 years
[libvirt_application_development_guide_using_python] All chapters - added index entries - imporved a few sentences - replaced the content of the Secur
by David Ashley
commit c1949e0b68ce13f73a1ad69c509f6f4cc9a8d88a
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Sat Aug 22 20:24:39 2015 -0500
All chapters
- added index entries
- imporved a few sentences
- replaced the content of the Security chapter (to be updated again later)
en-US/Book_Info.xml | 2 +-
en-US/Connections.xml | 7 ++++-
en-US/Debugging.xml | 2 +
en-US/Error_Handling.xml | 9 +++++++
en-US/Event_Handling.xml | 18 +++++++++++++++
en-US/Guest_Domains.xml | 41 +++++++++++++++++++++++++++++++++--
en-US/Network_Interfaces.xml | 30 +++++++++++++++++++++++++-
en-US/Revision_History.xml | 8 +++---
en-US/Security_Model.xml | 11 +++++++--
en-US/Storage_Pools.xml | 48 +++++++++++++++++++++++++++++++++++++++++-
en-US/Virtual_Networks.xml | 40 +++++++++++++++++++++++++++++++++++
11 files changed, 201 insertions(+), 15 deletions(-)
---
diff --git a/en-US/Book_Info.xml b/en-US/Book_Info.xml
index cdffd8a..84d5f25 100644
--- a/en-US/Book_Info.xml
+++ b/en-US/Book_Info.xml
@@ -7,7 +7,7 @@
<title>Libvirt Application Development Guide Using Python</title>
<subtitle>A guide to libvirt application development with Python</subtitle>
<productname>Documentation</productname>
- <productnumber>0.1</productnumber>
+ <productnumber>1.0</productnumber>
<edition>1</edition>
<pubsnumber>1</pubsnumber>
<abstract>
diff --git a/en-US/Connections.xml b/en-US/Connections.xml
index d42adff..b1cc17b 100644
--- a/en-US/Connections.xml
+++ b/en-US/Connections.xml
@@ -18,9 +18,12 @@
</para>
<section id="libvirt_application_development_guide_using_python-Connections-Overview">
<title>Overview</title>
+ <indexterm><primary>virInitialize</primary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virInitialize</secondary></indexterm>
<para>
- The very first thing a libvirt agent must do is call one of the
- Python libvirt connection functions to obtain an instance of the <literal>virConnect</literal>
+ The very first thing a libvirt agent must do is call the <literal>virInitialize</literal> function, or
+ one of the Python libvirt connection functions to obtain an instance of the <literal>virConnect</literal>
class. This instance will be used in subsequent operations. The Python libvirt module
provides 3 different functions for connecting to a resource:
</para>
diff --git a/en-US/Debugging.xml b/en-US/Debugging.xml
index e118249..01da318 100644
--- a/en-US/Debugging.xml
+++ b/en-US/Debugging.xml
@@ -80,6 +80,8 @@ x:file:file_path - log to a file specified by "file_path"</screen>
<section>
<title>Environment Variables</title>
+ <indexterm><primary>Environment variables, debugging</primary></indexterm>
+ <indexterm><primary>Debugging environment variables</primary></indexterm>
<para>
The desired log priority level, filters, and outputs are specified to
the libvirt library through the use of environment variables:
diff --git a/en-US/Error_Handling.xml b/en-US/Error_Handling.xml
index 543e7b3..ac3186e 100644
--- a/en-US/Error_Handling.xml
+++ b/en-US/Error_Handling.xml
@@ -5,6 +5,7 @@
]>
<chapter id="libvirt_application_development_guide_using_python-Error_Handling">
<title>Error Handling</title>
+ <indexterm><primary>Error handling</primary></indexterm>
<para>
The libvirt error functions are designed to give more detailed information
about what caused a failure in the case that a normal libvirt function or method
@@ -79,6 +80,9 @@
<section id="libvirt_application_development_guide_using_python-Error_Handling-virGetLastError">
<title>virGetLastError</title>
+ <indexterm><primary>virGetLastError</primary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virGetLastError</secondary></indexterm>
<para>
The <literal>virGetLastError</literal> function can be used to obtain a
Python <literal>list</literal> that contains all the information
@@ -97,6 +101,7 @@
<section id="libvirt_application_development_guide_using_python-Error_Handling-Subclassing_virError">
<title>Subclassing virError</title>
+ <indexterm><primary>virError class</primary></indexterm>
<para>
It is possible to subclass the <literal>virtError</literal> class to add functionality.
The default <literal>virError</literal> does not provide any ability to either save the error
@@ -112,6 +117,9 @@
<section id="libvirt_application_development_guide_using_python-Error_Handling-Registering_Error_Handler">
<title>Registering an Error Handler Function</title>
+ <indexterm><primary>registerErrorHandler</primary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>registerErrorHandler</secondary></indexterm>
<para>
Libvirt also supports setting up an error handler function. This is done using the libvirt
function <literal>registerErrorHandler</literal>.
@@ -119,6 +127,7 @@
</para>
<example>
<title>Subclassing virError</title>
+ <indexterm><primary>subclassing the virError class</primary></indexterm>
<programlisting language="Python"><xi:include href="extras/Error-Example-26.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
</example>
</section>
diff --git a/en-US/Event_Handling.xml b/en-US/Event_Handling.xml
index 2d050cd..621ee65 100644
--- a/en-US/Event_Handling.xml
+++ b/en-US/Event_Handling.xml
@@ -5,6 +5,24 @@
]>
<chapter id="libvirt_application_development_guide_using_python-Events_and_Timers">
<title>Event and Timer Handling</title>
+ <indexterm><primary>virEventAddHandle</primary></indexterm>
+ <indexterm><primary>virEventRegisterDefaultImpl</primary></indexterm>
+ <indexterm><primary>virEventRegisterImpl</primary></indexterm>
+ <indexterm><primary>virEventRemoveHandle</primary></indexterm>
+ <indexterm><primary>virEventRunDefaultImpl</primary></indexterm>
+ <indexterm><primary>virEventUpdateHandle</primary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventUpdateHandle</secondary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventRunDefaultImpl</secondary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventRemoveHandle</secondary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventRegisterDefaultImpl</secondary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventRegisterImpl</secondary></indexterm>
+ <indexterm><primary>Functions</primary>
+ <secondary>virEventAddHandle</secondary></indexterm>
<para>
The Python libvirt module provides a complete interface for handling both events and timers.
Both event and timer handling are invoked through a function interface as opposed to a
diff --git a/en-US/Guest_Domains.xml b/en-US/Guest_Domains.xml
index 0ced651..5567bd6 100644
--- a/en-US/Guest_Domains.xml
+++ b/en-US/Guest_Domains.xml
@@ -178,7 +178,7 @@
</para>
<para>
The <literal>listAllDomains</literal> method takes a single parameter which is a flag specifying
- a filter for the domains to be listed. If a value of <code>0</code> is specified then all
+ a filter for the domains to be listed. If a value of <code language="Python">0</code> is specified then all
domains will be listed. Otherwise any or all of the following constants can be added together
to create a filter for the domains to be listed.
</para>
@@ -624,6 +624,12 @@
<title>Stopping</title>
<indexterm><primary>Stopping a domain</primary></indexterm>
<indexterm><primary>Domain, stopping a</primary></indexterm>
+ <indexterm><primary>shutdown</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>shutdown</secondary></indexterm>
+ <indexterm><primary>destroy</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>destroy</secondary></indexterm>
<para>
Stopping refers to the process of halting a running guest. A guest can be stopped by two methods:
shutdown and destroy.
@@ -727,6 +733,12 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Migration">
<title>Migration</title>
<indexterm><primary>Migration, domain</primary></indexterm>
+ <indexterm><primary>migrate</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>migrate</secondary></indexterm>
+ <indexterm><primary>migrateToURI</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>migrateToURI</secondary></indexterm>
<para>
<indexterm><primary>migrate</primary></indexterm>
@@ -822,6 +834,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Autostart">
<title>Autostart</title>
<indexterm><primary>Autostart</primary></indexterm>
+ <indexterm><primary>autostart</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>autostart</secondary></indexterm>
<para>
<indexterm><primary>setAutostart</primary></indexterm>
@@ -844,8 +859,8 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Domain_Config">
<title>Domain Configuration</title>
- <indexterm><primary>Domain configuration</primary></indexterm>
- <indexterm><primary>Configuration, domain</primary></indexterm>
+ <indexterm><primary>Domain XML configuration</primary></indexterm>
+ <indexterm><primary>Configuration, domain XML</primary></indexterm>
<para>
Domains are defined in libvirt using XML. Everything related only to the domain, such as
@@ -922,6 +937,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Monitoring-Domain_Block">
<title>Domain Block Device Performance</title>
+ <indexterm><primary>blockStats</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>blockStats</secondary></indexterm>
<para>
Disk usage statistics are provided by the
@@ -943,6 +961,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Monitoring-vCPU">
<title>vCPU Performance</title>
+ <indexterm><primary>getCPUStats</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>getCPUStats</secondary></indexterm>
<para>
To obtain the individual VCPU statistics use the <literal>getCPUStats</literal> method.
@@ -971,6 +992,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Monitoring-Memory">
<title>Memory Statistics</title>
+ <indexterm><primary>memoryStats</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>memoryStats</secondary></indexterm>
<para>
To obtain the amount of memory currently used by the domain you can use the
@@ -989,6 +1013,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Monitoring-IO_stats">
<title>I/O Statistics</title>
+ <indexterm><primary>interfaceStats</primary></indexterm>
+ <indexterm><primary>Domains</primary>
+ <secondary>interfaceStats</secondary></indexterm>
<para>
To get the network statistics, you'll need the name
@@ -1059,6 +1086,7 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Device_Config-Disks">
<title>Disks</title>
+ <indexterm><primary>Disk configuration</primary></indexterm>
<para>
To discover the guest domain's disk(s) find and display the content of the disk XML tag(s).
@@ -1079,6 +1107,7 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Device_Config-Networking">
<title>Networking</title>
+ <indexterm><primary>Networking configuration</primary></indexterm>
<para>
To discover the guest domain's network interfaces find and display the interface XML tag.
@@ -1099,6 +1128,9 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Device_Config-Mice">
<title>Mice, Keyboard & Tablets</title>
+ <indexterm><primary>Mice configuration</primary></indexterm>
+ <indexterm><primary>Keyboard configuration</primary></indexterm>
+ <indexterm><primary>Tablets configuration</primary></indexterm>
<para>
To discover the guest domain's input devices find and display the input XML tags.
@@ -1119,6 +1151,8 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Device_Config-USB_Pass">
<title>USB Device Passthrough</title>
+ <indexterm><primary>USB passthrough</primary></indexterm>
+ <indexterm><primary>USB configuration</primary></indexterm>
<para>
The USB device passthrough capability allows a physical USB device from
@@ -1147,6 +1181,7 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Device_Config-PCI_Pass">
<title>PCI device passthrough</title>
<indexterm><primary>PCI device passthrough</primary></indexterm>
+ <indexterm><primary>PCI configuration</primary></indexterm>
<para>
The PCI device passthrough capability allows a physical PCI device from
diff --git a/en-US/Network_Interfaces.xml b/en-US/Network_Interfaces.xml
index beb1c1c..46ff5ec 100644
--- a/en-US/Network_Interfaces.xml
+++ b/en-US/Network_Interfaces.xml
@@ -64,6 +64,7 @@
<section id="libvirt_application_development_guide_using_python-Network_Interfaces-XML_Format">
<title>XML Interface Description Format</title>
+ <indexterm><primary>interface XML configuration</primary></indexterm>
<para>
The current Relax NG definition of the XML that is produced and accepted
by <literal>interfaceDefineXML</literal> and <literal>XMLDesc</literal> can be found in the
@@ -96,6 +97,18 @@
<section id="libvirt_application_development_guide_using_python-Network_Interfaces-Information-Listing">
<title>Enumerating Interfaces</title>
+ <indexterm><primary>numOfInterfaces</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>numOfInterfaces</secondary></indexterm>
+ <indexterm><primary>numOfDefinedInterfaces</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>numOfDefinedInterfaces</secondary></indexterm>
+ <indexterm><primary>listInterfaces</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>listInterfaces</secondary></indexterm>
+ <indexterm><primary>listDefinedInterfaces</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>listDefinedInterfaces</secondary></indexterm>
<para>
Once you have a connection to a host you can determine
the number of interfaces on the host with <literal>numOfInterfaces</literal>
@@ -181,6 +194,12 @@
<section id="libvirt_application_development_guide_using_python-Network_Interfaces-Configs-Define">
<title>Defining an interface configuration</title>
+ <indexterm><primary>interfaceDefineXML</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>interfaceDefineXML</secondary></indexterm>
+ <indexterm><primary>create</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>create</secondary></indexterm>
<para>
The <literal>interfaceDefineXML</literal> method is used for both adding new interface configurations
and modifying existing configurations. It either adds a new interface
@@ -198,7 +217,7 @@
for example making it active with <literal>create</literal>.
</para>
<para>
- Currently the flags parameter should always be <code>0</code>.
+ Currently the flags parameter should always be <code language="Python">0</code>.
</para>
<example id="Example-Defining_a_new_interface">
<title>Defining a new interface</title>
@@ -208,6 +227,12 @@
<section id="libvirt_application_development_guide_using_python-Network_Interfaces-Configs-Undefine">
<title>Undefining an interface configuration</title>
+ <indexterm><primary>undefine</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>undefine</secondary></indexterm>
+ <indexterm><primary>XMLDesc</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>XMLDesc</secondary></indexterm>
<para>
The <literal>undefine</literal> method completely and permanently removes the
configuration for the given interface from the host's configuration
@@ -244,6 +269,9 @@
<section id="libvirt_application_development_guide_using_python-Network_Interfaces-Lifecycle-Deactivate">
<title>Deactivating an interface</title>
+ <indexterm><primary>destroy</primary></indexterm>
+ <indexterm><primary>Interfaces</primary>
+ <secondary>destroy</secondary></indexterm>
<para>
The <literal>destroy</literal> method makes the given interface inactive ("down"). On
success, it returns 0. If there is any problem making the interface
diff --git a/en-US/Revision_History.xml b/en-US/Revision_History.xml
index f705fd9..19a2047 100644
--- a/en-US/Revision_History.xml
+++ b/en-US/Revision_History.xml
@@ -8,16 +8,16 @@
<simpara>
<revhistory>
<revision>
- <revnumber>0</revnumber>
- <date>Wed Jun 24 2015</date>
+ <revnumber>1.0-1</revnumber>
+ <date>Sat Aug 22 2015</date>
<author>
<firstname>W. David</firstname>
<surname>Ashley</surname>
- <email>dashley(a)gmail.com</email>
+ <email>w.david.ashley(a)gmail.com</email>
</author>
<revdescription>
<simplelist>
- <member>Import from the libvirt git repository with fedora document style changes.</member>
+ <member>Initial release to the Fedora Documentation Project.</member>
</simplelist>
</revdescription>
</revision>
diff --git a/en-US/Security_Model.xml b/en-US/Security_Model.xml
index b5d2da7..a3ab129 100644
--- a/en-US/Security_Model.xml
+++ b/en-US/Security_Model.xml
@@ -8,8 +8,13 @@
<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.
+ While the Python modules supplies full access to the security and secret methods, this topic is
+ currently beyond the scope of this guide. You can look up the security and secret methods by
+ running the following command.
+ </para>
+ <programlisting language="Python">pydoc libvirt</programlisting>
+ <para>
+ This will give you a manpage of the Python classes, methods and functions available specific
+ to your Linux distribution.
</para>
</chapter>
diff --git a/en-US/Storage_Pools.xml b/en-US/Storage_Pools.xml
index c128c9d..8e409d0 100644
--- a/en-US/Storage_Pools.xml
+++ b/en-US/Storage_Pools.xml
@@ -5,6 +5,7 @@
]>
<chapter id="libvirt_application_development_guide_using_python-Storage_Pools">
<title>Storage Pools</title>
+ <indexterm><primary>storage pools</primary></indexterm>
<para>
Libvirt provides storage management on the physical host through storage pools and volumes.
</para>
@@ -84,6 +85,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Listingt">
<title>Listing pools</title>
+ <indexterm><primary>listAllStoragePools</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>listAllStoragePools</secondary></indexterm>
<para>
A list of storage pool objects can be obtained using the <literal>listAllStoragePools</literal> method of the
<literal>virConnect</literal> class.
@@ -136,10 +140,16 @@
started if the <literal>autostart</literal> is not set.
</para>
<para>
+ <indexterm><primary>isActive</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>isActive</secondary></indexterm>
The <literal>isActive</literal> method indicates whether or not the user must activate the storage
pool in some way. The <literal>create</literal> method can activate a storage pool.
</para>
<para>
+ <indexterm><primary>isPersistent</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>isPersistent</secondary></indexterm>
The <literal>isPersistent</literal> method indicates whether or not a storage pool needs to be activated
using <literal>create</literal> method. A value of 1 indicates that the storage pool is persistent
and will remain on the file system after it is released.
@@ -162,6 +172,15 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Lifecycle">
<title>Lifecycle control</title>
<para>
+ <indexterm><primary>storagePoolDefineXML</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>storagePoolDefineXML</secondary></indexterm>
+ <indexterm><primary>storagePoolCreateXML</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>storagePoolCreateXML</secondary></indexterm>
+ <indexterm><primary>undefine</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>undefine</secondary></indexterm>
The following example shows how to create and destroy both a persistent and a
non-persistent storage pool. Note that a storage pool can not be destroyed if
it is in a active state. By default storage pools are created in a inactive state.
@@ -171,6 +190,9 @@
<programlisting language="Python"><xi:include href="extras/StoragePools-Example-4.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
</example>
<para>
+ <indexterm><primary>delete</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>delete</secondary></indexterm>
Note that the storage volumes defined in a storage pool will remain on the file system
unless the <literal>delete</literal> method is called. But be careful about leaving storage
volumes in place because if they exist on a remote file system or disk then that file system
@@ -181,13 +203,19 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Discover_Sources">
<title>Discovering pool sources</title>
+ <indexterm><primary>storagePoolLookupByName</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>storagePoolLookupByName</secondary></indexterm>
+ <indexterm><primary>XMLDesc</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>XMLDesc</secondary></indexterm>
<para>
The sources for a storage pool's sources can be discovered by examining the pool's XML
description. An example program follows that prints out a pools source description attributes.
</para>
<para>
Currently the flags parameter for the <literal>storagePoolCreateXML</literal> method
- should always be <code>0</code>.
+ should always be <code language="Python">0</code>.
</para>
<example>
<title>Discover a storage pool's sources</title>
@@ -197,6 +225,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Pool_Config">
<title>Pool configuration</title>
+ <indexterm><primary>setAutostart</primary></indexterm>
+ <indexterm><primary>Storage pools</primary>
+ <secondary>setAutostart</secondary></indexterm>
<para>
There are a number of methods which can configure aspects of a storage pool. The main method
is the <literal>setAutostart</literal> method.
@@ -219,6 +250,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Listing">
<title>Listing volumes</title>
+ <indexterm><primary>listVolumes</primary></indexterm>
+ <indexterm><primary>Storage volumes</primary>
+ <secondary>listVolumes</secondary></indexterm>
<para>
The following example program demonstrates how to list all the storage volumes contained by the
"default" storage pool.
@@ -231,6 +265,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Vol_Info">
<title>Volume information</title>
+ <indexterm><primary>info</primary></indexterm>
+ <indexterm><primary>Storage volumes</primary>
+ <secondary>info</secondary></indexterm>
<para>
Information about a storage volume is obtained by using the <literal>info</literal> method. The
following program shows how to list the information about each storage volume in the
@@ -244,6 +281,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Create_Remove">
<title>Creating and deleting volumes</title>
+ <indexterm><primary>createXML</primary></indexterm>
+ <indexterm><primary>Storage volumes</primary>
+ <secondary>createXML</secondary></indexterm>
<para>
Storage volumes are created using the storage pool <literal>createXML</literal> method. The type
and attributes of the storage volume are specified in the XML passed to the
@@ -264,6 +304,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Cloning">
<title>Cloning volumes</title>
+ <indexterm><primary>createXML</primary></indexterm>
+ <indexterm><primary>Storage volumes</primary>
+ <secondary>createXML</secondary></indexterm>
<para>
Cloning a storage volume is similar to creating a new storage volume, except that an existing
storage volume is used for most of the attributes. Only the name and permissions in the XML
@@ -282,6 +325,9 @@
<section id="libvirt_application_development_guide_using_python-Storage_Pools-Config_Vol">
<title>Configuring volumes</title>
+ <indexterm><primary>createXMLFrom</primary></indexterm>
+ <indexterm><primary>Storage volumes</primary>
+ <secondary>createXMLFrom</secondary></indexterm>
<para>
The following is an XML description for a storage volume.
</para>
diff --git a/en-US/Virtual_Networks.xml b/en-US/Virtual_Networks.xml
index ab72fa5..448cd74 100644
--- a/en-US/Virtual_Networks.xml
+++ b/en-US/Virtual_Networks.xml
@@ -5,6 +5,7 @@
]>
<chapter id="libvirt_application_development_guide_using_python-Virtual_Networks">
<title>Virtual Networks</title>
+ <indexterm><primary>Storage networks</primary></indexterm>
<section id="libvirt_application_development_guide_using_python-Virtual_Networks-Overview">
<title>Overview</title>
@@ -63,6 +64,21 @@
<section id="libvirt_application_development_guide_using_python-Virtual_Networks-Listing">
<title>Listing networks</title>
+ <indexterm><primary>networkLookupByName</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkLookupByName</secondary></indexterm>
+ <indexterm><primary>networkLookupByUUID</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkLookupByUUID</secondary></indexterm>
+ <indexterm><primary>networkLookupByUUIDString</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkLookupByUUIDString</secondary></indexterm>
+ <indexterm><primary>networkLookupByUUIDString</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkLookupByUUIDString</secondary></indexterm>
+ <indexterm><primary>listNetworks</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>listNetworks</secondary></indexterm>
<para>
Virtual networks are discovered using the methods <literal>networkLookupByName</literal>,
<literal>networkLookupByUUID</literal>, and <literal>networkLookupByUUIDString</literal>
@@ -76,6 +92,15 @@
<section id="libvirt_application_development_guide_using_python-Virtual_Networks-Lifecycle">
<title>Lifecycle control</title>
+ <indexterm><primary>networkCreateXML</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkCreateXML</secondary></indexterm>
+ <indexterm><primary>networkDefineXML</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>networkDefineXML</secondary></indexterm>
+ <indexterm><primary>destroy</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>destroy</secondary></indexterm>
<para>
The following example shows how to use the <literal>networkCreateXML</literal>,
<literal>networkDefineXML</literal> and the <literal>destroy</literal> methods.
@@ -88,6 +113,21 @@
<section id="libvirt_application_development_guide_using_python-Virtual_Networks-Config">
<title>Network configuration</title>
+ <indexterm><primary>XMLDesc</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>XMLDesc</secondary></indexterm>
+ <indexterm><primary>autostart</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>autostart</secondary></indexterm>
+ <indexterm><primary>isActive</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>isActive</secondary></indexterm>
+ <indexterm><primary>isPersistent</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>isPersistent</secondary></indexterm>
+ <indexterm><primary>setAutostart</primary></indexterm>
+ <indexterm><primary>Storage networks</primary>
+ <secondary>setAutostart</secondary></indexterm>
<para>
The following example shows how to use the <literal>XMLDesc</literal>, <literal>autostart</literal>,
<literal>isActive</literal>, <literal>isPersistent</literal> and the <literal>setAutostart</literal>
--
docs-commits mailing list
docs-commits(a)lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/docs-commits@lists.fedoraproject...
8 years, 1 month
[libvirt_application_development_guide_using_python] Various chapters - spell checked the entire document once more.
by David Ashley
commit 52b00f1902ee92183c61f57bbc971caab5156c69
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Thu Aug 20 14:43:03 2015 -0500
Various chapters
- spell checked the entire document once more.
en-US/Architecture.xml | 2 +-
en-US/Connections.xml | 14 +++++++-------
en-US/Guest_Domains.xml | 16 ++++++++--------
en-US/Virtual_Networks.xml | 4 ++--
4 files changed, 18 insertions(+), 18 deletions(-)
---
diff --git a/en-US/Architecture.xml b/en-US/Architecture.xml
index 4f13933..6c60374 100644
--- a/en-US/Architecture.xml
+++ b/en-US/Architecture.xml
@@ -142,7 +142,7 @@
<para>
A virtual network may be transient or persistent. A transient virtual network can only be
- managed while it it is running on the host. When taken offline, all traces of it will disappear. A persistent virtual network has its configuration maintained in a data store on the host, in an implementation defined format. Thus when a persistent network is brought offline, it is still possible to manage its inactive config. A transient network can be turned into a persistent network on the fly by defining a configuration for it.
+ managed while it is running on the host. When taken offline, all traces of it will disappear. A persistent virtual network has its configuration maintained in a data store on the host, in an implementation defined format. Thus when a persistent network is brought offline, it is still possible to manage its inactive config. A transient network can be turned into a persistent network on the fly by defining a configuration for it.
</para>
<para>
diff --git a/en-US/Connections.xml b/en-US/Connections.xml
index e613772..d42adff 100644
--- a/en-US/Connections.xml
+++ b/en-US/Connections.xml
@@ -103,7 +103,7 @@ conn = libvirt.openReadOnly(name)</programlisting>
<secondary>openAuth</secondary></indexterm>
<para>
The <literal>openAuth</literal> function is the most flexible, and effectively
- obsoletes the previous two cunctions. It takes an extra parameter providing
+ obsoletes the previous two functions. It takes an extra parameter providing
an Python <literal>list</literal> which contains the authentication credentials from the
client app. The flags parameter allows
the application to request a read-only connection with the
@@ -249,7 +249,7 @@ driver+unix:///session</screen>
</entry>
<entry>
<para>
- For for managing UML guests
+ For managing UML guests
</para>
</entry>
</row>
@@ -299,7 +299,7 @@ driver+unix:///session</screen>
</entry>
<entry>
<para>
- For mmanaging OpenNebula guests
+ For managing OpenNebula guests
</para>
</entry>
</row>
@@ -1067,9 +1067,9 @@ command -p port [-l username] hostname netcat -U socket
<para>
The <command>getCellsFreeMemory</command> method can be used to obtain the
amount of free memory (in kilobytes) in some or all of the NUMA
- nodes in the system. It takes as input thet starting cell
+ nodes in the system. It takes as input the starting cell
and the maximum number of cells to retrieve data from.
- If successful, aPython <literal>list</literal> is returned with the
+ If successful, Python <literal>list</literal> is returned with the
amount of free memory in each node.
On failure <literal>None</literal> is returned. The following code
demonstrates the use of <command>getCellsFreeMemory</command>:
@@ -1124,7 +1124,7 @@ command -p port [-l username] hostname netcat -U socket
<para>
The <command>getLibVersion</command> method can be used to obtain the version of
the libvirt software in use on the host.
- If successful it retirns a Python string with the version, otherwise it returns
+ If successful it returns a Python string with the version, otherwise it returns
<literal>None</literal>. The following code demonstrates the
use of <command>getLibVersion</command>:
</para>
@@ -1181,7 +1181,7 @@ command -p port [-l username] hostname netcat -U socket
The <command>isSecure</command> method can be used to find out if a given
connection is encrypted. A connection will be classified secure if
it is either encrypted or it is running on a channel which is not
- vulnerable to eavsdropping (like a UNIX domain socket).
+ vulnerable to eavesdropping (like a UNIX domain socket).
If successful it returns 1 for a
secure connection and 0 for an insecure connection. If an error
occurred, -1 will be returned. The following code demonstrates the use
diff --git a/en-US/Guest_Domains.xml b/en-US/Guest_Domains.xml
index 859fdca..0ced651 100644
--- a/en-US/Guest_Domains.xml
+++ b/en-US/Guest_Domains.xml
@@ -631,9 +631,9 @@
<para>
The <literal>shutdown</literal> method is a clean stop process, which sends a signal to the guest domain operating system
asking it to shut down immediately. The guest will only be stopped once the operating system
- has successfuly shut down. The shutdown process is analagous to running a shutdown command on
+ has successfully shut down. The shutdown process is analogous to running a shutdown command on
a physical machine. There is also a <literal>shutdownFlags</literal> method which can, depending
- on what the guest OS supports, can shudoown the domain and leave the objct in a usable state.
+ on what the guest OS supports, can shutdown the domain and leave the object in a usable state.
</para>
<para>
The <literal>destroy</literal> method immediately terminates the guest domain. The destroy process is analogous to pulling
@@ -657,7 +657,7 @@
<secondary>resume</secondary></indexterm>
the <literal>suspend</literal> and <literal>resume</literal> methods refer to the process of taking a running guest and
temporarily saving its memory state. At a later time, it is possible to resume the guest
- to its original running state, contiuining execution where it left off. Suspend does not
+ to its original running state, continuingly execution where it left off. Suspend does not
save a persistent image of the guest's memory. For this, <literal>save</literal> is used.
</para>
<para>
@@ -745,7 +745,7 @@
complete successfully, storage needs to be shared between the source and target hypervisors.
</para>
<para>
- The first parameter of the <literal>migrate</literal> method specifies the connectiion to be used to the
+ The first parameter of the <literal>migrate</literal> method specifies the connection to be used to the
target of the migration. This parameter is required.
</para>
<para>
@@ -772,7 +772,7 @@
<para>
The third parameter of the <literal>migrate</literal> method specifies a new name for the domain on the target
of the migration. Not all hypervisors support this operation. If no rename of the domain is
- required then the parameter shoule be set to <literal>None</literal>.
+ required then the parameter should be set to <literal>None</literal>.
</para>
<para>
The third parameter of the <literal>migrate</literal> method specifies a new name for the domain on the target
@@ -782,7 +782,7 @@
<para>
The forth parameter of the <literal>migrate</literal> method specifies the URI to be used as the
target of the migration. A URI is only required when the target system supports multiple
- hypervisors. If ther is only a single hypervisor on the target system then
+ hypervisors. If there is only a single hypervisor on the target system then
the parameter can be set to <literal>None</literal>.
</para>
<para>
@@ -1017,7 +1017,7 @@
<para>
Configuration information for a guest domain can be obtained by using the <literal>XMLDesc</literal>
method. This method returns the current description of a domain as an XML data stream.
- This stream can then be parsed to obtain detailed information about the doamin and all the
+ This stream can then be parsed to obtain detailed information about the domain and all the
parts that make up the domain.
</para>
<para>
@@ -1081,7 +1081,7 @@
<title>Networking</title>
<para>
- To discover the guest domain's network interfaces find and display the iterface XML tag.
+ To discover the guest domain's network interfaces find and display the interface XML tag.
</para>
<example>
<title>Get domain's network interface information</title>
diff --git a/en-US/Virtual_Networks.xml b/en-US/Virtual_Networks.xml
index 217ccec..ab72fa5 100644
--- a/en-US/Virtual_Networks.xml
+++ b/en-US/Virtual_Networks.xml
@@ -47,7 +47,7 @@
</itemizedlist>
<para>
A virtual network may be transient or persistent. A transient virtual network can only be managed
- while it it is running on the host. When taken offline, all trace of it will disappear. A persistent
+ while it is running on the host. When taken offline, all trace of it will disappear. A persistent
virtual network has its configuration maintained in a data store on the host, in an implementation
defined format. Thus when a persistent network is brought offline, it is still possible to manage its
inactive config. A transient network can be turned into a persistent network on the fly by defining a
@@ -66,7 +66,7 @@
<para>
Virtual networks are discovered using the methods <literal>networkLookupByName</literal>,
<literal>networkLookupByUUID</literal>, and <literal>networkLookupByUUIDString</literal>
- and <literal>listNetworks</literal>. The following example shws how to used these methods.
+ and <literal>listNetworks</literal>. The following example shows how to used these methods.
</para>
<example>
<title>Discovering and finding virtual networks</title>
8 years, 1 month
[libvirt_application_development_guide_using_python] Various chapters - added information for flags parameters - ficed a few spelling errors
by David Ashley
commit 82e8bf90026f70f3b977768f0ba3c8a25c1d31a1
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Thu Aug 20 14:08:38 2015 -0500
Various chapters
- added information for flags parameters
- ficed a few spelling errors
en-US/Guest_Domains.xml | 52 +++++++++++++++++++++++++++++++++++++++--
en-US/Network_Interfaces.xml | 4 ++-
en-US/Storage_Pools.xml | 40 ++++++++++++++++++++++++++++++++
3 files changed, 92 insertions(+), 4 deletions(-)
---
diff --git a/en-US/Guest_Domains.xml b/en-US/Guest_Domains.xml
index 230ef36..859fdca 100644
--- a/en-US/Guest_Domains.xml
+++ b/en-US/Guest_Domains.xml
@@ -176,7 +176,28 @@
upon an error. The <literal>list</literal> can be empty when no persistent domains
exist.
</para>
-
+ <para>
+ The <literal>listAllDomains</literal> method takes a single parameter which is a flag specifying
+ a filter for the domains to be listed. If a value of <code>0</code> is specified then all
+ domains will be listed. Otherwise any or all of the following constants can be added together
+ to create a filter for the domains to be listed.
+ </para>
+ <simplelist>
+ <member>VIR_CONNECT_LIST_DOMAINS_ACTIVE</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_INACTIVE</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_PERSISTENT</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_TRANSIENT</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_RUNNING</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_PAUSED</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_SHUTOFF</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_OTHER</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_MANAGEDSAVE</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_NO_MANAGEDSAVE</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_AUTOSTART</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_NO_AUTOSTART</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_HAS_SNAPSHOT</member>
+ <member>VIR_CONNECT_LIST_DOMAINS_NO_SNAPSHO</member>
+ </simplelist>
<example>
<title>Fetching all domain objects</title>
<programlisting language="Python"><xi:include href="extras/Domains-Example-6.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
@@ -729,10 +750,26 @@
</para>
<para>
The second parameter of the <literal>migrate</literal> method specifies a set of flags that control how the
- migration takes place over the connection. If npo flags are needed then the parameter should
+ migration takes place over the connection. If no flags are needed then the parameter should
be set to zero.
</para>
<para>
+ Flags may be one of more of the following:
+ </para>
+ <simplelist>
+ <member>VIR_MIGRATE_LIVE</member>
+ <member>VIR_MIGRATE_PEER2PEER</member>
+ <member>VIR_MIGRATE_TUNNELLED</member>
+ <member>VIR_MIGRATE_PERSIST_DEST</member>
+ <member>VIR_MIGRATE_UNDEFINE_SOURCE</member>
+ <member>VIR_MIGRATE_PAUSED</member>
+ <member>VIR_MIGRATE_NON_SHARED_DISK</member>
+ <member>VIR_MIGRATE_NON_SHARED_INC</member>
+ <member>VIR_MIGRATE_CHANGE_PROTECTION</member>
+ <member>VIR_MIGRATE_UNSAFE</member>
+ <member>VIR_MIGRATE_OFFLINE</member>
+ </simplelist>
+ <para>
The third parameter of the <literal>migrate</literal> method specifies a new name for the domain on the target
of the migration. Not all hypervisors support this operation. If no rename of the domain is
required then the parameter shoule be set to <literal>None</literal>.
@@ -978,12 +1015,21 @@
<title>Device configuration</title>
<para>
- Configuration information for a guest domain can be obtained by using the <literal>XMLSesc</literal>
+ Configuration information for a guest domain can be obtained by using the <literal>XMLDesc</literal>
method. This method returns the current description of a domain as an XML data stream.
This stream can then be parsed to obtain detailed information about the doamin and all the
parts that make up the domain.
</para>
<para>
+ The flags parameter may contain any number of the following constants:
+ </para>
+ <simplelist>
+ <member>VIR_DOMAIN_XML_SECURE</member>
+ <member>VIR_DOMAIN_XML_INACTIVE</member>
+ <member>VIR_DOMAIN_XML_UPDATE_CPU</member>
+ <member>VIR_DOMAIN_XML_MIGRATABLE</member>
+ </simplelist>
+ <para>
The following example shows how to obtain some basic information about the domain.
</para>
<example>
diff --git a/en-US/Network_Interfaces.xml b/en-US/Network_Interfaces.xml
index d4b8652..beb1c1c 100644
--- a/en-US/Network_Interfaces.xml
+++ b/en-US/Network_Interfaces.xml
@@ -197,7 +197,9 @@
This can be used as a handle to perform further actions on the new interface,
for example making it active with <literal>create</literal>.
</para>
-
+ <para>
+ Currently the flags parameter should always be <code>0</code>.
+ </para>
<example id="Example-Defining_a_new_interface">
<title>Defining a new interface</title>
<programlisting language="Python"><xi:include href="extras/NetworkInterface-Example-11.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
diff --git a/en-US/Storage_Pools.xml b/en-US/Storage_Pools.xml
index bcd085c..c128c9d 100644
--- a/en-US/Storage_Pools.xml
+++ b/en-US/Storage_Pools.xml
@@ -88,6 +88,29 @@
A list of storage pool objects can be obtained using the <literal>listAllStoragePools</literal> method of the
<literal>virConnect</literal> class.
</para>
+ <para>
+ The flags parameter can be one or more of the following constants:
+ </para>
+ <simplelist>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_INACTIVE</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_ACTIVE</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_PERSISTENT</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_TRANSIENT</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_AUTOSTART</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_NO_AUTOSTART</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_DIR</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_FS</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_NETFS</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_LOGICAL</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_DISK</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_ISCSI</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_SCSI</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_MPATH</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_RBD</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_SHEEPDOG</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_GLUSTER</member>
+ <member>VIR_CONNECT_LIST_STORAGE_POOLS_ZFS</member>
+ </simplelist>
<example>
<title>Get the list of storage pools</title>
<programlisting language="Python"><xi:include href="extras/StoragePools-Example-1.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
@@ -122,6 +145,12 @@
and will remain on the file system after it is released.
</para>
<para>
+ The flags parameter can be one or more of the following constants:
+ </para>
+ <simplelist>
+ <member>VIR_STORAGE_XML_INACTIVE</member>
+ </simplelist>
+ <para>
The following example shows how to get the XML description of a storage pool.
</para>
<example>
@@ -156,6 +185,10 @@
The sources for a storage pool's sources can be discovered by examining the pool's XML
description. An example program follows that prints out a pools source description attributes.
</para>
+ <para>
+ Currently the flags parameter for the <literal>storagePoolCreateXML</literal> method
+ should always be <code>0</code>.
+ </para>
<example>
<title>Discover a storage pool's sources</title>
<programlisting language="Python"><xi:include href="extras/StoragePools-Example-5.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
@@ -216,6 +249,13 @@
and attributes of the storage volume are specified in the XML passed to the
<literal>createXML</literal> method.
</para>
+ <para>
+ The flags parameter can be one or more of the following constants:
+ </para>
+ <simplelist>
+ <member>VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA</member>
+ <member>VIR_STORAGE_VOL_CREATE_REFLINKVIR_CONNECT_LIST_STORAGE_POOLS_INACTIVE</member>
+ </simplelist>
<example>
<title>Create a storage volume</title>
<programlisting language="Python"><xi:include href="extras/StoragePools-Example-9.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
8 years, 1 month
[networking-guide] master: Typos (60c0212)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 60c0212cf1b4690191b433936828405bbc98d44e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Tue Aug 18 21:41:46 2015 +0200
Typos
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 2 +-
en-US/Configure_Network_Bridging.xml | 2 +-
en-US/Configure_Network_Teaming.xml | 4 ++--
en-US/Configure_Networking.xml | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 25d9239..c807d02 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -439,7 +439,7 @@ Then when complete, bring up all the slaves, which will bring up the bond (provi
<screen>~]# <command>nmcli con load /etc/sysconfig/network-scripts/ifcfg-<replaceable>device</replaceable></command></screen>
Alternatively, to reload all interfaces:
<screen>~]# <command>nmcli con reload</command></screen>
- The default behavior is for <application>NetworkManager</application> not to be aware of the changes and to continue using the old configuration data. The is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
+ The default behavior is for <application>NetworkManager</application> not to be aware of the changes and to continue using the old configuration data. This is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
</para>
<para>
diff --git a/en-US/Configure_Network_Bridging.xml b/en-US/Configure_Network_Bridging.xml
index b24986d..fe4135c 100644
--- a/en-US/Configure_Network_Bridging.xml
+++ b/en-US/Configure_Network_Bridging.xml
@@ -384,7 +384,7 @@ This command will stop the network service, start the network service, and then
<note>
<para>
- The default behavior is for <application>NetworkManager</application> not to be aware of changes to ifcfg files and to continue using the old configuration data until the interface is next brought up. The is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
+ The default behavior is for <application>NetworkManager</application> not to be aware of changes to ifcfg files and to continue using the old configuration data until the interface is next brought up. This is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
</para>
</note>
</section>
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 77aced4..720b0e7 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -858,7 +858,7 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
<section id="sec-Configure_the_loadbalance_Runner">
<title>Configure the loadbalance Runner</title>
<para>
- This runner can be used for two types of load balancing, active and passive. In active mode, constant re-balancing of traffic is done by using statistics of recent traffic to share out traffic as evenly as possible. In static mode, streams of traffic are distributed randomly across the available links. This has a speed advantage due to lower processing overhead. In high volume traffic applications this is often preferred as traffic usually consists of multiple stream which will be distributed randomly between the available links, in his way load sharing is accomplished without intervention by <systemitem class="daemon">teamd</systemitem>.
+ This runner can be used for two types of load balancing, active and passive. In active mode, constant re-balancing of traffic is done by using statistics of recent traffic to share out traffic as evenly as possible. In static mode, streams of traffic are distributed randomly across the available links. This has a speed advantage due to lower processing overhead. In high volume traffic applications this is often preferred as traffic usually consists of multiple stream which will be distributed randomly between the available links, in this way load sharing is accomplished without intervention by <systemitem class="daemon">teamd</systemitem>.
</para>
<para>
To configure the loadbalance runner for passive transmit (Tx) load balancing, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
@@ -1148,7 +1148,7 @@ eth0 dfe1f57b-419d-4d1c-aaf5-245deab82487 802-3-ethernet --</screen>
Connection 'team-ServerA' (b954c62f-5fdd-4339-97b0-40efac734c50) successfully added.</screen>
<application>NetworkManager</application> will set its internal parameter <option>connection.autoconnect</option> to <literal>yes</literal> and as no <systemitem class="protocol">IP</systemitem> address was given <option>ipv4.method</option> will be set to <literal>auto</literal>. <application>NetworkManager</application> will also write a configuration file to <filename>/etc/sysconfig/network-scripts/ifcfg-team-ServerA</filename> where the corresponding ONBOOT will be set to <literal>yes</literal> and BOOTPROTO will be set to <literal>dhcp</literal>.</para>
<para>
-Note that manual changes to the ifcfg file will not be noticed by <application>NetworkManger</application> until the interface is next brought up. See <xref linkend="sec-Network_Configuration_Using_sysconfig_Files" /> for more information on using configuration files.
+Note that manual changes to the ifcfg file will not be noticed by <application>NetworkManager</application> until the interface is next brought up. See <xref linkend="sec-Network_Configuration_Using_sysconfig_Files" /> for more information on using configuration files.
</para>
<para>
To view the other values assigned, issue a command as follows:
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index a785b04..c009441 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -1912,7 +1912,7 @@ In the second example above the help is related to the object <literal>general</
<synopsis>nmcli connection modify id '<replaceable>MyCafe</replaceable>' 802-11-wireless.mtu 1350</synopsis>
Can be reduced to the following command:
<synopsis>nmcli con mod <replaceable>MyCafe</replaceable> 802-11-wireless.mtu 1350</synopsis>
- The <option>id</option> option can been omitted because the connection ID (name) is unambiguous for <application>nmcli</application> in this case.
+ The <option>id</option> option can be omitted because the connection ID (name) is unambiguous for <application>nmcli</application> in this case.
As you become familiar with the commands, further abbreviations can be made. For example:
<synopsis>nmcli connection add type ethernet</synopsis>
can be reduced to:
@@ -2110,7 +2110,7 @@ The default action is to save the connection profile as persistent. If required,
Connection 'test-lab' (05abfd5e-324e-4461-844e-8501ba704773) successfully added.</screen>
<application>NetworkManager</application> will set its internal parameter <option>ipv4.method</option> to <literal>manual</literal> and <option>connection.autoconnect</option> to <literal>yes</literal>. <application>NetworkManager</application> will also write out settings to <filename>/etc/sysconfig/network-scripts/ifcfg-my-office</filename> where the corresponding BOOTPROTO will be set to <literal>none</literal> and ONBOOT will be set to <literal>yes</literal>.</para>
<para>
- Note that manual changes to the ifcfg file will not be noticed by <application>NetworkManger</application> until the interface is next brought up. See <xref linkend="sec-Network_Configuration_Using_sysconfig_Files" /> for more information on using configuration files.</para>
+ Note that manual changes to the ifcfg file will not be noticed by <application>NetworkManager</application> until the interface is next brought up. See <xref linkend="sec-Network_Configuration_Using_sysconfig_Files" /> for more information on using configuration files.</para>
<para>
To set two <systemitem class="protocol">IPv4</systemitem> <systemitem class="protocol">DNS</systemitem> server addresses:
<screen>~]$ <command>nmcli con mod <replaceable>test-lab</replaceable> ipv4.dns "8.8.8.8 8.8.4.4"</command></screen>
8 years, 1 month
[networking-guide] master: Change to grubby command (a3f4843)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit a3f48435653424c13bd326c26472fd51267ee0f8
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Aug 17 22:30:33 2015 +0200
Change to grubby command
Editing the grub.cfg file is not a simple matter.
Using the grubby tool is the safer way.
>---------------------------------------------------------------
en-US/Consistent_Network_Device_Naming.xml | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/en-US/Consistent_Network_Device_Naming.xml b/en-US/Consistent_Network_Device_Naming.xml
index e7dea16..e1879d0 100644
--- a/en-US/Consistent_Network_Device_Naming.xml
+++ b/en-US/Consistent_Network_Device_Naming.xml
@@ -426,12 +426,12 @@ The name provided by <systemitem class="daemon">systemd-udev</systemitem> will b
</listitem>
<listitem>
<para>
- Add the following line to the <filename>/etc/default/grub</filename> file:
+ Append the following directive to the kernel command line in the GRUB 2 menu:
<synopsis>net.ifnames=0</synopsis>
- or pass it to the kernel at boot time using the GRUB2 command-line interface.</para>
- <note>
- <para>Changes to <filename>/etc/default/grub</filename> require rebuilding the <filename>grub.cfg</filename> file using the <command>grub2-mkconfig -o</command> command. For more information about GRUB2 see the <citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle>.</para>
- </note>
+ To update all the GRUB 2 kernel menu entries, enter a command as <systemitem class="username">root</systemitem> as follows:
+ <screen>~]# <command>grubby --update-kernel=ALL --args=net.ifnames=0</command></screen>
+ For more information about working with GRUB 2 see the <citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle>.
+ </para>
</listitem>
</itemizedlist>
</para>
8 years, 1 month
[system-administrators-guide] Repo specific overrides global in dnf.conf
by stephenw
commit d0c4cb171c9716a68264b51d94f421fc189bb048
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Fri Aug 14 10:45:51 2015 +0200
Repo specific overrides global in dnf.conf
en-US/DNF.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/DNF.xml b/en-US/DNF.xml
index 04a1e7d..630ad45 100644
--- a/en-US/DNF.xml
+++ b/en-US/DNF.xml
@@ -1030,7 +1030,7 @@ ID | Login user | Date a | Action | Altere
<tertiary>configuring DNF and DNF repositories</tertiary>
</indexterm>
<para>
- The configuration file for DNF and related utilities is located at <filename>/etc/dnf/dnf.conf</filename>. This file contains one mandatory <literal>[main]</literal> section, which allows you to set DNF options that have global effect, and may also contain one or more <literal>[<replaceable>repository</replaceable>]</literal> sections, which allow you to set repository-specific options. However, it is recommended to define individual repositories in new or existing <filename class="extension">.repo</filename> files in the <filename class="directory">/etc/yum.repos.d/</filename>directory. The values you define in the <literal>[main]</literal> section of the <filename>/etc/dnf/dnf.conf</filename> file may override values set in individual <literal>[<replaceable>repository</replaceable>]</literal> sections.
+ The configuration file for DNF and related utilities is located at <filename>/etc/dnf/dnf.conf</filename>. This file contains one mandatory <literal>[main]</literal> section, which allows you to set DNF options that have global effect, and may also contain one or more <literal>[<replaceable>repository</replaceable>]</literal> sections, which allow you to set repository-specific options. However, it is recommended to define individual repositories in new or existing <filename class="extension">.repo</filename> files in the <filename class="directory">/etc/yum.repos.d/</filename> directory. The values you define in individual <literal>[<replaceable>repository</replaceable>]</literal> sections of the <filename>/etc/dnf/dnf.conf</filename> file override values set in the <literal>[main]</literal> section.
</para>
<para>
This section shows you how to:
8 years, 1 month
[libvirt_application_development_guide_using_python] Architecture chapter - commented out a reference to the removed Host devices chapter Domains chapte
by David Ashley
commit 695a20dc155eb41961b9a7a7e19e363cb64534f0
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Fri Aug 14 14:22:40 2015 -0500
Architecture chapter
- commented out a reference to the removed Host devices chapter
Domains chapter
- commented out some unused sections
Main XML file
- commented out the Host devices chapter
en-US/Architecture.xml | 4 ++--
en-US/Guest_Domains.xml | 8 ++++----
..._Application_Development_Guide_Using_Python.xml | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
---
diff --git a/en-US/Architecture.xml b/en-US/Architecture.xml
index 6307295..4f13933 100644
--- a/en-US/Architecture.xml
+++ b/en-US/Architecture.xml
@@ -287,12 +287,12 @@
also useful when working with the storage and networking APIs
to determine what resources are available to configure.
</para>
-
+<!--
<para>
Refer to <xref linkend="libvirt_application_development_guide_using_python-Host_Devices"/>
for further information about using host device objects.
</para>
-
+-->
</section>
</section>
diff --git a/en-US/Guest_Domains.xml b/en-US/Guest_Domains.xml
index e6ef0e3..230ef36 100644
--- a/en-US/Guest_Domains.xml
+++ b/en-US/Guest_Domains.xml
@@ -1171,7 +1171,7 @@
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Live_Config">
<title>Live Configuration Change</title>
-
+<!--
<para>
TBD
</para>
@@ -1211,7 +1211,7 @@
</para>
</section>
-
+-->
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Live_Config-Block_Jobs">
<title>Block Device Jobs</title>
<indexterm><primary>Block device jobs</primary></indexterm>
@@ -1280,7 +1280,7 @@
</section>
</section>
-
+<!--
<section id="libvirt_application_development_guide_using_python-Guest_Domains-Tuning">
<title>Tuning</title>
@@ -1307,5 +1307,5 @@
</section>
</section>
-
+-->
</chapter>
diff --git a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
index 609bec1..9cdcb28 100644
--- a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
+++ b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml
@@ -13,7 +13,7 @@
<xi:include href="Storage_Pools.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Virtual_Networks.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Network_Interfaces.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Host_Devices.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+<!-- <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="Security_Model.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
8 years, 1 month
[libvirt_application_development_guide_using_python] Events chapter - added some information to the events section.
by David Ashley
commit 903bf682c99f4f6bd437987b6ec30a546ae31ba0
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Fri Aug 14 14:09:23 2015 -0500
Events chapter
- added some information to the events section.
en-US/Event_Handling.xml | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Event_Handling.xml b/en-US/Event_Handling.xml
index 82a20ef..2d050cd 100644
--- a/en-US/Event_Handling.xml
+++ b/en-US/Event_Handling.xml
@@ -25,6 +25,11 @@
and <literal>virEventUpdateHandle</literal>.
</para>
<para>
+ Creating an event requires
+ that an event loop has previously been registered with <literal>virEventRegisterImpl</literal>
+ or <literal>virEventRegisterDefaultImpl</literal>.
+ </para>
+ <para>
An example program that uses most of these functions follows:
</para>
<example id="Events-example_1">
@@ -37,7 +42,7 @@
<para>
The Python libvirt module supplies a framework for timer handling. Creating a timer requires
that an event loop has previously been registered with <literal>virEventRegisterImpl</literal>
- or <literal>virEventRegisterDefaultImpl</literal>.
+ or <literal>virEventRegisterDefaultImpl</literal>.
</para>
<para>
Timer handling is done through the functions <literal>virEventAddTimeout</literal>,
8 years, 1 month
[libvirt_application_development_guide_using_python] Events chapter - added the timer section
by David Ashley
commit 3d71540afe723d10158782f72e041298cb59324b
Author: W. David Ashley <w.david.ashley(a)gmail.com>
Date: Fri Aug 14 14:06:34 2015 -0500
Events chapter
- added the timer section
en-US/Event_Handling.xml | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Event_Handling.xml b/en-US/Event_Handling.xml
index 103af24..82a20ef 100644
--- a/en-US/Event_Handling.xml
+++ b/en-US/Event_Handling.xml
@@ -32,4 +32,26 @@
<programlisting language="Python"><xi:include href="extras/Events-Example-1.py" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
</example>
</section>
+ <section id="libvirt_application_development_guide_using_python-Timer_Handling">
+ <title>Timer Handling</title>
+ <para>
+ The Python libvirt module supplies a framework for timer handling. Creating a timer requires
+ that an event loop has previously been registered with <literal>virEventRegisterImpl</literal>
+ or <literal>virEventRegisterDefaultImpl</literal>.
+ </para>
+ <para>
+ Timer handling is done through the functions <literal>virEventAddTimeout</literal>,
+ <literal>virEventUdateTimeout</literal>, and <literal>virEventRemoveTimeout</literal>. The
+ implementation will support many timers.
+ </para>
+ <para>
+ To create a new timer call the <literal>VirEventAddTimout</literal> after the
+ <literal>virEventRegisterImpl</literal> or the <literal>virEventRegisterDefaultImpl</literal>
+ function has been invoked.
+ </para>
+ <para>
+ The timer can be removed using the <literal>VirEventRemoveTimout</literal> or updated with the
+ <literal>virEventUpdateTimeout</literal> function after it has been added.
+ </para>
+ </section>
</chapter>
8 years, 1 month