[libvirt] [PATCH v2 04/10] docs: Utilize our XSLT list generating template more
Erik Skultety
eskultet at redhat.com
Thu Apr 20 13:05:54 UTC 2017
Since we do have this template at hand, why not using it wherever
possible (list of supported pool types and remote access section).
Also, perform some stylistic micro adjustments.
Signed-off-by: Erik Skultety <eskultet at redhat.com>
---
docs/remote.html.in | 106 +++++++++++++++------------------------------------
docs/storage.html.in | 62 ++++++------------------------
2 files changed, 41 insertions(+), 127 deletions(-)
diff --git a/docs/remote.html.in b/docs/remote.html.in
index 443683d51..117ee3477 100644
--- a/docs/remote.html.in
+++ b/docs/remote.html.in
@@ -7,57 +7,11 @@
Libvirt allows you to access hypervisors running on remote
machines through authenticated and encrypted connections.
</p>
- <ul>
- <li>
- <a href="#Remote_basic_usage">Basic usage</a>
- </li>
- <li>
- <a href="#Remote_transports">Transports</a>
- </li>
- <li>
- <a href="#Remote_URI_reference">Remote URIs</a>
- <ul>
- <li>
- <a href="#Remote_URI_parameters">Extra parameters</a>
- </li>
- </ul>
- </li>
- <li>
- <a href="#Remote_certificates">Generating TLS certificates</a>
- <ul>
- <li>
- <a href="#Remote_PKI">Public Key Infrastructure set up</a>
- </li>
- <li>
- <a href="#Remote_TLS_background">Background to TLS certificates</a>
- </li>
- <li>
- <a href="#Remote_TLS_CA">Setting up a Certificate Authority (CA)</a>
- </li>
- <li>
- <a href="#Remote_TLS_server_certificates">Issuing server certificates</a>
- </li>
- <li>
- <a href="#Remote_TLS_client_certificates">Issuing client certificates</a>
- </li>
- <li>
- <a href="#Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a>
- </li>
- </ul>
- </li>
- <li>
- <a href="#Remote_libvirtd_configuration">libvirtd configuration file</a>
- </li>
- <li>
- <a href="#Remote_IPv6">IPv6 support</a>
- </li>
- <li>
- <a href="#Remote_limitations">Limitations</a>
- </li>
- </ul>
- <h3>
+ <ul id="toc"></ul>
+
+ <h2>
<a name="Remote_basic_usage">Basic usage</a>
- </h3>
+ </h2>
<p>
On the remote machine, <code>libvirtd</code> should be running in general.
See <a href="#Remote_libvirtd_configuration">the section
@@ -95,9 +49,9 @@ relating to failures in the remote transport itself. </li>
<li> Remote calls are handled synchronously, so they will be
much slower than, say, direct hypervisor calls. </li>
</ul>
- <h3>
+ <h2>
<a name="Remote_transports">Transports</a>
- </h3>
+ </h2>
<p>
Remote libvirt supports a range of transports:
</p>
@@ -156,9 +110,9 @@ netcat is required on the remote side.</dd>
<p>
The default transport, if no other is specified, is <code>tls</code>.
</p>
- <h3>
+ <h2>
<a name="Remote_URI_reference">Remote URIs</a>
- </h3>
+ </h2>
<p>
See also: <a href="uri.html">documentation on ordinary ("local") URIs</a>.
</p>
@@ -203,9 +157,9 @@ and use a different known_hosts file.</li>
Connect to a remote host using a ssh connection with the libssh driver
and use a different known_hosts file.</li>
</ul>
- <h4>
+ <h3>
<a name="Remote_URI_parameters">Extra parameters</a>
- </h4>
+ </h3>
<p>
Extra parameters can be added to remote URIs as part
of the query string (the part following <q><code>?</code></q>).
@@ -409,12 +363,12 @@ Note that parameter values must be
<td> Example: <code>sshauth=privkey,agent</code> </td>
</tr>
</table>
- <h3>
+ <h2>
<a name="Remote_certificates">Generating TLS certificates</a>
- </h3>
- <h4>
+ </h2>
+ <h3>
<a name="Remote_PKI">Public Key Infrastructure set up</a>
- </h4>
+ </h3>
<p>
If you are unsure how to create TLS certificates, skip to the
next section.
@@ -517,9 +471,9 @@ next section.
</li>
<li> For the root user, the global default locations will always be used.</li>
</ul>
- <h4>
+ <h3>
<a name="Remote_TLS_background">Background to TLS certificates</a>
- </h4>
+ </h3>
<p>
Libvirt supports TLS certificates for verifying the identity
of the server and clients. There are two distinct checks involved:
@@ -552,9 +506,9 @@ they have a valid certificate issued by the CA for their own IP
address. You may want to change this to make it less (or more)
permissive, depending on your needs.
</p>
- <h4>
+ <h3>
<a name="Remote_TLS_CA">Setting up a Certificate Authority (CA)</a>
- </h4>
+ </h3>
<p>
You will need the <a href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html">GnuTLS
certtool program documented here</a>. In Fedora, it is in the
@@ -623,9 +577,9 @@ This is all that is required to set up your CA. Keep the CA's private
key carefully as you will need it when you come to issue certificates
for your clients and servers.
</p>
- <h4>
+ <h3>
<a name="Remote_TLS_server_certificates">Issuing server certificates</a>
- </h4>
+ </h3>
<p>
For each server (libvirtd) you need to issue a certificate
with the X.509 CommonName (CN) field set to the hostname
@@ -706,9 +660,9 @@ which can be installed on the server as
<code>/etc/pki/libvirt/servercert.pem</code>.
</li>
</ul>
- <h4>
+ <h3>
<a name="Remote_TLS_client_certificates">Issuing client certificates</a>
- </h4>
+ </h3>
<p>
For each client (ie. any program linked with libvirt, such as
<a href="http://virt-manager.et.redhat.com/">virt-manager</a>)
@@ -759,9 +713,9 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem
</pre>
</li>
</ol>
- <h4>
+ <h3>
<a name="Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a>
- </h4>
+ </h3>
<dl>
<dt> failed to verify client's certificate </dt>
<dd>
@@ -777,9 +731,9 @@ tell you enough to diagnose the problem.
to analyze the setup on the client or server machines, preferably as root.
It will try to point out the possible problems and provide solutions to
fix the set up up to a point where you have secure remote access.</p>
- <h3>
+ <h2>
<a name="Remote_libvirtd_configuration">libvirtd configuration file</a>
- </h3>
+ </h2>
<p>
Libvirtd (the remote daemon) is configured from a file called
<code>/etc/libvirt/libvirtd.conf</code>, or specified on
@@ -945,9 +899,9 @@ Blank lines and comments beginning with <code>#</code> are ignored.
</td>
</tr>
</table>
- <h3>
+ <h2>
<a name="Remote_IPv6">IPv6 support</a>
- </h3>
+ </h2>
<p>
The libvirtd service and libvirt remote client driver both use the
<code>getaddrinfo()</code> functions for name resolution and are
@@ -958,9 +912,9 @@ address resolved for a service is reachable over IPv6, then an IPv6
connection will be made, otherwise IPv4 will be used. In summary it
should just 'do the right thing(tm)'.
</p>
- <h3>
+ <h2>
<a name="Remote_limitations">Limitations</a>
- </h3>
+ </h2>
<ul>
<li> Fine-grained authentication: libvirt in general,
but in particular the remote case should support more
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 5e18f02c5..89ebb7097 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -83,47 +83,7 @@
<p>
Libvirt supports the following storage pool types:
</p>
- <ul>
- <li>
- <a href="#StorageBackendDir">Directory backend</a>
- </li>
- <li>
- <a href="#StorageBackendFS">Local filesystem backend</a>
- </li>
- <li>
- <a href="#StorageBackendNetFS">Network filesystem backend</a>
- </li>
- <li>
- <a href="#StorageBackendLogical">Logical backend</a>
- </li>
- <li>
- <a href="#StorageBackendDisk">Disk backend</a>
- </li>
- <li>
- <a href="#StorageBackendISCSI">iSCSI backend</a>
- </li>
- <li>
- <a href="#StorageBackendSCSI">SCSI backend</a>
- </li>
- <li>
- <a href="#StorageBackendMultipath">Multipath backend</a>
- </li>
- <li>
- <a href="#StorageBackendRBD">RBD (RADOS Block Device) backend</a>
- </li>
- <li>
- <a href="#StorageBackendSheepdog">Sheepdog backend</a>
- </li>
- <li>
- <a href="#StorageBackendGluster">Gluster backend</a>
- </li>
- <li>
- <a href="#StorageBackendZFS">ZFS backend</a>
- </li>
- <li>
- <a href="#StorageBackendVstorage">Virtuozzo storage backend</a>
- </li>
- </ul>
+ <ul id="toc"></ul>
<h2><a name="StorageBackendDir">Directory pool</a></h2>
<p>
@@ -306,7 +266,7 @@
</p>
- <h2><a name="StorageBackendLogical">Logical volume pools</a></h2>
+ <h2><a name="StorageBackendLogical">Logical volume pool</a></h2>
<p>
This provides a pool based on an LVM volume group. For a
pre-defined LVM volume group, simply providing the group
@@ -343,7 +303,7 @@
</p>
- <h2><a name="StorageBackendDisk">Disk volume pools</a></h2>
+ <h2><a name="StorageBackendDisk">Disk pool</a></h2>
<p>
This provides a pool based on a physical disk. Volumes are created
by adding partitions to the disk. Disk pools have constraints
@@ -434,7 +394,7 @@
</ul>
- <h2><a name="StorageBackendISCSI">iSCSI volume pools</a></h2>
+ <h2><a name="StorageBackendISCSI">iSCSI pool</a></h2>
<p>
This provides a pool based on an iSCSI target. Volumes must be
pre-allocated on the iSCSI server, and cannot be created via
@@ -473,7 +433,7 @@
The iSCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendSCSI">SCSI volume pools</a></h2>
+ <h2><a name="StorageBackendSCSI">SCSI pool</a></h2>
<p>
This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI
LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names
@@ -505,7 +465,7 @@
The SCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendMultipath">Multipath pools</a></h2>
+ <h2><a name="StorageBackendMultipath">Multipath pool</a></h2>
<p>
This provides a pool that contains all the multipath devices on the
host. Therefore, only one Multipath pool may be configured per host.
@@ -538,7 +498,7 @@
The Multipath volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendRBD">RBD pools</a></h2>
+ <h2><a name="StorageBackendRBD">RBD pool</a></h2>
<p>
This storage driver provides a pool which contains all RBD
images in a RADOS pool. RBD (RADOS Block Device) is part
@@ -611,7 +571,7 @@
The RBD pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendSheepdog">Sheepdog pools</a></h2>
+ <h2><a name="StorageBackendSheepdog">Sheepdog pool</a></h2>
<p>
This provides a pool based on a Sheepdog Cluster.
Sheepdog is a distributed storage system for QEMU/KVM.
@@ -670,7 +630,7 @@
The Sheepdog pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendGluster">Gluster pools</a></h2>
+ <h2><a name="StorageBackendGluster">Gluster pool</a></h2>
<p>
This provides a pool based on native Gluster access. Gluster is
a distributed file system that can be exposed to the user via
@@ -756,7 +716,7 @@
pool type.
</p>
- <h2><a name="StorageBackendZFS">ZFS pools</a></h2>
+ <h2><a name="StorageBackendZFS">ZFS pool</a></h2>
<p>
This provides a pool based on the ZFS filesystem. Initially it was developed
for FreeBSD, and <span class="since">since 1.3.2</span> experimental support
@@ -794,7 +754,7 @@
<p>
The ZFS volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendVstorage">Vstorage pools</a></h2>
+ <h2><a name="StorageBackendVstorage">Vstorage pool</a></h2>
<p>
This provides a pool based on Virtuozzo storage. Virtuozzo Storage is
a highly available distributed software-defined storage with built-in
--
2.12.2
More information about the libvir-list
mailing list