5:12 a.m.
Got sick of seeing the "validity error : ID Objects already defined"
errors, which this patch addresses.
---
As per danpb's suggestion, nuked the id tags instead.
Internal document linking works with this version (tested).
docs/api.html.in | 8 ++++----
docs/architecture.html.in | 6 +++---
docs/downloads.html.in | 2 +-
docs/remote.html.in | 30 +++++++++++++++---------------
docs/storage.html.in | 16 ++++++++--------
docs/uri.html.in | 24 ++++++++++++------------
6 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/docs/api.html.in b/docs/api.html.in
index 4b6a529..ad43fa3 100644
--- a/docs/api.html.in
+++ b/docs/api.html.in
@@ -19,7 +19,7 @@
<a href="#Remote">Daemon and remote access</a>
</li>
</ul>
- <h2><a name="Objects" id="Objects">Objects
exposed</a></h2>
+ <h2><a name="Objects">Objects exposed</a></h2>
<p> As defined in the <a href="goals.html">goals
section</a>, libvirt
API need to expose all the resources needed to manage the virtualization
support of recent operating systems. The first object manipulated though
@@ -85,7 +85,7 @@
set of nodes.</li>
</ul>
- <h2><a name="Functions" id="Functions">Functions and
naming
+ <h2><a name="Functions">Functions and naming
conventions</a></h2>
<p> The naming of the functions present in the library is usually
made of a prefix describing the object associated to the function
@@ -120,13 +120,13 @@
</ul>
<p> For more in-depth details of the storage related APIs see
<a href="storage.html">the storage management page</a>,
- <h2><a name="Driver" id="Driver">The libvirt
drivers</a></h2>
+ <h2><a name="Driver">The libvirt drivers</a></h2>
<p></p>
<p class="image">
<img alt="The libvirt driver architecture"
src="libvirt-driver-arch.png"/>
</p>
- <h2><a name="Remote" id="Remote">Daemon and remote
access</a></h2>
+ <h2><a name="Remote">Daemon and remote
access</a></h2>
<p></p>
<p class="image">
<img alt="The libvirt daemon and remote architecture"
diff --git a/docs/architecture.html.in b/docs/architecture.html.in
index f5cc520..a3e91a5 100644
--- a/docs/architecture.html.in
+++ b/docs/architecture.html.in
@@ -16,7 +16,7 @@ engines:</p>
</li>
</ul>
<h3>
- <a name="Xen" id="Xen">Libvirt Xen support</a>
+ <a name="Xen">Libvirt Xen support</a>
</h3>
<p>When running in a Xen environment, programs using libvirt have to execute
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
@@ -49,7 +49,7 @@ connect to initialize the library. It will then fork a libvirt_proxy
program running as root and providing read_only access to the API, this is
then only useful for reporting and monitoring.</p>
<h3>
- <a name="QEmu" id="QEmu">Libvirt QEmu and KVM
support</a>
+ <a name="QEmu">Libvirt QEmu and KVM support</a>
</h3>
<p>The model for QEmu and KVM is completely similar, basically KVM is based
on QEmu for the process controlling a new domain, only small details differs
@@ -63,7 +63,7 @@ domain, by specifying the architecture and machine type
targeted.</p>
<p>The code controlling the QEmu process is available in the
<code>qemud/</code> directory.</p>
<h3>
- <a name="drivers" id="drivers">the driver based
architecture</a>
+ <a name="drivers">the driver based architecture</a>
</h3>
<p>As the previous section explains, libvirt can communicate using different
channels with the current hypervisor, and should also be able to use
diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 2ce1048..4b37d07 100644
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -91,7 +91,7 @@
<h1>libvirt Installation</h1>
- <h2><a name="Compilatio"
id="Compilatio">Compilation</a></h2>
+ <h2><a name="Compilatio">Compilation</a></h2>
<p>
libvirt uses the standard configure/make/install steps:
diff --git a/docs/remote.html.in b/docs/remote.html.in
index b8b8f2b..37b019b 100644
--- a/docs/remote.html.in
+++ b/docs/remote.html.in
@@ -58,7 +58,7 @@ machines through authenticated and encrypted connections.
</li>
</ul>
<h3>
- <a name="Remote_basic_usage"
id="Remote_basic_usage">Basic usage</a>
+ <a name="Remote_basic_usage">Basic usage</a>
</h3>
<p>
On the remote machine, <code>libvirtd</code> should be running.
@@ -92,7 +92,7 @@ relating to failures in the remote transport itself. </li>
much slower than, say, direct hypervisor calls. </li>
</ul>
<h3>
- <a name="Remote_transports"
id="Remote_transports">Transports</a>
+ <a name="Remote_transports">Transports</a>
</h3>
<p>
Remote libvirt supports a range of transports:
@@ -140,7 +140,7 @@ Remote libvirt supports a range of transports:
The default transport, if no other is specified, is <code>tls</code>.
</p>
<h3>
- <a name="Remote_URI_reference"
id="Remote_URI_reference">Remote URIs</a>
+ <a name="Remote_URI_reference">Remote URIs</a>
</h3>
<p>
See also: <a href="uri.html">documentation on ordinary
("local") URIs</a>.
@@ -181,7 +181,7 @@ settings.
</li>
</ul>
<h4>
- <a name="Remote_URI_parameters"
id="Remote_URI_parameters">Extra parameters</a>
+ <a name="Remote_URI_parameters">Extra parameters</a>
</h4>
<p>
Extra parameters can be added to remote URIs as part
@@ -304,10 +304,10 @@ Note that parameter values must be
</tr>
</table>
<h3>
- <a name="Remote_certificates"
id="Remote_certificates">Generating TLS certificates</a>
+ <a name="Remote_certificates">Generating TLS
certificates</a>
</h3>
<h4>
- <a name="Remote_PKI" id="Remote_PKI">Public Key
Infrastructure set up</a>
+ <a name="Remote_PKI">Public Key Infrastructure set up</a>
</h4>
<p>
If you are unsure how to create TLS certificates, skip to the
@@ -367,7 +367,7 @@ next section.
</tr>
</table>
<h4>
- <a name="Remote_TLS_background"
id="Remote_TLS_background">Background to TLS certificates</a>
+ <a name="Remote_TLS_background">Background to TLS
certificates</a>
</h4>
<p>
Libvirt supports TLS certificates for verifying the identity
@@ -402,7 +402,7 @@ address. You may want to change this to make it less (or more)
permissive, depending on your needs.
</p>
<h4>
- <a name="Remote_TLS_CA" id="Remote_TLS_CA">Setting up a
Certificate Authority (CA)</a>
+ <a name="Remote_TLS_CA">Setting up a Certificate Authority
(CA)</a>
</h4>
<p>
You will need the <a
href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-c...
@@ -473,7 +473,7 @@ key carefully as you will need it when you come to issue certificates
for your clients and servers.
</p>
<h4>
- <a name="Remote_TLS_server_certificates"
id="Remote_TLS_server_certificates">Issuing server certificates</a>
+ <a name="Remote_TLS_server_certificates">Issuing server
certificates</a>
</h4>
<p>
For each server (libvirtd) you need to issue a certificate
@@ -556,7 +556,7 @@ which can be installed on the server as
</li>
</ul>
<h4>
- <a name="Remote_TLS_client_certificates"
id="Remote_TLS_client_certificates">Issuing client certificates</a>
+ <a name="Remote_TLS_client_certificates">Issuing client
certificates</a>
</h4>
<p>
For each client (ie. any program linked with libvirt, such as
@@ -609,7 +609,7 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem
</li>
</ol>
<h4>
- <a name="Remote_TLS_troubleshooting"
id="Remote_TLS_troubleshooting">Troubleshooting TLS certificate
problems</a>
+ <a name="Remote_TLS_troubleshooting">Troubleshooting TLS
certificate problems</a>
</h4>
<dl>
<dt> failed to verify client's certificate </dt>
@@ -627,7 +627,7 @@ 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>
- <a name="Remote_libvirtd_configuration"
id="Remote_libvirtd_configuration">libvirtd configuration file</a>
+ <a name="Remote_libvirtd_configuration">libvirtd configuration
file</a>
</h3>
<p>
Libvirtd (the remote daemon) is configured from a file called
@@ -795,7 +795,7 @@ Blank lines and comments beginning with <code>#</code> are
ignored.
</tr>
</table>
<h3>
- <a name="Remote_IPv6" id="Remote_IPv6">IPv6
support</a>
+ <a name="Remote_IPv6">IPv6 support</a>
</h3>
<p>
The libvirtd service and libvirt remote client driver both use the
@@ -808,7 +808,7 @@ connection will be made, otherwise IPv4 will be used. In summary it
should just 'do the right thing(tm)'.
</p>
<h3>
- <a name="Remote_limitations"
id="Remote_limitations">Limitations</a>
+ <a name="Remote_limitations">Limitations</a>
</h3>
<ul>
<li> Fine-grained authentication: libvirt in general,
@@ -821,7 +821,7 @@ just read-write/read-only as at present.
Please come and discuss these issues and more on <a
href="https://www.redhat.com/mailman/listinfo/libvir-list"
title="libvir-list mailing list">the mailing list</a>.
</p>
<h3>
- <a name="Remote_implementation_notes"
id="Remote_implementation_notes">Implementation notes</a>
+ <a name="Remote_implementation_notes">Implementation
notes</a>
</h3>
<p>
The current implementation uses <a
href="http://en.wikipedia.org/wiki/External_Data_Representation"
title="External Data Representation">XDR</a>-encoded packets with a
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 079192b..a9c7f1c 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -33,7 +33,7 @@ libvirt.
</li>
</ul>
- <h2><a name="StorageBackendDir"
id="StorageBackendDir">Directory pool</a></h2>
+ <h2><a name="StorageBackendDir">Directory
pool</a></h2>
<p>
A pool with a type of <code>dir</code> provides the means to manage
files within a directory. The files can be fully allocated raw files,
@@ -85,7 +85,7 @@ libvirt.
</p>
- <h2><a name="StorageBackendFS"
id="StorageBackendFS">Filesystem pool</a></h2>
+ <h2><a name="StorageBackendFS">Filesystem
pool</a></h2>
<p>
This is a variant of the directory pool. Instead of creating a
directory on an existing mounted filesystem though, it expects
@@ -156,7 +156,7 @@ libvirt.
</p>
- <h2><a name="StorageBackendNetFS"
id="StorageBackendNetFS">Network filesystem pool</a></h2>
+ <h2><a name="StorageBackendNetFS">Network filesystem
pool</a></h2>
<p>
This is a variant of the filesystem pool. Instead of requiring
a local block device as the source, it requires the name of a
@@ -196,7 +196,7 @@ libvirt.
</p>
- <h2><a name="StorageBackendLogical"
id="StorageBackendLogical">Logical volume pools</a></h2>
+ <h2><a name="StorageBackendLogical">Logical volume
pools</a></h2>
<p>
This provides a pool based on an LVM volume group. For a
pre-defined LVM volume group, simply providing the group
@@ -231,7 +231,7 @@ libvirt.
</p>
- <h2><a name="StorageBackendDisk"
id="StorageBackendDisk">Disk volume pools</a></h2>
+ <h2><a name="StorageBackendDisk">Disk volume
pools</a></h2>
<p>
This provides a pool based on a physical disk. Volumes are created
by adding partitions to the disk. Disk pools are have constraints
@@ -318,7 +318,7 @@ libvirt.
</ul>
- <h2><a name="StorageBackendISCSI"
id="StorageBackendISCSI">iSCSI volume pools</a></h2>
+ <h2><a name="StorageBackendISCSI">iSCSI volume
pools</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
@@ -351,7 +351,7 @@ libvirt.
The iSCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendSCSI"
id="StorageBackendSCSI">SCSI volume pools</a></h2>
+ <h2><a name="StorageBackendSCSI">SCSI volume
pools</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
@@ -383,7 +383,7 @@ libvirt.
The SCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendMultipath"
id="StorageBackendMultipath">Multipath pools</a></h2>
+ <h2><a name="StorageBackendMultipath">Multipath
pools</a></h2>
<p>
This provides a pool that contains all the multipath devices on the
host. Volume creating is not supported via the libvirt APIs.
diff --git a/docs/uri.html.in b/docs/uri.html.in
index 0540dab..39c308b 100644
--- a/docs/uri.html.in
+++ b/docs/uri.html.in
@@ -37,7 +37,7 @@ documents libvirt URIs.
</li>
</ul>
<h3>
- <a name="URI_libvirt" id="URI_libvirt">Specifying URIs to
libvirt</a>
+ <a name="URI_libvirt">Specifying URIs to libvirt</a>
</h3>
<p>
The URI is passed as the <code>name</code> parameter to <a
href="html/libvirt-libvirt.html#virConnectOpen"><code>virConnectOpen</code></a>
or <a
href="html/libvirt-libvirt.html#virConnectOpenReadOnly"><code>virConnectOpenReadOnly</code></a>.
For example:
@@ -46,7 +46,7 @@ The URI is passed as the <code>name</code> parameter to
<a href="html/libvirt-li
virConnectPtr conn = virConnectOpenReadOnly
(<b>"test:///default"</b>);
</pre>
<h3>
- <a name="URI_virsh" id="URI_virsh">Specifying URIs to
virsh, virt-manager and virt-install</a>
+ <a name="URI_virsh">Specifying URIs to virsh, virt-manager and
virt-install</a>
</h3>
<p>
In virsh use the <code>-c</code> or <code>--connect</code>
option:
@@ -77,7 +77,7 @@ In virt-install use the
<code>--connect=</code><i>URI</i> option:
virt-install <b>--connect=test:///default</b> <i>[other
options]</i>
</pre>
<h3>
- <a name="URI_xen" id="URI_xen">xen:/// URI</a>
+ <a name="URI_xen">xen:/// URI</a>
</h3>
<p>
<i>This section describes a feature which is new in libvirt >
@@ -88,7 +88,7 @@ To access a Xen hypervisor running on the local machine
use the URI <code>xen:///</code>.
</p>
<h3>
- <a name="URI_qemu" id="URI_qemu">qemu:///... QEMU and KVM
URIs</a>
+ <a name="URI_qemu">qemu:///... QEMU and KVM URIs</a>
</h3>
<p>
To use QEMU support in libvirt you must be running the
@@ -120,7 +120,7 @@ KVM guests in the <a href="format.html#KVM1">guest XML
as described
here</a>.
</p>
<h3>
- <a name="URI_remote" id="URI_remote">Remote
URIs</a>
+ <a name="URI_remote">Remote URIs</a>
</h3>
<p>
Remote URIs are formed by taking ordinary local URIs and adding a
@@ -183,7 +183,7 @@ remote URI reference</a> and <a
href="remote.html">full documentation
for libvirt remote support</a>.
</p>
<h3>
- <a name="URI_test" id="URI_test">test:///... Test
URIs</a>
+ <a name="URI_test">test:///... Test URIs</a>
</h3>
<p>
The test driver is a dummy hypervisor for test purposes.
@@ -197,10 +197,10 @@ a set of host definitions held in the named file.
</li>
</ul>
<h3>
- <a name="URI_legacy" id="URI_legacy">Other &
legacy URI formats</a>
+ <a name="URI_legacy">Other & legacy URI formats</a>
</h3>
<h4>
- <a name="URI_NULL" id="URI_NULL">NULL and empty string
URIs</a>
+ <a name="URI_NULL">NULL and empty string URIs</a>
</h4>
<p>
Libvirt allows you to pass a <code>NULL</code> pointer to
@@ -224,7 +224,7 @@ application wishes to connect specifically to a Xen hypervisor, then
for future proofing it should choose a full <a
href="#URI_xen"><code>xen:///</code> URI</a>.
</p>
<h4>
- <a name="URI_file" id="URI_file">File paths
(xend-unix-server)</a>
+ <a name="URI_file">File paths (xend-unix-server)</a>
</h4>
<p>
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
@@ -241,7 +241,7 @@ using a file URI such as:
virsh -c ///var/run/xend/xend-socket
</pre>
<h4>
- <a name="URI_http" id="URI_http">Legacy:
<code>http://...</code> (xend-http-server)</a>
+ <a name="URI_http">Legacy: <code>http://...</code>
(xend-http-server)</a>
</h4>
<p>
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
@@ -277,7 +277,7 @@ Notes:
documentation as "unix server" or "http server".</li>
</ol>
<h4>
- <a name="URI_legacy_xen" id="URI_legacy_xen">Legacy:
<code>"xen"</code></a>
+ <a name="URI_legacy_xen">Legacy:
<code>"xen"</code></a>
</h4>
<p>
Another legacy URI is to specify name as the string
@@ -285,7 +285,7 @@ Another legacy URI is to specify name as the string
hypervisor. However you should prefer a full <a
href="#URI_xen"><code>xen:///</code> URI</a> in all future
code.
</p>
<h4>
- <a name="URI_legacy_proxy" id="URI_legacy_proxy">Legacy:
Xen proxy</a>
+ <a name="URI_legacy_proxy">Legacy: Xen proxy</a>
</h4>
<p>
Libvirt continues to support connections to a separately running Xen
--
1.7.2.3