The 'name' attribute on <a...> elements is deprecated in favour
of the 'id' attribute which is allowed on any element. HTML5
drops 'name' support entirely.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
docs/acl.html.in | 6 +-
docs/aclpolkit.html.in | 32 +++---
docs/api.html.in | 8 +-
docs/api_extension.html.in | 12 +--
docs/apps.html.in | 30 +++---
docs/architecture.html.in | 6 +-
docs/auditlog.html.in | 38 +++----
docs/auth.html.in | 14 +--
docs/bugs.html.in | 10 +-
docs/cgroups.html.in | 24 ++---
docs/compiling.html.in | 6 +-
docs/contact.html.in | 6 +-
docs/contribute.html.in | 10 +-
docs/csharp.html.in | 18 ++--
docs/downloads.html.in | 12 +--
docs/drivers.html.in | 4 +-
docs/drvbhyve.html.in | 20 ++--
docs/drvesx.html.in | 44 ++++----
docs/drvhyperv.html.in | 10 +-
docs/drvlxc.html.in | 52 +++++-----
docs/drvnodedev.html.in | 8 +-
docs/drvopenvz.html.in | 12 +--
docs/drvphyp.html.in | 6 +-
docs/drvqemu.html.in | 32 +++---
docs/drvuml.html.in | 2 +-
docs/drvvbox.html.in | 4 +-
docs/drvvirtuozzo.html.in | 6 +-
docs/drvvmware.html.in | 4 +-
docs/drvxen.html.in | 14 +--
docs/firewall.html.in | 6 +-
docs/formatcaps.html.in | 8 +-
docs/formatdomain.html.in | 192 +++++++++++++++++------------------
docs/formatdomaincaps.html.in | 24 ++---
docs/formatnetwork.html.in | 32 +++---
docs/formatnode.html.in | 4 +-
docs/formatnwfilter.html.in | 68 ++++++-------
docs/formatsecret.html.in | 10 +-
docs/formatsnapshot.html.in | 4 +-
docs/formatstorage.html.in | 28 ++---
docs/formatstorageencryption.html.in | 10 +-
docs/governance.html.in | 12 +--
docs/hacking.html.in | 40 ++++----
docs/hooks.html.in | 30 +++---
docs/internals/command.html.in | 32 +++---
docs/internals/eventloop.html.in | 6 +-
docs/internals/locking.html.in | 16 +--
docs/internals/oomtesting.html.in | 8 +-
docs/internals/rpc.html.in | 42 ++++----
docs/locking-lockd.html.in | 8 +-
docs/locking-sanlock.html.in | 10 +-
docs/locking.html.in | 2 +-
docs/logging.html.in | 14 +--
docs/migration.html.in | 36 +++----
docs/nss.html.in | 10 +-
docs/page.xsl | 14 +--
docs/remote.html.in | 28 ++---
docs/secureusage.html.in | 14 +--
docs/securityprocess.html.in | 12 +--
docs/storage.html.in | 26 ++---
docs/uri.html.in | 28 ++---
docs/virshcmdref.html.in | 8 +-
docs/windows.html.in | 18 ++--
62 files changed, 624 insertions(+), 626 deletions(-)
diff --git a/docs/acl.html.in b/docs/acl.html.in
index 6d280c194..5936c6d20 100644
--- a/docs/acl.html.in
+++ b/docs/acl.html.in
@@ -12,7 +12,7 @@
<ul id="toc"></ul>
- <h2><a name="intro">Access control
introduction</a></h2>
+ <h2><a id="intro">Access control
introduction</a></h2>
<p>
In a default configuration, the libvirtd daemon has three levels
@@ -42,7 +42,7 @@
<code>getattr</code> permission.
</p>
- <h2><a name="drivers">Access control
drivers</a></h2>
+ <h2><a id="drivers">Access control
drivers</a></h2>
<p>
The access control framework is designed as a pluggable
@@ -83,7 +83,7 @@
the libvirtd daemon be restarted.
</p>
- <h2><a name="perms">Objects and
permissions</a></h2>
+ <h2><a id="perms">Objects and permissions</a></h2>
<p>
Libvirt applies access control to all the main object
diff --git a/docs/aclpolkit.html.in b/docs/aclpolkit.html.in
index 7967a0f3d..d1f327c70 100644
--- a/docs/aclpolkit.html.in
+++ b/docs/aclpolkit.html.in
@@ -14,7 +14,7 @@
<ul id="toc"></ul>
- <h2><a name="intro">Introduction</a></h2>
+ <h2><a id="intro">Introduction</a></h2>
<p>
A default install of libvirt will typically use
@@ -27,7 +27,7 @@
object.
</p>
- <h2><a name="perms">Permission names</a></h2>
+ <h2><a id="perms">Permission names</a></h2>
<p>
The libvirt <a href="acl.html#perms">object names and permission
names</a>
@@ -53,7 +53,7 @@
permissions default to deny access.
</p>
- <h2><a name="attrs">Object identity
attributes</a></h2>
+ <h2><a id="attrs">Object identity
attributes</a></h2>
<p>
To allow polkit authorization rules to be written to match
@@ -63,7 +63,7 @@
of object being checked
</p>
- <h3><a
name="object_connect">virConnectPtr</a></h3>
+ <h3><a id="object_connect">virConnectPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -79,7 +79,7 @@
</tbody>
</table>
- <h3><a name="object_domain">virDomainPtr</a></h3>
+ <h3><a id="object_domain">virDomainPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -103,7 +103,7 @@
</tbody>
</table>
- <h3><a
name="object_interface">virInterfacePtr</a></h3>
+ <h3><a
id="object_interface">virInterfacePtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -127,7 +127,7 @@
</tbody>
</table>
- <h3><a
name="object_network">virNetworkPtr</a></h3>
+ <h3><a id="object_network">virNetworkPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -151,7 +151,7 @@
</tbody>
</table>
- <h3><a
name="object_node_device">virNodeDevicePtr</a></h3>
+ <h3><a
id="object_node_device">virNodeDevicePtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -171,7 +171,7 @@
</tbody>
</table>
- <h3><a
name="object_nwfilter">virNWFilterPtr</a></h3>
+ <h3><a
id="object_nwfilter">virNWFilterPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -195,7 +195,7 @@
</tbody>
</table>
- <h3><a name="object_secret">virSecretPtr</a></h3>
+ <h3><a id="object_secret">virSecretPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -231,7 +231,7 @@
</tbody>
</table>
- <h3><a
name="object_storage_pool">virStoragePoolPtr</a></h3>
+ <h3><a
id="object_storage_pool">virStoragePoolPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -255,7 +255,7 @@
</tbody>
</table>
- <h3><a
name="object_storage_vol">virStorageVolPtr</a></h3>
+ <h3><a
id="object_storage_vol">virStorageVolPtr</a></h3>
<table class="acl">
<thead>
<tr>
@@ -288,7 +288,7 @@
</table>
- <h2><a name="user">User identity
attributes</a></h2>
+ <h2><a id="user">User identity attributes</a></h2>
<p>
At this point in time, the only attribute provided by
@@ -307,7 +307,7 @@
</p>
- <h2><a name="checks">Writing access control
policies</a></h2>
+ <h2><a id="checks">Writing access control
policies</a></h2>
<p>
If using versions of polkit prior to 0.106 then it is only
@@ -358,7 +358,7 @@ polkit.addRule(function(action, subject) {
for a more complex example.
</p>
- <h3><a name="exconnect">Example: restricting ability to connect
to drivers</a></h3>
+ <h3><a id="exconnect">Example: restricting ability to connect
to drivers</a></h3>
<p>
Consider a local user <code>berrange</code>
@@ -386,7 +386,7 @@ polkit.addRule(function(action, subject) {
});
</pre>
- <h3><a name="exdomain">Example: restricting access to a single
domain</a></h3>
+ <h3><a id="exdomain">Example: restricting access to a single
domain</a></h3>
<p>
Consider a local user <code>berrange</code>
diff --git a/docs/api.html.in b/docs/api.html.in
index c38bed28c..1cd166364 100644
--- a/docs/api.html.in
+++ b/docs/api.html.in
@@ -9,7 +9,7 @@
<ul id="toc"></ul>
- <h2><a name="Objects">Objects Exposed</a></h2>
+ <h2><a id="Objects">Objects Exposed</a></h2>
<p> As defined in the <a href="goals.html">goals
section</a>, the libvirt
API is designed to expose all the resources needed to manage the
virtualization support of recent operating systems. The first object
@@ -121,7 +121,7 @@
set of nodes.</p></li>
</ul>
- <h2><a name="Functions">Functions and Naming
Conventions</a></h2>
+ <h2><a id="Functions">Functions and Naming
Conventions</a></h2>
<p> The naming of the functions present in the library is usually
composed by a prefix describing the object associated to the function
and a verb describing the action on that object.</p>
@@ -297,7 +297,7 @@
<p> For more in-depth details of the storage related APIs see
<a href="storage.html">the storage management page</a>.
</p>
- <h2><a name="Drivers">The libvirt Drivers</a></h2>
+ <h2><a id="Drivers">The libvirt Drivers</a></h2>
<p>Drivers are the basic building block for libvirt functionality
to support the capability to handle specific hypervisor driver calls.
Drivers are discovered and registered during connection processing as
@@ -325,7 +325,7 @@
the various functions and support found in each driver by the version
support was added into libvirt.
</p>
- <h2><a name="Remote">Daemon and Remote
Access</a></h2>
+ <h2><a id="Remote">Daemon and Remote
Access</a></h2>
<p>Access to libvirt drivers is primarily handled by the libvirtd
daemon through the <a href="remote.html">remote</a> driver via
an
<a href="internals/rpc.html">RPC</a>. Some hypervisors do
support
diff --git a/docs/api_extension.html.in b/docs/api_extension.html.in
index ac7097b91..fdc7eb296 100644
--- a/docs/api_extension.html.in
+++ b/docs/api_extension.html.in
@@ -273,7 +273,7 @@
<li>unlocks the remote driver.</li>
</ol>
- <h3><a name="serverdispatch">Implement the server side
dispatcher</a></h3>
+ <h3><a id="serverdispatch">Implement the server side
dispatcher</a></h3>
<p>
Implementing the server side of the remote function call is simply a
@@ -300,7 +300,7 @@
<p class="example">See <a
href="api_extension/0005-implement-the-remote-protocol.patch">0005-implement-the-remote-protocol.patch</a></p>
- <h2><a name="internaluseapi">Use the new API
internally</a></h2>
+ <h2><a id="internaluseapi">Use the new API
internally</a></h2>
<p>
Sometimes, a new API serves as a superset of existing API, by
@@ -314,7 +314,7 @@
<p class="example">See <a
href="api_extension/0006-make-old-API-trivially-wrap-to-new-API.patch">0006-make-old-API-trivially-wrap-to-new-API.patch</a></p>
- <h2><a name="virshuseapi">Expose the new API in
virsh</a></h2>
+ <h2><a id="virshuseapi">Expose the new API in
virsh</a></h2>
<p>
All new API should be manageable from the virsh command line
@@ -345,7 +345,7 @@
<p class="example">See <a
href="api_extension/0007-add-virsh-support.patch">0007-add-virsh-support.patch</a></p>
- <h2><a name="driverimpl">Implement the driver
methods</a></h2>
+ <h2><a id="driverimpl">Implement the driver
methods</a></h2>
<p>
So, after all that, we get to the fun part. All functionality in
@@ -356,7 +356,7 @@
adding.
</p>
- <h3><a name="commonimpl">Implement common
handling</a></h3>
+ <h3><a id="commonimpl">Implement common
handling</a></h3>
<p>
If the new API is applicable to more than one driver, it may
@@ -373,7 +373,7 @@
<p class="example">See <a
href="api_extension/0008-support-new-xml.patch">0008-support-new-xml.patch</a></p>
- <h3><a name="drivercode">Implement driver
handling</a></h3>
+ <h3><a id="drivercode">Implement driver
handling</a></h3>
<p>
The remaining patches should only touch one driver at a time.
diff --git a/docs/apps.html.in b/docs/apps.html.in
index 44e5b644f..760004715 100644
--- a/docs/apps.html.in
+++ b/docs/apps.html.in
@@ -11,7 +11,7 @@
<ul id="toc"></ul>
- <h2><a name="add">Add an application</a></h2>
+ <h2><a id="add">Add an application</a></h2>
<p>
To add an application not listed on this page, send a message
@@ -30,7 +30,7 @@
<img src="logos/logo-square-powered-256.png" alt="libvirt
powered"/>
</p>
- <h2><a name="clientserver">Client/Server
applications</a></h2>
+ <h2><a id="clientserver">Client/Server
applications</a></h2>
<dl>
<dt><a
href="http://archipelproject.org">Archipel</a></dt>
@@ -50,7 +50,7 @@
</dd>
</dl>
- <h2><a name="command">Command line tools</a></h2>
+ <h2><a id="command">Command line tools</a></h2>
<dl>
<dt><a
href="http://libguestfs.org">guestfish</a></dt>
@@ -121,7 +121,7 @@
</dd>
</dl>
- <h2><a name="configmgmt">Configuration
Management</a></h2>
+ <h2><a id="configmgmt">Configuration
Management</a></h2>
<dl>
<dt><a
href="https://wiki.lcfg.org/bin/view/LCFG/LcfgLibvirt">LCFG&...
@@ -139,7 +139,7 @@
</dd>
</dl>
- <h2><a name="continuousintegration">Continuous
Integration</a></h2>
+ <h2><a id="continuousintegration">Continuous
Integration</a></h2>
<dl>
<dt><a
href="http://buildbot.net/buildbot/docs/current/Libvirt.html"&g...
@@ -163,7 +163,7 @@
</dd>
</dl>
- <h2><a name="conversion">Conversion</a></h2>
+ <h2><a id="conversion">Conversion</a></h2>
<dl>
<dt><a
href="http://libguestfs.org/virt-p2v.1.html">virt-p2v</a&...
@@ -194,7 +194,7 @@
</dd>
</dl>
- <h2><a name="desktop">Desktop
applications</a></h2>
+ <h2><a id="desktop">Desktop applications</a></h2>
<dl>
<dt><a
href="http://virt-manager.org/">virt-manager</a></d...
@@ -224,7 +224,7 @@
</dd>
</dl>
- <h2><a name="iaas">Infrastructure as a Service
(IaaS)</a></h2>
+ <h2><a id="iaas">Infrastructure as a Service
(IaaS)</a></h2>
<dl>
<dt><a href="http://cc1.ifj.edu.pl">Cracow Cloud
One</a></dt>
@@ -288,7 +288,7 @@
</dd>
</dl>
- <h2><a name="libraries">Libraries</a></h2>
+ <h2><a id="libraries">Libraries</a></h2>
<dl>
<dt><a
href="http://libguestfs.org">libguestfs</a></dt>
@@ -321,7 +321,7 @@
</dd>
</dl>
- <h2><a name="livecd">LiveCD / Appliances</a></h2>
+ <h2><a id="livecd">LiveCD / Appliances</a></h2>
<dl>
<dt><a
href="http://et.redhat.com/~rjones/virt-p2v/">virt-p2v</a...
@@ -334,7 +334,7 @@
</dd>
</dl>
- <h2><a name="monitoring">Monitoring</a></h2>
+ <h2><a id="monitoring">Monitoring</a></h2>
<dl>
<dt><a
href="http://collectd.org/plugins/libvirt.shtml">collectd<...
<dd>
@@ -381,7 +381,7 @@
</dd>
</dl>
- <h2><a name="provisioning">Provisioning</a></h2>
+ <h2><a id="provisioning">Provisioning</a></h2>
<dl>
<dt><a
href="http://www.ibm.com/software/tivoli/products/prov-mgr/">...
Provisioning Manager</a></dt>
@@ -415,7 +415,7 @@
</dl>
- <h2><a name="web">Web applications</a></h2>
+ <h2><a id="web">Web applications</a></h2>
<dl>
<dt><a
href="http://community.abiquo.com/display/AbiCloud">AbiCloud...
@@ -468,7 +468,7 @@
</dd>
</dl>
- <h2><a name="mobile">Mobile applications</a></h2>
+ <h2><a id="mobile">Mobile applications</a></h2>
<dl>
<dt><a
href="https://market.android.com/details?id=vm.manager">VM
Manager</a></dt>
@@ -479,7 +479,7 @@
</dd>
</dl>
- <h2><a name="other">Other</a></h2>
+ <h2><a id="other">Other</a></h2>
<dl>
<dt><a
href="http://cuckoosandbox.org/">Cuckoo
Sandbox</a></dt>
diff --git a/docs/architecture.html.in b/docs/architecture.html.in
index 5d3d441ba..33a4ccb97 100644
--- a/docs/architecture.html.in
+++ b/docs/architecture.html.in
@@ -13,7 +13,7 @@
<ul id="toc"></ul>
- <h2><a name="Xen">Xen support</a></h2>
+ <h2><a id="Xen">Xen support</a></h2>
<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
@@ -46,7 +46,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>
- <h2><a name="QEmu">QEmu and KVM support</a></h2>
+ <h2><a id="QEmu">QEmu and KVM support</a></h2>
<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
@@ -60,7 +60,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>
- <h2><a name="drivers">Driver based
architecture</a></h2>
+ <h2><a id="drivers">Driver based
architecture</a></h2>
<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/auditlog.html.in b/docs/auditlog.html.in
index 0c778aafe..54da12b5c 100644
--- a/docs/auditlog.html.in
+++ b/docs/auditlog.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="intro">Introduction</a></h2>
+ <h2><a id="intro">Introduction</a></h2>
<p>
A number of the libvirt virtualization drivers (QEMU/KVM and LXC) include
@@ -17,7 +17,7 @@
the logs will usually end up in <code>/var/log/audit/audit.log</code>
</p>
- <h2><a name="config">Configuration</a></h2>
+ <h2><a id="config">Configuration</a></h2>
<p>
The libvirt audit integration is enabled by default on any host which has
@@ -48,7 +48,7 @@
mentioned above.
</p>
- <h2><a name="types">Message types</a></h2>
+ <h2><a id="types">Message types</a></h2>
<p>
Libvirt defines three core audit message types each of which will
@@ -90,7 +90,7 @@
<dd>Result of the action, either <code>success</code> or
<code>failed</code></dd>
</dl>
- <h3><a name="typecontrol">VIRT_CONTROL</a></h3>
+ <h3><a id="typecontrol">VIRT_CONTROL</a></h3>
<p>
Reports change in the lifecycle state of a virtual machine. The
<code>msg</code>
@@ -110,7 +110,7 @@
<dd>Namespace ID of the <code>init</code> process in a container.
Only if <code>op=init</code> and <code>virt=lxc</code></dd>
</dl>
- <h3><a name="typemachine">VIRT_MACHINE_ID</a></h3>
+ <h3><a id="typemachine">VIRT_MACHINE_ID</a></h3>
<p>
Reports the association of a security context with a guest. The
<code>msg</code>
@@ -126,7 +126,7 @@
<dd>Security context for the guest disk images and other assigned host
resources</dd>
</dl>
- <h3><a name="typeresource">VIRT_RESOURCE</a></h3>
+ <h3><a id="typeresource">VIRT_RESOURCE</a></h3>
<p>
Reports the usage of a host resource by a guest. The fields include will
@@ -137,7 +137,7 @@
be generated.
</p>
- <h4><a name="typeresourcevcpu">Virtual
CPU</a></h4>
+ <h4><a id="typeresourcevcpu">Virtual CPU</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
@@ -155,7 +155,7 @@
</dl>
- <h4><a name="typeresourcemem">Memory</a></h4>
+ <h4><a id="typeresourcemem">Memory</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
@@ -172,7 +172,7 @@
<dd>Updated memory size in bytes</dd>
</dl>
- <h4><a name="typeresourcedisk">Disk</a></h4>
+ <h4><a id="typeresourcedisk">Disk</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -188,7 +188,7 @@
<dd>Updated host file or device path acting as the disk backing
file</dd>
</dl>
- <h4><a name="typeresourcenic">Network
interface</a></h4>
+ <h4><a id="typeresourcenic">Network
interface</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
@@ -221,7 +221,7 @@
<dd>Name of the host network interface</dd>
</dl>
- <h4><a name="typeresourcefs">Filesystem</a></h4>
+ <h4><a id="typeresourcefs">Filesystem</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -237,7 +237,7 @@
<dd>Updated host directory, file or device path backing the
filesystem</dd>
</dl>
- <h4><a name="typeresourcehost">Host
device</a></h4>
+ <h4><a id="typeresourcehost">Host device</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -255,7 +255,7 @@
<dd>The path of the character device assigned to the guest, if
<code>resrc=hostdev</code></dd>
</dl>
- <h4><a name="typeresourcetpm">TPM</a></h4>
+ <h4><a id="typeresourcetpm">TPM</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -269,7 +269,7 @@
<dd>The path of the host TPM device assigned to the guest</dd>
</dl>
- <h4><a name="typeresourcerng">RNG</a></h4>
+ <h4><a id="typeresourcerng">RNG</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -285,7 +285,7 @@
<dd>Updated path of the host entropy source for the RNG</dd>
</dl>
- <h4><a
name="typeresourcechardev">console/serial/parallel/channel</a></h4>
+ <h4><a
id="typeresourcechardev">console/serial/parallel/channel</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -301,7 +301,7 @@
<dd>Updated path of the backing character device for given emulated
device</dd>
</dl>
- <h4><a
name="typeresourcesmartcard">smartcard</a></h4>
+ <h4><a
id="typeresourcesmartcard">smartcard</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -321,7 +321,7 @@
</dd>
</dl>
- <h4><a name="typeresourceredir">Redirected
device</a></h4>
+ <h4><a id="typeresourceredir">Redirected
device</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
@@ -337,7 +337,7 @@
<dd>The device type, only <code>USB redir</code>
allowed</dd>
</dl>
- <h4><a name="typeresourcecgroup">Control
group</a></h4>
+ <h4><a id="typeresourcecgroup">Control
group</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
@@ -353,7 +353,7 @@
</dl>
- <h4><a name="typeresourceshmem">Shared
memory</a></h4>
+ <h4><a id="typeresourceshmem">Shared
memory</a></h4>
<p>
The <code>msg</code> field will include the following sub-fields
</p>
diff --git a/docs/auth.html.in b/docs/auth.html.in
index f75454416..9c9afe7b4 100644
--- a/docs/auth.html.in
+++ b/docs/auth.html.in
@@ -14,7 +14,7 @@
<ul id="toc"></ul>
- <h2><a name="Auth_client_config">Client
configuration</a></h2>
+ <h2><a id="Auth_client_config">Client
configuration</a></h2>
<p>
When connecting to a remote hypervisor which requires authentication,
@@ -142,7 +142,7 @@ credentials=defgrp</pre>
to storage VNC or SPICE login credentials
</p>
- <h2><a name="ACL_server_config">Server
configuration</a></h2>
+ <h2><a id="ACL_server_config">Server
configuration</a></h2>
<p>
The libvirt daemon allows the administrator to choose the authentication
mechanisms used for client connections on each network socket independently.
@@ -153,7 +153,7 @@ currently a choice of <code>none</code>,
<code>polkit</code>, and <code>sasl</co
The SASL scheme can be further configured to choose between a large
number of different mechanisms.
</p>
- <h2><a name="ACL_server_unix_perms">UNIX socket
permissions/group</a></h2>
+ <h2><a id="ACL_server_unix_perms">UNIX socket
permissions/group</a></h2>
<p>
If libvirt does not contain support for PolicyKit, then access control for
the UNIX domain socket is done using traditional file user/group ownership
@@ -170,7 +170,7 @@ parameter. For example, setting the former to mode
<code>0770</code> and the
latter <code>wheel</code> would let any user in the wheel group connect to
the libvirt daemon.
</p>
- <h2><a name="ACL_server_polkit">UNIX socket PolicyKit
auth</a></h2>
+ <h2><a id="ACL_server_polkit">UNIX socket PolicyKit
auth</a></h2>
<p>
If libvirt contains support for PolicyKit, then access control options are
more advanced. The <code>auth_unix_rw</code> parameter will default to
@@ -204,7 +204,7 @@ ResultActive=yes</pre>
Further examples of PolicyKit setup can be found on the
<a
href="http://wiki.libvirt.org/page/SSHPolicyKitSetup">wiki
page</a>.
</p>
- <h2><a name="ACL_server_sasl">SASL pluggable
authentication</a></h2>
+ <h2><a id="ACL_server_sasl">SASL pluggable
authentication</a></h2>
<p>
Libvirt integrates with the cyrus-sasl library to provide a pluggable authentication
@@ -255,7 +255,7 @@ GSSAPI plugin is considered acceptably secure by modern standards:
TLS or UNIX socket listeners.
</p>
- <h3><a name="ACL_server_username">Username/password
auth</a></h3>
+ <h3><a id="ACL_server_username">Username/password
auth</a></h3>
<p>
As noted above, the DIGEST-MD5 mechanism is considered obsolete and should
not be used anymore. To provide a simple username/password auth scheme on
@@ -297,7 +297,7 @@ again:
<pre>
# saslpasswd2 -a libvirt -d fred
</pre>
- <h3><a name="ACL_server_kerberos">GSSAPI/Kerberos
auth</a></h3>
+ <h3><a id="ACL_server_kerberos">GSSAPI/Kerberos
auth</a></h3>
<p>
The plain TCP listener of the libvirt daemon defaults to using SASL for authentication.
The libvirt SASL config also defaults to GSSAPI, so there is no need to edit the
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 55ceb6007..7ba8dd6a4 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -7,7 +7,7 @@
<ul id="toc"></ul>
- <h2><a name="security">Security Issues</a></h2>
+ <h2><a id="security">Security Issues</a></h2>
<p>
If you think that an issue with libvirt may have security
@@ -19,7 +19,7 @@
<a href="securityprocess.html">security process</a> instead.
</p>
- <h2><a name="bugzilla">Bug Tracking</a></h2>
+ <h2><a id="bugzilla">Bug Tracking</a></h2>
<p>
If you are using libvirt binaries from a Linux distribution
@@ -27,7 +27,7 @@
first.
</p>
- <h2><a name="general">General libvirt bug
reports</a></h2>
+ <h2><a id="general">General libvirt bug
reports</a></h2>
<p>
The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla
Server</a>
@@ -69,7 +69,7 @@
<li><a
href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virt...
libvirt ticket</a></li>
</ul>
- <h2><a name="distribution">Linux Distribution specific bug
reports</a></h2>
+ <h2><a id="distribution">Linux Distribution specific bug
reports</a></h2>
<ul>
<li>
If you are using binaries from <strong>Fedora</strong>, enter
@@ -107,7 +107,7 @@
</ul>
- <h2><a name="quality">How to file high quality bug
reports</a></h2>
+ <h2><a id="quality">How to file high quality bug
reports</a></h2>
<p>
To increase the likelihood of your bug report being addressed it is
diff --git a/docs/cgroups.html.in b/docs/cgroups.html.in
index 60b47da1f..ac6390960 100644
--- a/docs/cgroups.html.in
+++ b/docs/cgroups.html.in
@@ -11,7 +11,7 @@
for applying resource management to their virtual machines and containers.
</p>
- <h2><a name="requiredControllers">Required
controllers</a></h2>
+ <h2><a id="requiredControllers">Required
controllers</a></h2>
<p>
The control groups filesystem supports multiple "controllers". By
default
@@ -42,7 +42,7 @@
which use them will cease to operate.
</p>
- <h2><a name="currentLayout">Current cgroups
layout</a></h2>
+ <h2><a id="currentLayout">Current cgroups
layout</a></h2>
<p>
As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been
@@ -63,14 +63,14 @@
in two, one describing systemd hosts and the other non-systemd hosts.
</p>
- <h3><a name="currentLayoutSystemd">Systemd cgroups
integration</a></h3>
+ <h3><a id="currentLayoutSystemd">Systemd cgroups
integration</a></h3>
<p>
On hosts which use systemd, each consumer maps to a systemd scope unit,
while partitions map to a system slice unit.
</p>
- <h4><a name="systemdScope">Systemd scope
naming</a></h4>
+ <h4><a id="systemdScope">Systemd scope
naming</a></h4>
<p>
The systemd convention is for the scope name of virtual machines / containers
@@ -83,7 +83,7 @@
The scope names map directly to the cgroup directory names.
</p>
- <h4><a name="systemdSlice">Systemd slice
naming</a></h4>
+ <h4><a id="systemdSlice">Systemd slice
naming</a></h4>
<p>
The systemd convention for slice naming is that a slice should include the
@@ -96,7 +96,7 @@
by libvirt will be associated with <code>machine.slice</code> by
default.
</p>
- <h4><a name="systemdLayout">Systemd cgroup
layout</a></h4>
+ <h4><a id="systemdLayout">Systemd cgroup
layout</a></h4>
<p>
Given this, a possible systemd cgroups layout involving 3 qemu guests,
@@ -145,7 +145,7 @@ $ROOT
+- machine-lxc\x2dcontainer3.scope
</pre>
- <h3><a name="currentLayoutGeneric">Non-systemd cgroups
layout</a></h3>
+ <h3><a id="currentLayoutGeneric">Non-systemd cgroups
layout</a></h3>
<p>
On hosts which do not use systemd, each consumer has a corresponding cgroup
@@ -206,7 +206,7 @@ $ROOT
+- container3.libvirt-lxc
</pre>
- <h2><a name="customPartiton">Using custom
partitions</a></h2>
+ <h2><a id="customPartiton">Using custom
partitions</a></h2>
<p>
If there is a need to apply resource constraints to groups of
@@ -255,7 +255,7 @@ $ROOT
later in this document did not support customization per guest.
</p>
- <h3><a name="createSystemd">Creating custom partitions
(systemd)</a></h3>
+ <h3><a id="createSystemd">Creating custom partitions
(systemd)</a></h3>
<p>
Given the XML config above, the admin on a systemd based host would
@@ -272,7 +272,7 @@ EOF
# systemctl start machine-testing.slice
</pre>
- <h3><a name="createNonSystemd">Creating custom partitions
(non-systemd)</a></h3>
+ <h3><a id="createNonSystemd">Creating custom partitions
(non-systemd)</a></h3>
<p>
Given the XML config above, the admin on a non-systemd based host
@@ -291,7 +291,7 @@ EOF
done
</pre>
- <h2><a name="resourceAPIs">Resource management
APIs/commands</a></h2>
+ <h2><a id="resourceAPIs">Resource management
APIs/commands</a></h2>
<p>
Since libvirt aims to provide an API which is portable across
@@ -354,7 +354,7 @@ swap_hard_limit: unlimited
network interfaces.
</p>
- <h2><a name="legacyLayout">Legacy cgroups
layout</a></h2>
+ <h2><a id="legacyLayout">Legacy cgroups
layout</a></h2>
<p>
Prior to libvirt 1.0.5, the cgroups layout created by libvirt was different
diff --git a/docs/compiling.html.in b/docs/compiling.html.in
index 3a0c7fdd1..af22199ef 100644
--- a/docs/compiling.html.in
+++ b/docs/compiling.html.in
@@ -2,11 +2,11 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml">
<body>
- <h1><a name="installation">libvirt
Installation</a></h1>
+ <h1><a id="installation">libvirt
Installation</a></h1>
<ul id="toc"></ul>
- <h2><a name="compiling">Compiling a release
tarball</a></h2>
+ <h2><a id="compiling">Compiling a release
tarball</a></h2>
<p>
libvirt uses the standard configure/make/install steps:
@@ -58,7 +58,7 @@ $ <b>sudo</b> <i>make install</i></pre>
to update your list of installed shared libs.
</p>
- <h2><a name="building">Building from a GIT
checkout</a></h2>
+ <h2><a id="building">Building from a GIT
checkout</a></h2>
<p>
The libvirt build process uses GNU autotools, so after obtaining a
diff --git a/docs/contact.html.in b/docs/contact.html.in
index 9ea16748a..1f84527b2 100644
--- a/docs/contact.html.in
+++ b/docs/contact.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="security">Security Issues</a></h2>
+ <h2><a id="security">Security Issues</a></h2>
<p>
If you think that an issue with libvirt may have security
@@ -18,7 +18,7 @@
<a href="securityprocess.html">security process</a> instead.
</p>
- <h2><a name="email">Mailing lists</a></h2>
+ <h2><a id="email">Mailing lists</a></h2>
<p>
There are three mailing-lists:
@@ -95,7 +95,7 @@
page.
</p>
- <h2><a name="irc">IRC discussion</a></h2>
+ <h2><a id="irc">IRC discussion</a></h2>
<p>
Some of the libvirt developers may be found on IRC on the <a
href="http://oftc.net">OFTC IRC</a>
diff --git a/docs/contribute.html.in b/docs/contribute.html.in
index 32935b1fa..c169b6700 100644
--- a/docs/contribute.html.in
+++ b/docs/contribute.html.in
@@ -11,7 +11,7 @@
<ul id="toc"></ul>
- <h2><a name="skills">Contributions
required</a></h2>
+ <h2><a id="skills">Contributions required</a></h2>
<p>
The libvirt project is always looking for new contributors to
@@ -97,7 +97,7 @@
these help forums.</li>
</ul>
- <h2><a name="comms">Communication</a></h2>
+ <h2><a id="comms">Communication</a></h2>
<p>
For full details on contacting other project contributors
@@ -106,7 +106,7 @@
between contributors:
</p>
- <h3><a name="email">Mailing lists</a></h3>
+ <h3><a id="email">Mailing lists</a></h3>
<p>
The project has a number of
@@ -118,7 +118,7 @@
to follow the traffic.
</p>
- <h3><a name="irc">Instant messaging /
chat</a></h3>
+ <h3><a id="irc">Instant messaging / chat</a></h3>
<p>
Contributors to libvirt are encouraged to join the
@@ -127,7 +127,7 @@
with others members.
</p>
- <h2><a name="outreach">Student / outreach coding
programs</a></h2>
+ <h2><a id="outreach">Student / outreach coding
programs</a></h2>
<p>
Since 2016, the libvirt project directly participates as an
diff --git a/docs/csharp.html.in b/docs/csharp.html.in
index 4c35c871d..e1c0fefba 100644
--- a/docs/csharp.html.in
+++ b/docs/csharp.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="description">Description</a></h2>
+ <h2><a id="description">Description</a></h2>
<p>
The C# libvirt bindings are a class library. They use a Microsoft
@@ -21,7 +21,7 @@
<p> </p>
- <h2><a name="requirements">Requirements</a></h2>
+ <h2><a id="requirements">Requirements</a></h2>
<p>
These bindings depend upon the libvirt libraries being installed.
@@ -34,7 +34,7 @@
<p> </p>
<!-- 2010-10-19 JC: Commented out until we have C# tarballs to download
- <h2><a name="getting">Getting them</a></h2>
+ <h2><a id="getting">Getting them</a></h2>
<p>
The latest versions of the libvirt C# bindings can be downloaded from:
@@ -46,7 +46,7 @@
</ul>
-->
- <h2><a name="git">GIT source repository</a></h2>
+ <h2><a id="git">GIT source repository</a></h2>
<p>
The C# bindings source code is maintained in a <a
href="http://git-scm.com/">git</a> repository available on
@@ -67,7 +67,7 @@ git clone
git://libvirt.org/libvirt-csharp.git
<p> </p>
- <h2><a name="usage">Usage</a></h2>
+ <h2><a id="usage">Usage</a></h2>
<p>
The libvirt C# bindings class library exposes the <b>Libvirt</b>
@@ -118,7 +118,7 @@ git clone
git://libvirt.org/libvirt-csharp.git
<p> </p>
- <h2><a name="authors">Authors</a></h2>
+ <h2><a id="authors">Authors</a></h2>
<p>
The C# bindings are the work of Arnaud Champion
@@ -128,7 +128,7 @@ git clone
git://libvirt.org/libvirt-csharp.git
<p> </p>
- <h2><a name="notes">Test Configuration</a></h2>
+ <h2><a id="notes">Test Configuration</a></h2>
<p>
Testing is performed using the following configurations:
@@ -141,7 +141,7 @@ git clone
git://libvirt.org/libvirt-csharp.git
<p> </p>
- <h2><a name="type">Type Coverage</a></h2>
+ <h2><a id="type">Type Coverage</a></h2>
<p>
Coverage of the libvirt types is:
@@ -219,7 +219,7 @@ git clone
git://libvirt.org/libvirt-csharp.git
<p> </p>
- <h2><a name="funccover">Function Coverage</a></h2>
+ <h2><a id="funccover">Function Coverage</a></h2>
<p>
Coverage of the libvirt functions is:
diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 030694549..21d79df4e 100644
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="releases">Project modules</a></h2>
+ <h2><a id="releases">Project modules</a></h2>
<p>
The libvirt project maintains a number of inter-related modules beyond
@@ -435,7 +435,7 @@
<li><a
href="https://libvirt.org/sources/">libvirt.org HTTPS
server</a></li>
</ul>
- <h2><a name="hourly">Hourly development
snapshots</a></h2>
+ <h2><a id="hourly">Hourly development
snapshots</a></h2>
<p>
Once an hour, an automated snapshot is made from the git server
@@ -450,7 +450,7 @@
<li><a
href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz"&g...
HTTP server</a></li>
</ul>
- <h2><a name="schedule">Primary release
schedule</a></h2>
+ <h2><a id="schedule">Primary release
schedule</a></h2>
<p>
The core libvirt module follows a time based plan, with releases made
@@ -462,7 +462,7 @@
independant ad-hoc releases with no fixed time schedle.
</p>
- <h2><a name="numbering">Release numbering</a></h2>
+ <h2><a id="numbering">Release numbering</a></h2>
<p>
Since libvirt 2.0.0, a time based version numbering rule
@@ -497,7 +497,7 @@
digits.
</p>
- <h2><a name="maintenance">Maintenance
releases</a></h2>
+ <h2><a id="maintenance">Maintenance
releases</a></h2>
<p>
In the git repository are several stable maintenance branches
for the core library, matching the
@@ -525,7 +525,7 @@
wiki page</a>.
</p>
- <h2><a name="git">GIT source repository</a></h2>
+ <h2><a id="git">GIT source repository</a></h2>
<p>
All modules maintained by the libvirt project have their primary
diff --git a/docs/drivers.html.in b/docs/drivers.html.in
index 61993861e..79b204d1a 100644
--- a/docs/drivers.html.in
+++ b/docs/drivers.html.in
@@ -18,7 +18,7 @@
network and storage driver active.
</p>
- <h2><a name="hypervisor">Hypervisor
drivers</a></h2>
+ <h2><a id="hypervisor">Hypervisor drivers</a></h2>
<p>
The hypervisor drivers currently supported by libvirt are:
@@ -40,7 +40,7 @@
<li><strong><a
href="drvbhyve.html">Bhyve</a></strong> - The BSD
Hypervisor</li>
</ul>
- <h2><a name="storage">Storage drivers</a></h2>
+ <h2><a id="storage">Storage drivers</a></h2>
<ul>
<li><strong><a
href="storage.html#StorageBackendDir">Directory
backend</a></strong></li>
diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in
index f083db91c..7b1829b65 100644
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve.html.in
@@ -31,7 +31,7 @@ $
Additional information on bhyve could be obtained on <a
href="http://bhyve.org/">bhyve.org</a>.
</p>
-<h2><a name="uri">Connections to the Bhyve
driver</a></h2>
+<h2><a id="uri">Connections to the Bhyve
driver</a></h2>
<p>
The libvirt bhyve driver is a single-instance privileged driver. Some sample
connection URIs are:
@@ -43,7 +43,7 @@ bhyve+unix:///system (local access)
bhyve+ssh://root@example.com/system (remote access, SSH tunnelled)
</pre>
-<h2><a name="exconfig">Example guest domain XML
configurations</a></h2>
+<h2><a id="exconfig">Example guest domain XML
configurations</a></h2>
<h3>Example config</h3>
<p>
@@ -206,9 +206,9 @@ Note the addition of <bootloader>.
<p>Please refer to the <a href="#uefi">UEFI</a> section for a
more detailed explanation.</p>
-<h2><a name="usage">Guest usage / management</a></h2>
+<h2><a id="usage">Guest usage / management</a></h2>
-<h3><a name="console">Connecting to a guest
console</a></h3>
+<h3><a id="console">Connecting to a guest
console</a></h3>
<p>
Guest console connection is supported through the <code>nmdm</code> device.
It could be enabled by adding
@@ -253,7 +253,7 @@ device) is:</p>
<pre>cu -l /dev/nmdm0B</pre>
-<h3><a name="xmltonative">Converting from domain XML to Bhyve
args</a></h3>
+<h3><a id="xmltonative">Converting from domain XML to Bhyve
args</a></h3>
<p>
The <code>virsh domxml-to-native</code> command can preview the actual
@@ -275,7 +275,7 @@ tweak them.</p>
/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s
3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l
com1,/dev/nmdm0A vm1
</pre>
-<h3><a name="zfsvolume">Using ZFS volumes</a></h3>
+<h3><a id="zfsvolume">Using ZFS volumes</a></h3>
<p>It's possible to use ZFS volumes as disk devices <span
class="since">since 1.2.8</span>.
An example of domain XML device entry for that will look like:</p>
@@ -291,7 +291,7 @@ An example of domain XML device entry for that will look
like:</p>
<p>Please refer to the <a href="storage.html">Storage
documentation</a> for more details on storage
management.</p>
-<h3><a name="grubbhyve">Using grub2-bhyve or Alternative
Bootloaders</a></h3>
+<h3><a id="grubbhyve">Using grub2-bhyve or Alternative
Bootloaders</a></h3>
<p>It's possible to boot non-FreeBSD guests by specifying an explicit
bootloader, e.g. <code>grub-bhyve(1)</code>. Arguments to the bootloader may
be
@@ -312,7 +312,7 @@ attempt to boot from the first partition in the disk image.</p>
<p>Caveat: <code>bootloader_args</code> does not support any quoting.
Filenames, etc, must not have spaces or they will be tokenized incorrectly.</p>
-<h3><a name="uefi">Using UEFI bootrom, VNC, and USB
tablet</a></h3>
+<h3><a id="uefi">Using UEFI bootrom, VNC, and USB
tablet</a></h3>
<p><span class="since">Since 3.2.0</span>, in addition to
<a href="#grubbhyve">grub-bhyve</a>,
non-FreeBSD guests could be also booted using an UEFI boot ROM, provided both guest OS
and
@@ -381,7 +381,7 @@ will be used. Please refer to the
manual page and the <a
href="https://wiki.freebsd.org/bhyve">bhyve
wiki</a> for more details on using
the <code>vgaconf</code> option.</p>
-<h3><a name="clockconfig">Clock configuration</a></h3>
+<h3><a id="clockconfig">Clock configuration</a></h3>
<p>Originally bhyve supported only localtime for RTC. Support for UTC time was
introduced in
<a
href="http://svnweb.freebsd.org/changeset/base/284894">r2848... for
<i>10-STABLE</i> and
@@ -409,7 +409,7 @@ you'll need to explicitly specify 'localtime' in this
case:</p>
</domain>
</pre>
-<h3><a name="e1000">e1000 NIC</a></h3>
+<h3><a id="e1000">e1000 NIC</a></h3>
<p>As of <a
href="https://svnweb.freebsd.org/changeset/base/302504">r302...
bhyve
supports Intel e1000 network adapter emulation. It's supported in libvirt
diff --git a/docs/drvesx.html.in b/docs/drvesx.html.in
index 5ba7bc121..d503d65b8 100644
--- a/docs/drvesx.html.in
+++ b/docs/drvesx.html.in
@@ -11,7 +11,7 @@
connect to a VMware vCenter 2.5/4.x/5.x (VPX).
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -20,7 +20,7 @@
</li>
</ul>
- <h2><a name="prereq">Deployment
pre-requisites</a></h2>
+ <h2><a id="prereq">Deployment
pre-requisites</a></h2>
<p>
None. Any out-of-the-box installation of VPX/ESX(i)/GSX should work. No
preparations are required on the server side, no libvirtd must be
@@ -34,7 +34,7 @@
VMware vSphere API</a>.
</p>
- <h2><a name="uri">Connections to the VMware ESX
driver</a></h2>
+ <h2><a id="uri">Connections to the VMware ESX
driver</a></h2>
<p>
Some example remote connection URIs for the driver are:
</p>
@@ -54,7 +54,7 @@
esx://example-esx.com/?no_verify=1 (ESX over HTTPS, but doesn't
verify the s
</p>
- <h3><a name="uriformat">URI Format</a></h3>
+ <h3><a id="uriformat">URI Format</a></h3>
<p>
URIs have this general form (<code>[...]</code> marks an optional
part).
</p>
@@ -93,7 +93,7 @@
vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
</pre>
- <h4><a name="extraparams">Extra
parameters</a></h4>
+ <h4><a id="extraparams">Extra parameters</a></h4>
<p>
Extra parameters can be added to a URI as part of the query string
(the part following <code>?</code>). A single parameter is formed by
a
@@ -188,7 +188,7 @@
vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
</table>
- <h3><a name="auth">Authentication</a></h3>
+ <h3><a id="auth">Authentication</a></h3>
<p>
In order to perform any useful operation the driver needs to log into
the ESX server. Therefore, only <code>virConnectOpenAuth</code> can
be
@@ -208,7 +208,7 @@
vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
</p>
- <h3><a name="certificates">Certificates for
HTTPS</a></h3>
+ <h3><a id="certificates">Certificates for
HTTPS</a></h3>
<p>
By default the ESX driver uses HTTPS to communicate with an ESX server.
Proper HTTPS communication requires correctly configured SSL
@@ -244,7 +244,7 @@ error: internal error curl_easy_perform() returned an error: Peer
certificate ca
</ul>
- <h3><a name="connproblems">Connection
problems</a></h3>
+ <h3><a id="connproblems">Connection
problems</a></h3>
<p>
There are also other causes for connection problems than the
<a href="#certificates">HTTPS certificate</a> related
ones.
@@ -303,7 +303,7 @@ error: invalid argument in libvirt was built without the 'esx'
driver
</ul>
- <h2><a name="questions">Questions blocking
tasks</a></h2>
+ <h2><a id="questions">Questions blocking
tasks</a></h2>
<p>
Some methods of the VI API start tasks, for example
<code>PowerOnVM_Task()</code>. Such tasks may be blocked by
questions
@@ -322,12 +322,12 @@ error: invalid argument in libvirt was built without the
'esx' driver
</p>
- <h2><a name="xmlspecial">Specialties in the domain XML
config</a></h2>
+ <h2><a id="xmlspecial">Specialties in the domain XML
config</a></h2>
<p>
There are several specialties in the domain XML config for ESX domains.
</p>
- <h3><a name="restrictions">Restrictions</a></h3>
+ <h3><a id="restrictions">Restrictions</a></h3>
<p>
There are some restrictions for some values of the domain XML config.
The driver will complain if this restrictions are violated.
@@ -347,7 +347,7 @@ error: invalid argument in libvirt was built without the 'esx'
driver
</ul>
- <h3><a name="datastore">Datastore
references</a></h3>
+ <h3><a id="datastore">Datastore
references</a></h3>
<p>
Storage is managed in datastores. VMware uses a special path format to
reference files in a datastore. Basically, the datastore name is put
@@ -366,7 +366,7 @@ error: invalid argument in libvirt was built without the 'esx'
driver
</p>
- <h3><a name="macaddresses">MAC addresses</a></h3>
+ <h3><a id="macaddresses">MAC addresses</a></h3>
<p>
VMware has registered two MAC address prefixes for domains:
<code>00:0c:29</code> and <code>00:50:56</code>. These
prefixes are
@@ -427,7 +427,7 @@ ethernet0.checkMACAddress = "false"
</pre>
- <h3><a name="hardware">Available hardware</a></h3>
+ <h3><a id="hardware">Available hardware</a></h3>
<p>
VMware ESX supports different models of SCSI controllers and network
cards.
@@ -523,14 +523,14 @@ ethernet0.checkMACAddress = "false"
</pre>
- <h2><a name="importexport">Import and export of domain XML
configs</a></h2>
+ <h2><a id="importexport">Import and export of domain XML
configs</a></h2>
<p>
The ESX driver currently supports a native config format known as
<code>vmware-vmx</code> to handle VMware VMX configs.
</p>
- <h3><a name="xmlimport">Converting from VMware VMX config to
domain XML config</a></h3>
+ <h3><a id="xmlimport">Converting from VMware VMX config to
domain XML config</a></h3>
<p>
The <code>virsh domxml-from-native</code> provides a way to convert
an
existing VMware VMX config into a domain XML config that can then be
@@ -621,7 +621,7 @@ Enter root password for
example.com:
</pre>
- <h3><a name="xmlexport">Converting from domain XML config to
VMware VMX config</a></h3>
+ <h3><a id="xmlexport">Converting from domain XML config to
VMware VMX config</a></h3>
<p>
The <code>virsh domxml-to-native</code> provides a way to convert a
domain XML config into a VMware VMX config.
@@ -675,7 +675,7 @@ ethernet0.address = "00:50:56:25:48:C7"
</pre>
- <h2><a name="xmlconfig">Example domain XML
configs</a></h2>
+ <h2><a id="xmlconfig">Example domain XML
configs</a></h2>
<h3>Fedora11 on x86_64</h3>
<pre>
@@ -704,7 +704,7 @@ ethernet0.address = "00:50:56:25:48:C7"
</pre>
- <h2><a name="migration">Migration</a></h2>
+ <h2><a id="migration">Migration</a></h2>
<p>
A migration cannot be initiated on an ESX server directly, a VMware
vCenter is necessary for this. The <code>vcenter</code> query
@@ -749,7 +749,7 @@ Enter administrator password for
example-vcenter.com:
</pre>
- <h2><a name="scheduler">Scheduler
configuration</a></h2>
+ <h2><a id="scheduler">Scheduler
configuration</a></h2>
<p>
The driver exposes the ESX CPU scheduler. The parameters listed below
are available to control the scheduler.
@@ -780,7 +780,7 @@ Enter administrator password for
example-vcenter.com:
</dl>
- <h2><a name="tools">VMware tools</a></h2>
+ <h2><a id="tools">VMware tools</a></h2>
<p>
Some actions require installed VMware tools. If the VMware tools are
not installed in the guest and one of the actions below is to be
@@ -796,7 +796,7 @@ Enter administrator password for
example-vcenter.com:
</ul>
- <h2><a name="links">Links</a></h2>
+ <h2><a id="links">Links</a></h2>
<ul>
<li>
<a
href="http://www.vmware.com/support/developer/vc-sdk/">
diff --git a/docs/drvhyperv.html.in b/docs/drvhyperv.html.in
index e87d8cbc1..ac2fa7017 100644
--- a/docs/drvhyperv.html.in
+++ b/docs/drvhyperv.html.in
@@ -9,7 +9,7 @@
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
The <a
href="http://www.microsoft.com/hyper-v-server/">Microsoft
Hyper-V</a>
@@ -18,7 +18,7 @@
</ul>
- <h2><a name="uri">Connections to the Microsoft Hyper-V
driver</a></h2>
+ <h2><a id="uri">Connections to the Microsoft Hyper-V
driver</a></h2>
<p>
Some example remote connection URIs for the driver are:
</p>
@@ -36,7 +36,7 @@
hyperv://example-hyperv.com/?transport=http (over HTTP)
</p>
- <h3><a name="uriformat">URI Format</a></h3>
+ <h3><a id="uriformat">URI Format</a></h3>
<p>
URIs have this general form (<code>[...]</code> marks an optional
part).
</p>
@@ -49,7 +49,7 @@ hyperv://[username@]hostname[:port]/[?extraparameters]
</p>
- <h4><a name="extraparams">Extra
parameters</a></h4>
+ <h4><a id="extraparams">Extra parameters</a></h4>
<p>
Extra parameters can be added to a URI as part of the query string
(the part following <code>?</code>). A single parameter is formed by
a
@@ -83,7 +83,7 @@ hyperv://[username@]hostname[:port]/[?extraparameters]
</table>
- <h3><a name="auth">Authentication</a></h3>
+ <h3><a id="auth">Authentication</a></h3>
<p>
In order to perform any useful operation the driver needs to log into
the Hyper-V server. Therefore, only <code>virConnectOpenAuth</code>
can
diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in
index c0c26ca35..180dc6834 100644
--- a/docs/drvlxc.html.in
+++ b/docs/drvlxc.html.in
@@ -18,7 +18,7 @@ particular sVirt for mandatory access control, auditing of operations,
integration with control groups and many other features.
</p>
-<h2><a name="cgroups">Control groups
Requirements</a></h2>
+<h2><a id="cgroups">Control groups
Requirements</a></h2>
<p>
In order to control the resource usage of processes inside containers, the
@@ -32,7 +32,7 @@ init service will be required. For further information, consult the
general
libvirt <a href="cgroups.html">cgroups documentation</a>.
</p>
-<h2><a name="namespaces">Namespace
requirements</a></h2>
+<h2><a id="namespaces">Namespace requirements</a></h2>
<p>
In order to separate processes inside a container from those in the
@@ -47,9 +47,9 @@ configured UID/GID mapping is a pre-requisite to making containers
secure, in the absence of sVirt confinement.</strong>
</p>
-<h2><a name="init">Default container setup</a></h2>
+<h2><a id="init">Default container setup</a></h2>
-<h3><a name="cliargs">Command line arguments</a></h3>
+<h3><a id="cliargs">Command line arguments</a></h3>
<p>
When the container "init" process is started, it will typically
@@ -70,7 +70,7 @@ would use the following XML
</os>
</pre>
-<h3><a name="envvars">Environment variables</a></h3>
+<h3><a id="envvars">Environment variables</a></h3>
<p>
When the container "init" process is started, it will be given several useful
@@ -108,7 +108,7 @@ Use of this is discouraged, in favour of passing arguments directly to
the
container init process via the <code>initarg</code> config
element.</dd>
</dl>
-<h3><a name="fsmounts">Filesystem mounts</a></h3>
+<h3><a id="fsmounts">Filesystem mounts</a></h3>
<p>
In the absence of any explicit configuration, the container will
@@ -131,7 +131,7 @@ only expose the sub-tree associated with the container</li>
</ul>
-<h3><a name="devnodes">Device nodes</a></h3>
+<h3><a id="devnodes">Device nodes</a></h3>
<p>
The container init process will be started with <code>CAP_MKNOD</code>
@@ -178,7 +178,7 @@ Further block or character devices will be made available to
containers
depending on their configuration.
</p>
-<h2><a name="security">Security
considerations</a></h2>
+<h2><a id="security">Security considerations</a></h2>
<p>
The libvirt LXC driver is fairly flexible in how it can be configured,
@@ -190,7 +190,7 @@ isolation between a container and the host must ensure that they are
writing a suitable configuration.
</p>
-<h3><a name="securenetworking">Network
isolation</a></h3>
+<h3><a id="securenetworking">Network
isolation</a></h3>
<p>
If the guest configuration does not list any network interfaces,
@@ -205,7 +205,7 @@ namespace is not wanted, then applications should set the
<code><features>....</features></code> element.
</p>
-<h3><a name="securefs">Filesystem isolation</a></h3>
+<h3><a id="securefs">Filesystem isolation</a></h3>
<p>
If the guest configuration does not list any filesystems, then
@@ -250,7 +250,7 @@ a bind mount to hide them. This is particularly important for the
</p>
-<h3><a name="secureusers">User and group
isolation</a></h3>
+<h3><a id="secureusers">User and group
isolation</a></h3>
<p>
If the guest configuration does not list any ID mapping, then the
@@ -281,7 +281,7 @@ causes libvirt to activate the user namespace feature.
</p>
-<h2><a name="activation">Systemd Socket Activation
Integration</a></h2>
+<h2><a id="activation">Systemd Socket Activation
Integration</a></h2>
<p>
The libvirt LXC driver provides the ability to pass across pre-opened file
@@ -477,7 +477,7 @@ configured to block read/write/mknod from all devices except those
that a container is authorized to use.
</p>
-<h2><a name="exconfig">Example configurations</a></h2>
+<h2><a id="exconfig">Example configurations</a></h2>
<h3>Example config version 1</h3>
<p></p>
@@ -542,7 +542,7 @@ debootstrap, whatever) under /opt/vm-1-root:
</domain>
</pre>
-<h2><a name="capabilities">Altering the available
capabilities</a></h2>
+<h2><a id="capabilities">Altering the available
capabilities</a></h2>
<p>
By default the libvirt LXC driver drops some capabilities among which CAP_MKNOD.
@@ -590,7 +590,7 @@ Note that allowing capabilities that are normally dropped by default
can serious
affect the security of the container and the host.
</p>
-<h2><a name="share">Inherit namespaces</a></h2>
+<h2><a id="share">Inherit namespaces</a></h2>
<p>
Libvirt allows you to inherit the namespace from container/process just like lxc tools
@@ -615,7 +615,7 @@ ignored.
The use of namespace passthrough requires libvirt >= 1.2.19
</p>
-<h2><a name="usage">Container usage /
management</a></h2>
+<h2><a id="usage">Container usage /
management</a></h2>
<p>
As with any libvirt virtualization driver, LXC containers can be
@@ -629,7 +629,7 @@ and LXC. For further details about usage of virsh consult its
manual page.
</p>
-<h3><a name="usageSave">Defining (saving) container
configuration</a></h3>
+<h3><a id="usageSave">Defining (saving) container
configuration</a></h3>
<p>
The <code>virsh define</code> command takes an XML configuration
@@ -640,7 +640,7 @@ document and loads it into libvirt, saving the configuration on disk
# virsh -c lxc:/// define myguest.xml
</pre>
-<h3><a name="usageView">Viewing container
configuration</a></h3>
+<h3><a id="usageView">Viewing container
configuration</a></h3>
<p>
The <code>virsh dumpxml</code> command can be used to view the
@@ -655,7 +655,7 @@ using the <code>--inactive</code> flag
# virsh -c lxc:/// dumpxml myguest
</pre>
-<h3><a name="usageStart">Starting containers</a></h3>
+<h3><a id="usageStart">Starting containers</a></h3>
<p>
The <code>virsh start</code> command can be used to start a
@@ -677,7 +677,7 @@ by libvirt, using the <code>virsh create</code> command.
</pre>
-<h3><a name="usageStop">Stopping containers</a></h3>
+<h3><a id="usageStop">Stopping containers</a></h3>
<p>
The <code>virsh shutdown</code> command can be used
@@ -702,7 +702,7 @@ request, it can be forcibly stopped using the <code>virsh
destroy</code>
</pre>
-<h3><a name="usageReboot">Rebooting a
container</a></h3>
+<h3><a id="usageReboot">Rebooting a container</a></h3>
<p>
The <code>virsh reboot</code> command can be used
@@ -717,7 +717,7 @@ to PID 1 inside the container.
# virsh -c lxc:/// reboot myguest
</pre>
-<h3><a name="usageDelete">Undefining (deleting) a container
configuration</a></h3>
+<h3><a id="usageDelete">Undefining (deleting) a container
configuration</a></h3>
<p>
The <code>virsh undefine</code> command can be used to delete the
@@ -729,7 +729,7 @@ running, this will turn it into a "transient" guest.
# virsh -c lxc:/// undefine myguest
</pre>
-<h3><a name="usageConnect">Connecting to a container
console</a></h3>
+<h3><a id="usageConnect">Connecting to a container
console</a></h3>
<p>
The <code>virsh console</code> command can be used to connect
@@ -752,7 +752,7 @@ as 'console0', 'console1', 'console2', etc.
# virsh -c lxc:/// console myguest --devname console1
</pre>
-<h3><a name="usageEnter">Running commands in a
container</a></h3>
+<h3><a id="usageEnter">Running commands in a
container</a></h3>
<p>
The <code>virsh lxc-enter-namespace</code> command can be used
@@ -764,7 +764,7 @@ and then execute an arbitrary command.
# virsh -c lxc:/// lxc-enter-namespace myguest -- /bin/ls -al /dev
</pre>
-<h3><a name="usageTop">Monitoring container
utilization</a></h3>
+<h3><a id="usageTop">Monitoring container
utilization</a></h3>
<p>
The <code>virt-top</code> command can be used to monitor the
@@ -776,7 +776,7 @@ host
# virt-top -c lxc:///
</pre>
-<h3><a name="usageConvert">Converting LXC container
configuration</a></h3>
+<h3><a id="usageConvert">Converting LXC container
configuration</a></h3>
<p>
The <code>virsh domxml-from-native</code> command can be used to convert
diff --git a/docs/drvnodedev.html.in b/docs/drvnodedev.html.in
index 26c52dd0d..439bbe7d0 100644
--- a/docs/drvnodedev.html.in
+++ b/docs/drvnodedev.html.in
@@ -98,7 +98,7 @@
<ul id="toc"/>
- <h2><a name="PCI">PCI host devices</a></h2>
+ <h2><a id="PCI">PCI host devices</a></h2>
<dl>
<dt><code>capability</code></dt>
<dd>
@@ -139,7 +139,7 @@
element will be included for each capability the device supports.
</p>
- <h3><a name="SRIOVCap">SR-IOV capability</a></h3>
+ <h3><a id="SRIOVCap">SR-IOV capability</a></h3>
<p>
Single root input/output virtualization (SR-IOV) allows sharing of the
PCIe resources by multiple virtual environments. That is achieved by
@@ -186,7 +186,7 @@
...
<device></pre>
- <h3><a name="MDEVCap">MDEV capability</a></h3>
+ <h3><a id="MDEVCap">MDEV capability</a></h3>
<p>
A PCI device capable of creating mediated devices will include a nested
capability <code>mdev_types</code> which enumerates all supported mdev
@@ -252,7 +252,7 @@
</capability>
</device></pre>
- <h2><a name="MDEV">Mediated devices
(MDEVs)</a></h2>
+ <h2><a id="MDEV">Mediated devices (MDEVs)</a></h2>
<p>
Mediated devices (<span class="since">Since 3.2.0</span>) are
software
devices defining resource allocation on the backing physical device which
diff --git a/docs/drvopenvz.html.in b/docs/drvopenvz.html.in
index e2e72e7a3..30e0c6b7e 100644
--- a/docs/drvopenvz.html.in
+++ b/docs/drvopenvz.html.in
@@ -15,7 +15,7 @@
undue trouble.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -24,7 +24,7 @@
</li>
</ul>
- <h2><a name="connections">Connections to OpenVZ
driver</a></h2>
+ <h2><a id="connections">Connections to OpenVZ
driver</a></h2>
<p>
The libvirt OpenVZ driver is a single-instance privileged driver,
@@ -40,7 +40,7 @@
openvz+tcp://example.com/system (remote access, SASl/Kerberos)
openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
</pre>
- <h2><a name="notes">Notes on bridged
networking</a></h2>
+ <h2><a id="notes">Notes on bridged
networking</a></h2>
<p>
Bridged networking enables a guest domain (ie container) to have its
@@ -49,7 +49,7 @@ openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
the host OS.
</p>
- <h3><a name="host">Host network devices</a></h3>
+ <h3><a id="host">Host network devices</a></h3>
<p>
One or more of the physical devices must be attached to a bridge. The
@@ -60,7 +60,7 @@ openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
physical device "eth0", or a bonding device "bond0".
</p>
- <h3><a name="tools">OpenVZ tools
configuration</a></h3>
+ <h3><a id="tools">OpenVZ tools
configuration</a></h3>
<p>
OpenVZ releases later than 3.0.23 ship with a standard network device
@@ -85,7 +85,7 @@ EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
</p>
- <h2><a name="example">Example guest domain XML
configuration</a></h2>
+ <h2><a id="example">Example guest domain XML
configuration</a></h2>
<p>
The current libvirt OpenVZ driver has a restriction that the
diff --git a/docs/drvphyp.html.in b/docs/drvphyp.html.in
index bb1f69e51..c75a830c4 100644
--- a/docs/drvphyp.html.in
+++ b/docs/drvphyp.html.in
@@ -10,7 +10,7 @@
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
The <a
href="http://www-03.ibm.com/systems/power/software/virtualization/in...
@@ -19,7 +19,7 @@
</ul>
- <h2><a name="uri">Connections to the PowerVM
driver</a></h2>
+ <h2><a id="uri">Connections to the PowerVM
driver</a></h2>
<p>
Some example remote connection URIs for the driver are:
</p>
@@ -38,7 +38,7 @@ phyp://user@ivm/system (IVM connection)
</p>
- <h3><a name="uriformat">URI Format</a></h3>
+ <h3><a id="uriformat">URI Format</a></h3>
<p>
URIs have this general form (<code>[...]</code> marks an
optional part, <code>{...|...}</code> marks a mandatory choice).
diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in
index fa1eca78a..a2a830a23 100644
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -11,7 +11,7 @@
version 0.12.0 or later.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -23,7 +23,7 @@
</li>
</ul>
- <h2><a name="prereq">Deployment
pre-requisites</a></h2>
+ <h2><a id="prereq">Deployment
pre-requisites</a></h2>
<ul>
<li>
@@ -43,7 +43,7 @@
</li>
</ul>
- <h2><a name="uris">Connections to QEMU
driver</a></h2>
+ <h2><a id="uris">Connections to QEMU
driver</a></h2>
<p>
The libvirt QEMU driver is a multi-instance driver, providing a single
@@ -63,14 +63,14 @@
qemu+tcp://example.com/system (remote access, SASl/Kerberos)
qemu+ssh://root@example.com/system (remote access, SSH tunnelled)
</pre>
- <h2><a name="security">Driver security
architecture</a></h2>
+ <h2><a id="security">Driver security
architecture</a></h2>
<p>
There are multiple layers to security in the QEMU driver, allowing for
flexibility in the use of QEMU based virtual machines.
</p>
- <h3><a name="securitydriver">Driver
instances</a></h3>
+ <h3><a id="securitydriver">Driver
instances</a></h3>
<p>
As explained above there are two ways to access the QEMU driver
@@ -94,7 +94,7 @@ qemu+ssh://root@example.com/system (remote access, SSH tunnelled)
elevated privileges.
</p>
- <h3><a name="securitydac">POSIX
users/groups</a></h3>
+ <h3><a id="securitydac">POSIX
users/groups</a></h3>
<p>
In the "session" instance, the POSIX users/groups model restricts QEMU
@@ -187,7 +187,7 @@ chmod o+x /path/to/directory
</li>
</ul>
- <h3><a name="securitycap">Linux process
capabilities</a></h3>
+ <h3><a id="securitycap">Linux process
capabilities</a></h3>
<p>
The libvirt QEMU driver has a build time option allowing it to use
@@ -224,7 +224,7 @@ chmod o+x /path/to/directory
to changing the <code>/etc/libvirt/qemu.conf</code> settings.
</p>
- <h3><a name="securityselinux">SELinux basic
confinement</a></h3>
+ <h3><a id="securityselinux">SELinux basic
confinement</a></h3>
<p>
The basic SELinux protection for QEMU virtual machines is intended to
@@ -255,7 +255,7 @@ chmod o+x /path/to/directory
SELinux boolean.
</p>
- <h3><a name="securitysvirt">SELinux sVirt
confinement</a></h3>
+ <h3><a id="securitysvirt">SELinux sVirt
confinement</a></h3>
<p>
The SELinux sVirt protection for QEMU virtual machines builds to the
@@ -305,7 +305,7 @@ chmod o+x /path/to/directory
file can be used to change the setting to
<code>security_driver="none"</code>
</p>
- <h3><a name="securitysvirtaa">AppArmor sVirt
confinement</a></h3>
+ <h3><a id="securitysvirtaa">AppArmor sVirt
confinement</a></h3>
<p>
When using basic AppArmor protection for the libvirtd daemon and
@@ -373,7 +373,7 @@ chmod o+x /path/to/directory
</p>
- <h3><a name="securityacl">Cgroups device
ACLs</a></h3>
+ <h3><a id="securityacl">Cgroups device
ACLs</a></h3>
<p>
Recent Linux kernels have a capability known as "cgroups" which is used
@@ -416,7 +416,7 @@ mount -t cgroup none /dev/cgroup -o devices
<code>/dev/cgroup/libvirt/qemu/$VMNAME/</code>
</p>
- <h2><a name="imex">Import and export of libvirt domain XML
configs</a></h2>
+ <h2><a id="imex">Import and export of libvirt domain XML
configs</a></h2>
<p>The QEMU driver currently supports a single native
config format known as <code>qemu-argv</code>. The data for this
format
@@ -424,7 +424,7 @@ mount -t cgroup none /dev/cgroup -o devices
then the QEMu binary name, finally followed by the QEMU command line
arguments</p>
- <h3><a name="xmlimport">Converting from QEMU args to domain
XML</a></h3>
+ <h3><a id="xmlimport">Converting from QEMU args to domain
XML</a></h3>
<p>
The <code>virsh domxml-from-native</code> provides a way to
@@ -473,7 +473,7 @@ $ virsh domxml-from-native qemu-argv demo.args
<p>NB, don't include the literal \ in the args, put everything on one
line</p>
- <h3><a name="xmlexport">Converting from domain XML to QEMU
args</a></h3>
+ <h3><a id="xmlexport">Converting from domain XML to QEMU
args</a></h3>
<p>
The <code>virsh domxml-to-native</code> provides a way to convert a
@@ -515,7 +515,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
-serial none -parallel none -usb
</pre>
- <h2><a name="qemucommand">Pass-through of arbitrary qemu
+ <h2><a id="qemucommand">Pass-through of arbitrary qemu
commands</a></h2>
<p>Libvirt provides an XML namespace and an optional
@@ -582,7 +582,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
</domain>
</pre>
- <h2><a name="xmlconfig">Example domain XML
config</a></h2>
+ <h2><a id="xmlconfig">Example domain XML
config</a></h2>
<h3>QEMU emulated guest on x86_64</h3>
diff --git a/docs/drvuml.html.in b/docs/drvuml.html.in
index 03c04eff4..832592024 100644
--- a/docs/drvuml.html.in
+++ b/docs/drvuml.html.in
@@ -13,7 +13,7 @@
has pre-created TAP devices.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
diff --git a/docs/drvvbox.html.in b/docs/drvvbox.html.in
index 4888dd266..d6ed6aabf 100644
--- a/docs/drvvbox.html.in
+++ b/docs/drvvbox.html.in
@@ -8,7 +8,7 @@
from version 2.2 onwards.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -43,7 +43,7 @@ vbox+ssh://user@example.com/session (remote access, SSH tunnelled)
work is completed to get the libvirtd daemon working there.</strong>
</p>
- <h2><a name="xmlconfig">Example domain XML
config</a></h2>
+ <h2><a id="xmlconfig">Example domain XML
config</a></h2>
<pre>
<domain type='vbox'>
diff --git a/docs/drvvirtuozzo.html.in b/docs/drvvirtuozzo.html.in
index 28c8242a1..3c4a85fe0 100644
--- a/docs/drvvirtuozzo.html.in
+++ b/docs/drvvirtuozzo.html.in
@@ -9,7 +9,7 @@
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
The <a
href="http://www.odin.com/products/virtuozzo/">Virtuozzo<... Solution.
@@ -17,7 +17,7 @@
</ul>
- <h2><a name="uri">Connections to the Virtuozzo
driver</a></h2>
+ <h2><a id="uri">Connections to the Virtuozzo
driver</a></h2>
<p>
The libvirt Virtuozzo driver is a single-instance privileged driver, with a
driver name of 'virtuozzo'. Some example connection URIs for the libvirt driver
are:
</p>
@@ -29,7 +29,7 @@
vz+tcp://example.com/system (remote access, SASl/Kerberos)
vz+ssh://root@example.com/system (remote access, SSH tunnelled)
</pre>
- <h2><a name="example">Example guest domain XML
configuration</a></h2>
+ <h2><a id="example">Example guest domain XML
configuration</a></h2>
<p>
Virtuozzo driver require at least one hard disk for new domains
diff --git a/docs/drvvmware.html.in b/docs/drvvmware.html.in
index 240afd005..45f6fe261 100644
--- a/docs/drvvmware.html.in
+++ b/docs/drvvmware.html.in
@@ -15,7 +15,7 @@
from <a
href="http://www.vmware.com/support/developer/vix-api/">here...;.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -51,7 +51,7 @@ vmwarews+tcp://user@example.com/session (remote access to VMware
Workstation, S
vmwarews+ssh://user@example.com/session (remote access to VMware Workstation, SSH
tunnelled)
</pre>
- <h2><a name="xmlconfig">Example domain XML
config</a></h2>
+ <h2><a id="xmlconfig">Example domain XML
config</a></h2>
<pre>
<domain type='vmware'>
diff --git a/docs/drvxen.html.in b/docs/drvxen.html.in
index 649ba42bf..6af15f44b 100644
--- a/docs/drvxen.html.in
+++ b/docs/drvxen.html.in
@@ -11,7 +11,7 @@
on any Xen release from 3.0.1 onwards.
</p>
- <h2><a name="project">Project Links</a></h2>
+ <h2><a id="project">Project Links</a></h2>
<ul>
<li>
@@ -20,7 +20,7 @@
</li>
</ul>
- <h2><a name="prereq">Deployment
pre-requisites</a></h2>
+ <h2><a id="prereq">Deployment
pre-requisites</a></h2>
<p>
The libvirt Xen driver uses a combination of channels to manage Xen
@@ -65,7 +65,7 @@
</li>
</ul>
- <h2><a name="uri">Connections to Xen
driver</a></h2>
+ <h2><a id="uri">Connections to Xen driver</a></h2>
<p>
The libvirt Xen driver is a single-instance privileged driver,
@@ -81,7 +81,7 @@
xen+tcp://example.com/ (remote access, SASl/Kerberos)
xen+ssh://root@example.com/ (remote access, SSH tunnelled)
</pre>
- <h2><a name="imex">Import and export of libvirt domain XML
configs</a></h2>
+ <h2><a id="imex">Import and export of libvirt domain XML
configs</a></h2>
<p>The Xen driver currently supports two native
config formats. The first known as <code>xen-xm</code> is the format
@@ -89,7 +89,7 @@ xen+ssh://root@example.com/ (remote access, SSH tunnelled)
known as <code>xen-sxpr</code>, is the format used for interacting
with the XenD's legacy HTTP RPC service.</p>
- <h3><a name="xmlimport">Converting from XM config files to
domain XML</a></h3>
+ <h3><a id="xmlimport">Converting from XM config files to domain
XML</a></h3>
<p>
The <code>virsh domxml-from-native</code> provides a way to convert an
@@ -135,7 +135,7 @@ xen+ssh://root@example.com/ (remote access, SSH tunnelled)
</devices>
</domain></pre>
- <h3><a name="xmlexport">Converting from domain XML to XM config
files</a></h3>
+ <h3><a id="xmlexport">Converting from domain XML to XM config
files</a></h3>
<p>
The <code>virsh domxml-to-native</code> provides a way to convert a
@@ -163,7 +163,7 @@ vnclisten = "0.0.0.0"
disk = [ "tap:aio:/var/lib/xen/images/rhel5pv.img,xvda,w",
"tap:qcow:/root/qcow1-xen.img,xvdd,w" ]
vif = [ "mac=00:16:3e:60:36:ba,bridge=virbr0,script=vif-bridge,vifname=vif5.0"
]</pre>
- <h2><a name="xmlconfig">Example domain XML
config</a></h2>
+ <h2><a id="xmlconfig">Example domain XML
config</a></h2>
<p>
Below are some example XML configurations for Xen guest domains.
diff --git a/docs/firewall.html.in b/docs/firewall.html.in
index 5bb6dc143..b21891ac9 100644
--- a/docs/firewall.html.in
+++ b/docs/firewall.html.in
@@ -35,8 +35,7 @@
</li>
</ul>
- <h3><a name="name-fw-virtual-network-driver"
- id="id-fw-virtual-network-driver">The virtual network
driver</a>
+ <h3><a id="fw-virtual-network-driver">The virtual network
driver</a>
</h3>
<p>The typical configuration for guests is to use bridging of the
physical NIC on the host to connect the guest directly to the LAN.
@@ -130,8 +129,7 @@ MASQUERADE all -- * * 192.168.122.0/24
!192.168.122.0/24</pre>
</li>
</ul>
- <h3><a name="name-fw-network-filter-driver"
- id="id-fw-network-filter-driver">The network filter
driver</a>
+ <h3><a id="fw-network-filter-driver">The network filter
driver</a>
</h3>
<p>This driver provides a fully configurable network filtering capability
that leverages ebtables, iptables and ip6tables. This was written by
diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in
index bc4511c66..d224523ef 100644
--- a/docs/formatcaps.html.in
+++ b/docs/formatcaps.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="elements">Element and attribute
overview</a></h2>
+ <h2><a id="elements">Element and attribute
overview</a></h2>
<p>As new virtualization engine support gets added to libvirt, and to
handle cases like QEMU supporting a variety of emulations, a query
@@ -28,7 +28,7 @@
the set of architectures the host can run at the moment.</p>
- <h3><a name="elementHost">Host
capabilities</a></h3>
+ <h3><a id="elementHost">Host capabilities</a></h3>
<p>The <code><host/></code> element consists of the
following child
elements:</p>
@@ -61,7 +61,7 @@
</dl>
- <h3><a name="elementGuest">Guest
capabilities</a></h3>
+ <h3><a id="elementGuest">Guest
capabilities</a></h3>
<p>While the <a href="#elementHost">previous section</a>
aims at host
capabilities, this one focuses on capabilities available to a guest
@@ -138,7 +138,7 @@
</dd>
</dl>
- <h3><a name="elementExamples">Examples</a></h3>
+ <h3><a id="elementExamples">Examples</a></h3>
<p>For example, in the case of a 64-bit machine with hardware
virtualization capabilities enabled in the chip and
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index bceddd2aa..fb22dd1db 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -14,7 +14,7 @@
</p>
- <h2><a name="elements">Element and attribute
overview</a></h2>
+ <h2><a id="elements">Element and attribute
overview</a></h2>
<p>
The root element required for all virtual machines is
@@ -28,7 +28,7 @@
</p>
- <h3><a name="elementsMetadata">General
metadata</a></h3>
+ <h3><a id="elementsMetadata">General
metadata</a></h3>
<pre>
<domain type='xen' id='3'>
@@ -82,14 +82,14 @@
element). <span class="since">Since
0.9.10</span></dd>
</dl>
- <h3><a name="elementsOS">Operating system
booting</a></h3>
+ <h3><a id="elementsOS">Operating system
booting</a></h3>
<p>
There are a number of different ways to boot virtual machines
each with their own pros and cons.
</p>
- <h4><a name="elementsOSBIOS">BIOS
bootloader</a></h4>
+ <h4><a id="elementsOSBIOS">BIOS
bootloader</a></h4>
<p>
Booting via the BIOS is available for hypervisors supporting
@@ -229,7 +229,7 @@
</dd>
</dl>
- <h4><a name="elementsOSBootloader">Host
bootloader</a></h4>
+ <h4><a id="elementsOSBootloader">Host
bootloader</a></h4>
<p>
Hypervisors employing paravirtualization do not usually emulate
@@ -262,7 +262,7 @@
</dl>
- <h4><a name="elementsOSKernel">Direct kernel
boot</a></h4>
+ <h4><a id="elementsOSKernel">Direct kernel
boot</a></h4>
<p>
When installing a new guest OS it is often useful to boot directly
@@ -315,7 +315,7 @@
<span class="since">Since 1.3.5 (QEMU
only)</span></dd>
</dl>
- <h4><a name="elementsOSContainer">Container
boot</a></h4>
+ <h4><a id="elementsOSContainer">Container
boot</a></h4>
<p>
When booting a domain using container based virtualization, instead
@@ -379,7 +379,7 @@
</pre>
- <h3><a name="elementsSysinfo">SMBIOS System
Information</a></h3>
+ <h3><a id="elementsSysinfo">SMBIOS System
Information</a></h3>
<p>
Some hypervisors allow control over what system information is
@@ -502,7 +502,7 @@
</dd>
</dl>
- <h3><a name="elementsCPUAllocation">CPU
Allocation</a></h3>
+ <h3><a id="elementsCPUAllocation">CPU
Allocation</a></h3>
<pre>
<domain>
@@ -610,7 +610,7 @@
</dd>
</dl>
- <h3><a name="elementsIOThreadsAllocation">IOThreads
Allocation</a></h3>
+ <h3><a id="elementsIOThreadsAllocation">IOThreads
Allocation</a></h3>
<p>
IOThreads are dedicated event loop threads for supported disk
devices to perform block I/O requests in order to improve
@@ -667,7 +667,7 @@
</dd>
</dl>
- <h3><a name="elementsCPUTuning">CPU
Tuning</a></h3>
+ <h3><a id="elementsCPUTuning">CPU Tuning</a></h3>
<pre>
<domain>
@@ -837,7 +837,7 @@
</dl>
- <h3><a name="elementsMemoryAllocation">Memory
Allocation</a></h3>
+ <h3><a id="elementsMemoryAllocation">Memory
Allocation</a></h3>
<pre>
<domain>
@@ -910,7 +910,7 @@
</dl>
- <h3><a name="elementsMemoryBacking">Memory
Backing</a></h3>
+ <h3><a id="elementsMemoryBacking">Memory
Backing</a></h3>
<pre>
<domain>
@@ -980,7 +980,7 @@
</dl>
- <h3><a name="elementsMemoryTuning">Memory
Tuning</a></h3>
+ <h3><a id="elementsMemoryTuning">Memory
Tuning</a></h3>
<pre>
<domain>
@@ -1044,7 +1044,7 @@
</dl>
- <h3><a name="elementsNUMATuning">NUMA Node
Tuning</a></h3>
+ <h3><a id="elementsNUMATuning">NUMA Node
Tuning</a></h3>
<pre>
<domain>
@@ -1105,7 +1105,7 @@
</dl>
- <h3><a name="elementsBlockTuning">Block I/O
Tuning</a></h3>
+ <h3><a id="elementsBlockTuning">Block I/O
Tuning</a></h3>
<pre>
<domain>
...
@@ -1174,7 +1174,7 @@
</dl></dd></dl>
- <h3><a name="resPartition">Resource
partitioning</a></h3>
+ <h3><a id="resPartition">Resource
partitioning</a></h3>
<p>
Hypervisors may allow for virtual machines to be placed into
@@ -1203,7 +1203,7 @@
in all mounted controllers. <span class="since">Since
1.0.5</span>
</p>
- <h3><a name="elementsCPU">CPU model and
topology</a></h3>
+ <h3><a id="elementsCPU">CPU model and
topology</a></h3>
<p>
Requirements for CPU model, its features and topology can be specified
@@ -1532,7 +1532,7 @@
This guest NUMA specification is currently available only for QEMU/KVM.
</p>
- <h3><a name="elementsEvents">Events
configuration</a></h3>
+ <h3><a id="elementsEvents">Events
configuration</a></h3>
<p>
It is sometimes necessary to override the default actions taken
@@ -1643,7 +1643,7 @@
<dd>Keep the domain running as if nothing happened.</dd>
</dl>
- <h3><a name="elementsPowerManagement">Power
Management</a></h3>
+ <h3><a id="elementsPowerManagement">Power
Management</a></h3>
<p>
<span class="since">Since 0.10.2</span> it is possible to
@@ -1667,7 +1667,7 @@
left with its default value.</dd>
</dl>
- <h3><a name="elementsFeatures">Hypervisor
features</a></h3>
+ <h3><a id="elementsFeatures">Hypervisor
features</a></h3>
<p>
Hypervisors may allow certain CPU / machine features to be
@@ -1869,7 +1869,7 @@
</dd>
</dl>
- <h3><a name="elementsTime">Time keeping</a></h3>
+ <h3><a id="elementsTime">Time keeping</a></h3>
<p>
The guest clock is typically initialized from the host clock.
@@ -2037,7 +2037,7 @@
</dd>
</dl>
- <h3><a name="elementsPerf">Performance monitoring
events</a></h3>
+ <h3><a id="elementsPerf">Performance monitoring
events</a></h3>
<p>
Some platforms allow monitoring of performance of the virtual machine and
@@ -2218,7 +2218,7 @@
</tr>
</table>
- <h3><a name="elementsDevices">Devices</a></h3>
+ <h3><a id="elementsDevices">Devices</a></h3>
<p>
The final set of XML elements are all used to describe devices
@@ -2245,7 +2245,7 @@
</dd>
</dl>
- <h4><a name="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
+ <h4><a id="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
<p>
Any device that looks like a disk, be it a floppy, harddisk,
@@ -3185,7 +3185,7 @@
</dd>
</dl>
- <h4><a
name="elementsFilesystems">Filesystems</a></h4>
+ <h4><a
id="elementsFilesystems">Filesystems</a></h4>
<p>
A directory on the host that can be accessed directly from the guest.
@@ -3368,7 +3368,7 @@
</dd>
</dl>
- <h4><a name="elementsAddress">Device
Addresses</a></h4>
+ <h4><a id="elementsAddress">Device
Addresses</a></h4>
<p>
Many devices have an optional <code><address></code>
@@ -3485,7 +3485,7 @@
</dd>
</dl>
- <h4><a name="elementsVirtio">Virtio-related
options</a></h4>
+ <h4><a id="elementsVirtio">Virtio-related
options</a></h4>
<p>
QEMU's virtio devices have some attributes related to the virtio transport
under
@@ -3498,7 +3498,7 @@
<span class="since">Since 3.5.0</span>
</p>
- <h4><a
name="elementsControllers">Controllers</a></h4>
+ <h4><a
id="elementsControllers">Controllers</a></h4>
<p>
Depending on the guest architecture, some device buses can
@@ -3884,7 +3884,7 @@
</devices>
...</pre>
- <h4><a name="elementsLease">Device leases</a></h4>
+ <h4><a id="elementsLease">Device leases</a></h4>
<p>
When using a lock manager, it may be desirable to record device leases
@@ -3924,9 +3924,9 @@
</dd>
</dl>
- <h4><a name="elementsHostDev">Host device
assignment</a></h4>
+ <h4><a id="elementsHostDev">Host device
assignment</a></h4>
- <h5><a name="elementsHostDevSubsys">USB / PCI / SCSI
devices</a></h5>
+ <h5><a id="elementsHostDevSubsys">USB / PCI / SCSI
devices</a></h5>
<p>
USB, PCI and SCSI devices attached to the host can be passed through
@@ -4237,7 +4237,7 @@
</dl>
- <h5><a name="elementsHostDevCaps">Block / character
devices</a></h5>
+ <h5><a id="elementsHostDevCaps">Block / character
devices</a></h5>
<p>
Block / character devices from the host can be passed through
@@ -4294,7 +4294,7 @@
</dd>
</dl>
- <h4><a name="elementsRedir">Redirected
devices</a></h4>
+ <h4><a id="elementsRedir">Redirected
devices</a></h4>
<p>
USB device redirection through a character device is
@@ -4361,7 +4361,7 @@
</dd>
</dl>
- <h4><a name="elementsSmartcard">Smartcard
devices</a></h4>
+ <h4><a id="elementsSmartcard">Smartcard
devices</a></h4>
<p>
A virtual smartcard device can be supplied to the guest via the
@@ -4454,7 +4454,7 @@
smartcard, with an address of bus=0 slot=0.
</p>
- <h4><a name="elementsNICS">Network
interfaces</a></h4>
+ <h4><a id="elementsNICS">Network
interfaces</a></h4>
<pre>
...
@@ -4494,7 +4494,7 @@
as <a href="#elementsAddress">documented above</a>.
</p>
- <h5><a name="elementsNICSVirtual">Virtual
network</a></h5>
+ <h5><a id="elementsNICSVirtual">Virtual
network</a></h5>
<p>
<strong><em>
@@ -4600,7 +4600,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSBridge">Bridge to
LAN</a></h5>
+ <h5><a id="elementsNICSBridge">Bridge to
LAN</a></h5>
<p>
<strong><em>
@@ -4691,7 +4691,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSSlirp">Userspace SLIRP
stack</a></h5>
+ <h5><a id="elementsNICSSlirp">Userspace SLIRP
stack</a></h5>
<p>
Provides a virtual LAN with NAT to the outside world. The virtual
@@ -4714,7 +4714,7 @@
...</pre>
- <h5><a name="elementsNICSEthernet">Generic ethernet
connection</a></h5>
+ <h5><a id="elementsNICSEthernet">Generic ethernet
connection</a></h5>
<p>
Provides a means for the administrator to execute an arbitrary script
@@ -4738,7 +4738,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSDirect">Direct attachment to physical
interface</a></h5>
+ <h5><a id="elementsNICSDirect">Direct attachment to physical
interface</a></h5>
<p>
Provides direct attachment of the virtual machine's NIC to the given
@@ -4883,7 +4883,7 @@
</pre>
- <h5><a name="elementsNICSHostdev">PCI
Passthrough</a></h5>
+ <h5><a id="elementsNICSHostdev">PCI
Passthrough</a></h5>
<p>
A PCI network device (specified by the <source> element)
@@ -4956,7 +4956,7 @@
...</pre>
- <h5><a name="elementsNICSMulticast">Multicast
tunnel</a></h5>
+ <h5><a id="elementsNICSMulticast">Multicast
tunnel</a></h5>
<p>
A multicast group is setup to represent a virtual network. Any VMs
@@ -4980,7 +4980,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSTCP">TCP tunnel</a></h5>
+ <h5><a id="elementsNICSTCP">TCP tunnel</a></h5>
<p>
A TCP client/server architecture provides a virtual network. One VM
@@ -5006,7 +5006,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSUDP">UDP unicast
tunnel</a></h5>
+ <h5><a id="elementsNICSUDP">UDP unicast
tunnel</a></h5>
<p>
A UDP unicast architecture provides a virtual network which enables
@@ -5030,7 +5030,7 @@
</devices>
...</pre>
- <h5><a name="elementsNICSModel">Setting the NIC
model</a></h5>
+ <h5><a id="elementsNICSModel">Setting the NIC
model</a></h5>
<pre>
...
@@ -5065,7 +5065,7 @@ qemu-kvm -net nic,model=? /dev/null
ne2k_isa i82551 i82557b i82559er ne2k_pci pcnet rtl8139 e1000 virtio
</p>
- <h5><a name="elementsDriverBackendOptions">Setting NIC
driver-specific options</a></h5>
+ <h5><a id="elementsDriverBackendOptions">Setting NIC
driver-specific options</a></h5>
<pre>
...
@@ -5240,7 +5240,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h5><a name="elementsBackendOptions">Setting network
backend-specific options</a></h5>
+ <h5><a id="elementsBackendOptions">Setting network
backend-specific options</a></h5>
<pre>
...
@@ -5271,7 +5271,7 @@ qemu-kvm -net nic,model=? /dev/null
adjust the size of send buffer in the host. <span
class="since">Since
0.8.8</span>
</p>
- <h5><a name="elementsNICSTargetOverride">Overriding the target
element</a></h5>
+ <h5><a id="elementsNICSTargetOverride">Overriding the target
element</a></h5>
<pre>
...
@@ -5309,7 +5309,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h5><a name="elementsNICSBoot">Specifying boot
order</a></h5>
+ <h5><a id="elementsNICSBoot">Specifying boot
order</a></h5>
<pre>
...
@@ -5332,7 +5332,7 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 0.8.8</span>
</p>
- <h5><a name="elementsNICSROM">Interface ROM BIOS
configuration</a></h5>
+ <h5><a id="elementsNICSROM">Interface ROM BIOS
configuration</a></h5>
<pre>
...
@@ -5361,7 +5361,7 @@ qemu-kvm -net nic,model=? /dev/null
network device.
<span class="since">Since 0.9.10 (QEMU and KVM only)</span>.
</p>
- <h5><a name="elementDomain">Setting up a network backend in a
driver domain</a></h5>
+ <h5><a id="elementDomain">Setting up a network backend in a
driver domain</a></h5>
<pre>
...
<devices>
@@ -5385,7 +5385,7 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 1.2.13 (Xen only)</span>
</p>
- <h5><a name="elementQoS">Quality of
service</a></h5>
+ <h5><a id="elementQoS">Quality of service</a></h5>
<pre>
...
@@ -5409,7 +5409,7 @@ qemu-kvm -net nic,model=? /dev/null
the Network XML.
</p>
- <h5><a name="elementVlanTag">Setting VLAN tag (on supported
network types only)</a></h5>
+ <h5><a id="elementVlanTag">Setting VLAN tag (on supported
network types only)</a></h5>
<pre>
...
@@ -5477,7 +5477,7 @@ qemu-kvm -net nic,model=? /dev/null
traffic for that VLAN will be tagged.
</p>
- <h5><a name="elementLink">Modifying virtual link
state</a></h5>
+ <h5><a id="elementLink">Modifying virtual link
state</a></h5>
<pre>
...
<devices>
@@ -5498,7 +5498,7 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 0.9.5</span>
</p>
- <h5><a name="mtu">MTU configuration</a></h5>
+ <h5><a id="mtu">MTU configuration</a></h5>
<pre>
...
<devices>
@@ -5517,7 +5517,7 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 3.1.0</span>
</p>
- <h5><a name="coalesce">Coalesce settings</a></h5>
+ <h5><a id="coalesce">Coalesce settings</a></h5>
<pre>
...
<devices>
@@ -5544,7 +5544,7 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 3.3.0</span>
</p>
- <h5><a name="ipconfig">IP configuration</a></h5>
+ <h5><a id="ipconfig">IP configuration</a></h5>
<pre>
...
<devices>
@@ -5623,7 +5623,7 @@ qemu-kvm -net nic,model=? /dev/null
configure the guest side of the interface (described above).
</p>
- <h5><a name="elementVhostuser">vhost-user
interface</a></h5>
+ <h5><a id="elementVhostuser">vhost-user
interface</a></h5>
<p>
<span class="since">Since 1.2.7</span> the vhost-user enables
the
@@ -5660,7 +5660,7 @@ qemu-kvm -net nic,model=? /dev/null
<code><model></code> element is mandatory.
</p>
- <h5><a name="elementNwfilter">Traffic filtering with
NWFilter</a></h5>
+ <h5><a id="elementNwfilter">Traffic filtering with
NWFilter</a></h5>
<p>
<span class="since">Since 0.8.0</span> an
<code>nwfilter</code> profile
@@ -5700,7 +5700,7 @@ qemu-kvm -net nic,model=? /dev/null
</p>
- <h4><a name="elementsInput">Input devices</a></h4>
+ <h4><a id="elementsInput">Input devices</a></h4>
<p>
Input devices allow interaction with the graphical framebuffer
@@ -5755,7 +5755,7 @@ qemu-kvm -net nic,model=? /dev/null
set. (<span class="since">Since 3.5.0</span>)
</p>
- <h4><a name="elementsHub">Hub devices</a></h4>
+ <h4><a id="elementsHub">Hub devices</a></h4>
<p>
A hub is a device that expands a single port into several so
@@ -5784,7 +5784,7 @@ qemu-kvm -net nic,model=? /dev/null
above</a>.
</p>
- <h4><a name="elementsGraphics">Graphical
framebuffers</a></h4>
+ <h4><a id="elementsGraphics">Graphical
framebuffers</a></h4>
<p>
A graphics device allows for graphical interaction with the
@@ -6082,7 +6082,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsVideo">Video devices</a></h4>
+ <h4><a id="elementsVideo">Video devices</a></h4>
<p>
A video device.
</p>
@@ -6197,7 +6197,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsConsole">Consoles, serial, parallel
& channel devices</a></h4>
+ <h4><a id="elementsConsole">Consoles, serial, parallel
& channel devices</a></h4>
<p>
A character device provides a way to interact with the virtual machine.
@@ -6283,14 +6283,14 @@ qemu-kvm -net nic,model=? /dev/null
slot.
</p>
- <h5><a name="elementsCharGuestInterface">Guest
interface</a></h5>
+ <h5><a id="elementsCharGuestInterface">Guest
interface</a></h5>
<p>
A character device presents itself to the guest as one of the following
types.
</p>
- <h6><a name="elementCharParallel">Parallel
port</a></h6>
+ <h6><a id="elementCharParallel">Parallel
port</a></h6>
<pre>
...
@@ -6308,7 +6308,7 @@ qemu-kvm -net nic,model=? /dev/null
usually 0, 1 or 2 parallel ports.
</p>
- <h6><a name="elementCharSerial">Serial
port</a></h6>
+ <h6><a id="elementCharSerial">Serial port</a></h6>
<pre>
...
@@ -6337,7 +6337,7 @@ qemu-kvm -net nic,model=? /dev/null
<code>type='pci'</code> to select desired location on the PCI
bus.
</p>
- <h6><a name="elementCharConsole">Console</a></h6>
+ <h6><a id="elementCharConsole">Console</a></h6>
<p>
The console element is used to represent interactive consoles. Depending
@@ -6409,7 +6409,7 @@ qemu-kvm -net nic,model=? /dev/null
only 1 console.
</p>
- <h6><a name="elementCharChannel">Channel</a></h6>
+ <h6><a id="elementCharChannel">Channel</a></h6>
<p>
This represents a private communication channel between the host and the
@@ -6501,14 +6501,14 @@ qemu-kvm -net nic,model=? /dev/null
<span class="since">Since 0.8.8</span></dd>
</dl>
- <h5><a name="elementsCharHostInterface">Host
interface</a></h5>
+ <h5><a id="elementsCharHostInterface">Host
interface</a></h5>
<p>
A character device presents itself to the host as one of the following
types.
</p>
- <h6><a name="elementsCharSTDIO">Domain
logfile</a></h6>
+ <h6><a id="elementsCharSTDIO">Domain
logfile</a></h6>
<p>
This disables all input on the character device, and sends output
@@ -6525,7 +6525,7 @@ qemu-kvm -net nic,model=? /dev/null
...</pre>
- <h6><a name="elementsCharFle">Device
logfile</a></h6>
+ <h6><a id="elementsCharFle">Device
logfile</a></h6>
<p>
A file is opened and all data sent to the character
@@ -6542,7 +6542,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharVC">Virtual
console</a></h6>
+ <h6><a id="elementsCharVC">Virtual
console</a></h6>
<p>
Connects the character device to the graphical framebuffer in
@@ -6559,7 +6559,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharNull">Null
device</a></h6>
+ <h6><a id="elementsCharNull">Null device</a></h6>
<p>
Connects the character device to the void. No data is ever
@@ -6575,7 +6575,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharPTY">Pseudo TTY</a></h6>
+ <h6><a id="elementsCharPTY">Pseudo TTY</a></h6>
<p>
A Pseudo TTY is allocated using /dev/ptmx. A suitable client
@@ -6600,7 +6600,7 @@ qemu-kvm -net nic,model=? /dev/null
with existing syntax for <console> tags.
</p>
- <h6><a name="elementsCharHost">Host device
proxy</a></h6>
+ <h6><a id="elementsCharHost">Host device
proxy</a></h6>
<p>
The character device is passed through to the underlying
@@ -6620,7 +6620,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharPipe">Named pipe</a></h6>
+ <h6><a id="elementsCharPipe">Named pipe</a></h6>
<p>
The character device writes output to a named pipe. See pipe(7) for
@@ -6637,7 +6637,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharTCP">TCP
client/server</a></h6>
+ <h6><a id="elementsCharTCP">TCP
client/server</a></h6>
<p>
The character device acts as a TCP client connecting to a
@@ -6726,7 +6726,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharUDP">UDP network
console</a></h6>
+ <h6><a id="elementsCharUDP">UDP network
console</a></h6>
<p>
The character device acts as a UDP netconsole service,
@@ -6744,7 +6744,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharUNIX">UNIX domain socket
client/server</a></h6>
+ <h6><a id="elementsCharUNIX">UNIX domain socket
client/server</a></h6>
<p>
The character device acts as a UNIX domain socket server,
@@ -6761,7 +6761,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsCharSpiceport">Spice
channel</a></h6>
+ <h6><a id="elementsCharSpiceport">Spice
channel</a></h6>
<p>
The character device is accessible through spice connection
@@ -6784,7 +6784,7 @@ qemu-kvm -net nic,model=? /dev/null
</devices>
...</pre>
- <h6><a name="elementsNmdm">Nmdm device</a></h6>
+ <h6><a id="elementsNmdm">Nmdm device</a></h6>
<p>
The nmdm device driver, available on FreeBSD, provides two
@@ -6815,7 +6815,7 @@ qemu-kvm -net nic,model=? /dev/null
to the guest console. Device is specified by a fully qualified path.</dd>
</dl>
- <h4><a name="elementsSound">Sound devices</a></h4>
+ <h4><a id="elementsSound">Sound devices</a></h4>
<p>
A virtual sound card can be attached to the host via the
@@ -6868,7 +6868,7 @@ qemu-kvm -net nic,model=? /dev/null
slot, <a href="#elementsAddress">documented above</a>.
</p>
- <h4><a name="elementsWatchdog">Watchdog
device</a></h4>
+ <h4><a id="elementsWatchdog">Watchdog
device</a></h4>
<p>
A virtual hardware watchdog device can be added to the guest via
@@ -6958,7 +6958,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsMemBalloon">Memory balloon
device</a></h4>
+ <h4><a id="elementsMemBalloon">Memory balloon
device</a></h4>
<p>
A virtual memory balloon device is added to all Xen and KVM/QEMU
@@ -7043,7 +7043,7 @@ qemu-kvm -net nic,model=? /dev/null
set. (<span class="since">Since 3.5.0</span>)
</dd>
</dl>
- <h4><a name="elementsRng">Random number generator
device</a></h4>
+ <h4><a id="elementsRng">Random number generator
device</a></h4>
<p>
The virtual random number generator device allows the host to pass
@@ -7137,7 +7137,7 @@ qemu-kvm -net nic,model=? /dev/null
</dl>
- <h4><a name="elementsTpm">TPM device</a></h4>
+ <h4><a id="elementsTpm">TPM device</a></h4>
<p>
The TPM device enables a QEMU guest to have access to TPM
@@ -7197,7 +7197,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsNVRAM">NVRAM device</a></h4>
+ <h4><a id="elementsNVRAM">NVRAM device</a></h4>
<p>
nvram device is always added to pSeries guest on PPC64, and its address
is allowed to be changed. Element <code>nvram</code> (only valid for
@@ -7231,7 +7231,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsPanic">panic device</a></h4>
+ <h4><a id="elementsPanic">panic device</a></h4>
<p>
panic device enables libvirt to receive panic notification from a QEMU
guest.
@@ -7288,7 +7288,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsShmem">Shared memory
device</a></h4>
+ <h4><a id="elementsShmem">Shared memory
device</a></h4>
<p>
A shared memory device allows to share a memory region between
@@ -7352,7 +7352,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsMemory">Memory
devices</a></h4>
+ <h4><a id="elementsMemory">Memory devices</a></h4>
<p>
In addition to the initial memory assigned to the guest, memory devices
@@ -7495,7 +7495,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h4><a name="elementsIommu">IOMMU devices</a></h4>
+ <h4><a id="elementsIommu">IOMMU devices</a></h4>
<p>
The <code>iommu</code> element can be used to add an IOMMU device.
@@ -7575,7 +7575,7 @@ qemu-kvm -net nic,model=? /dev/null
</dd>
</dl>
- <h3><a name="seclabel">Security label</a></h3>
+ <h3><a id="seclabel">Security label</a></h3>
<p>
The <code>seclabel</code> element allows control over the
@@ -7704,7 +7704,7 @@ qemu-kvm -net nic,model=? /dev/null
being on a file system that lacks security labeling.
</p>
- <h3><a name="keywrap">Key Wrap</a></h3>
+ <h3><a id="keywrap">Key Wrap</a></h3>
<p>The content of the optional <code>keywrap</code> element
specifies
whether the guest will be allowed to perform the S390 cryptographic key
@@ -7743,7 +7743,7 @@ qemu-kvm -net nic,model=? /dev/null
<p>Note: DEA/TDEA is synonymous with DES/TDES.</p>
- <h2><a name="examples">Example configs</a></h2>
+ <h2><a id="examples">Example configs</a></h2>
<p>
Example configurations for each driver are provide on the
diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
index 007cab62d..5e63fb7ca 100644
--- a/docs/formatdomaincaps.html.in
+++ b/docs/formatdomaincaps.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="Overview">Overview</a></h2>
+ <h2><a id="Overview">Overview</a></h2>
<p>Sometimes, when a new domain is to be created it may come handy to know
the capabilities of the hypervisor so the correct combination of devices and
@@ -37,7 +37,7 @@
management application to choose an appropriate mode for a pass-through
host device as well as which adapter to utilize.</p>
- <h2><a name="elements">Element and attribute
overview</a></h2>
+ <h2><a id="elements">Element and attribute
overview</a></h2>
<p> A new query interface was added to the virConnect API's to retrieve
the
XML listing of the set of domain capabilities (<span
class="since">Since
@@ -79,7 +79,7 @@
</dl>
- <h3><a name="elementsCPUAllocation">CPU
Allocation</a></h3>
+ <h3><a id="elementsCPUAllocation">CPU
Allocation</a></h3>
<p>Before any devices capability occurs, there might be a info on domain
wide capabilities, e.g. virtual CPUs:</p>
@@ -97,7 +97,7 @@
<dd>The maximum number of supported virtual CPUs</dd>
</dl>
- <h3><a name="elementsOSBIOS">BIOS
bootloader</a></h3>
+ <h3><a id="elementsOSBIOS">BIOS
bootloader</a></h3>
<p>Sometimes users might want to tweak some BIOS knobs or use
UEFI. For cases like that, <a
@@ -143,7 +143,7 @@
<loader/> element.</dd>
</dl>
- <h3><a name="elementsCPU">CPU
configuration</a></h3>
+ <h3><a id="elementsCPU">CPU configuration</a></h3>
<p>
The <code>cpu</code> element exposes options usable for configuring
@@ -208,7 +208,7 @@
</dd>
</dl>
- <h3><a name="elementsDevices">Devices</a></h3>
+ <h3><a id="elementsDevices">Devices</a></h3>
<p>
Another set of XML elements describe the supported devices and their
@@ -240,7 +240,7 @@
support the values <code>disk</code>, <code>cdrom</code>,
<code>floppy</code>, or <code>lun</code>.</p>
- <h4><a name="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
+ <h4><a id="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
<p>Disk capabilities are exposed under the <code>disk</code>
element. For
instance:</p>
@@ -283,7 +283,7 @@
</dl>
- <h4><a name="elementsGraphics">Graphical
framebuffers</a></h4>
+ <h4><a id="elementsGraphics">Graphical
framebuffers</a></h4>
<p>Graphics device capabilities are exposed under the
<code>graphics</code> element. For instance:</p>
@@ -310,7 +310,7 @@
</dl>
- <h4><a name="elementsVideo">Video device</a></h4>
+ <h4><a id="elementsVideo">Video device</a></h4>
<p>Video device capabilities are exposed under the
<code>video</code> element. For instance:</p>
@@ -339,7 +339,7 @@
</dl>
- <h4><a name="elementsHostDev">Host device
assignment</a></h4>
+ <h4><a id="elementsHostDev">Host device
assignment</a></h4>
<p>Some host devices can be passed through to a guest (e.g. USB, PCI and
SCSI). Well, only if the following is enabled:</p>
@@ -401,7 +401,7 @@
element.</dd>
</dl>
- <h3><a name="elementsFeatures">Features</a></h3>
+ <h3><a id="elementsFeatures">Features</a></h3>
<p>One more set of XML elements describe the supported features and
their capabilities. All features occur as children of the main
@@ -431,7 +431,7 @@
the domain XML documentation.
</p>
- <h4><a name="elementsGIC">GIC
capabilities</a></h4>
+ <h4><a id="elementsGIC">GIC capabilities</a></h4>
<p>GIC capabilities are exposed under the <code>gic</code>
element.</p>
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index b410dd64e..e8e618e42 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -13,7 +13,7 @@
<a
href="https://wiki.libvirt.org/page/Networking">relevant wiki
page</a>.
</p>
- <h2><a name="elements">Element and attribute
overview</a></h2>
+ <h2><a id="elements">Element and attribute
overview</a></h2>
<p>
The root element required for all virtual networks is
@@ -27,7 +27,7 @@
available <span class="since">since 0.3.0</span>
</p>
- <h3><a name="elementsMetadata">General
metadata</a></h3>
+ <h3><a id="elementsMetadata">General
metadata</a></h3>
<p>
The first elements provide basic metadata about the virtual
@@ -83,7 +83,7 @@
override the setting in the network.</dd>
</dl>
- <h3><a
name="elementsConnect">Connectivity</a></h3>
+ <h3><a id="elementsConnect">Connectivity</a></h3>
<p>
The next set of elements control how a virtual network is
@@ -514,7 +514,7 @@
</dd>
</dl>
- <h5><a name="elementQoS">Quality of
service</a></h5>
+ <h5><a id="elementQoS">Quality of service</a></h5>
<pre>
...
@@ -634,7 +634,7 @@
<span class="since">since 1.0.1</span>.
</p>
- <h5><a name="elementVlanTag">Setting VLAN tag (on supported
network types only)</a></h5>
+ <h5><a id="elementVlanTag">Setting VLAN tag (on supported
network types only)</a></h5>
<pre>
<network>
@@ -712,7 +712,7 @@
or <code><interface></code>.
</p>
- <h5><a
name="elementsPortgroup">Portgroups</a></h5>
+ <h5><a id="elementsPortgroup">Portgroups</a></h5>
<pre>
...
@@ -790,7 +790,7 @@
setting in the portgroup.
</p>
- <h5><a name="elementsStaticroute">Static
Routes</a></h5>
+ <h5><a id="elementsStaticroute">Static
Routes</a></h5>
<p>
Static route definitions are used to provide routing information
to the virtualization host for networks which are not directly
@@ -845,7 +845,7 @@
...
</pre>
- <h3><a name="elementsAddress">Addressing</a></h3>
+ <h3><a id="elementsAddress">Addressing</a></h3>
<p>
The final set of elements define the addresses (IPv4 and/or
@@ -1079,9 +1079,9 @@
</dd>
</dl>
- <h2><a name="examples">Example
configuration</a></h2>
+ <h2><a id="examples">Example
configuration</a></h2>
- <h3><a name="examplesNAT">NAT based
network</a></h3>
+ <h3><a id="examplesNAT">NAT based network</a></h3>
<p>
This example is the so called "default" virtual network. It is
@@ -1129,7 +1129,7 @@
</ip>
</network></pre>
- <h3><a name="examplesRoute">Routed network
config</a></h3>
+ <h3><a id="examplesRoute">Routed network
config</a></h3>
<p>
This is a variant on the default network which routes traffic
@@ -1211,7 +1211,7 @@
<route family="ipv6" address="2001:db8:ca2:8::"
prefix="64" gateway="2001:db8:ca2:7::4"/>
</network></pre>
- <h3><a name="examplesPrivate">Isolated network
config</a></h3>
+ <h3><a id="examplesPrivate">Isolated network
config</a></h3>
<p>
This variant provides a completely isolated private network
@@ -1233,7 +1233,7 @@
<ip family="ipv6" address="2001:db8:ca2:3::1"
prefix="64"/>
</network></pre>
- <h3><a name="examplesPrivate6">Isolated IPv6 network
config</a></h3>
+ <h3><a id="examplesPrivate6">Isolated IPv6 network
config</a></h3>
<p>
This variation of an isolated network defines only IPv6.
@@ -1259,7 +1259,7 @@
</ip>
</network></pre>
- <h3><a name="examplesBridge">Using an existing host
bridge</a></h3>
+ <h3><a id="examplesBridge">Using an existing host
bridge</a></h3>
<p>
<span class="since">Since 0.9.4</span>
@@ -1277,7 +1277,7 @@
<bridge name="br0"/>
</network></pre>
- <h3><a name="examplesDirect">Using a macvtap "direct"
connection</a></h3>
+ <h3><a id="examplesDirect">Using a macvtap "direct"
connection</a></h3>
<p>
<span class="since">Since 0.9.4, QEMU and KVM only, requires
@@ -1312,7 +1312,7 @@
</forward>
</network></pre>
- <h3><a name="examplesNoGateway">Network config with no gateway
addresses</a></h3>
+ <h3><a id="examplesNoGateway">Network config with no gateway
addresses</a></h3>
<p>
A valid network definition can contain no IPv4 or IPv6 addresses. Such a definition
diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in
index 32451d557..f82aecf3a 100644
--- a/docs/formatnode.html.in
+++ b/docs/formatnode.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="NodedevAttributes">Node Device
XML</a></h2>
+ <h2><a id="NodedevAttributes">Node Device
XML</a></h2>
<p>
There are several libvirt functions, all with the
@@ -340,7 +340,7 @@
</dd>
</dl>
- <h2><a name="nodeExample">Examples</a></h2>
+ <h2><a id="nodeExample">Examples</a></h2>
<p>The following are some example node device XML outputs:</p>
<pre>
diff --git a/docs/formatnwfilter.html.in b/docs/formatnwfilter.html.in
index 0d32893cb..5eb60e12c 100644
--- a/docs/formatnwfilter.html.in
+++ b/docs/formatnwfilter.html.in
@@ -12,7 +12,7 @@
their goals, concepts and XML format.
</p>
- <h2><a name="goals">Goals and background</a></h2>
+ <h2><a id="goals">Goals and background</a></h2>
<p>
The goal of the network filtering XML is to enable administrators
@@ -43,7 +43,7 @@
(QEMU, KVM)</span>
</p>
- <h2><a name="nwfconcepts">Concepts</a></h2>
+ <h2><a id="nwfconcepts">Concepts</a></h2>
<p>
The network traffic filtering subsystem enables configuration
of network traffic filtering rules on individual network
@@ -111,7 +111,7 @@
<br/><br/>
</p>
- <h3><a name="nwfconceptschains">Filtering
chains</a></h3>
+ <h3><a id="nwfconceptschains">Filtering
chains</a></h3>
<p>
Filtering rules are organized in filter chains. These chains can be
thought of as having a tree structure with packet
@@ -192,7 +192,7 @@
traverse the ARP chain.
<br/><br/>
</p>
- <h3><a name="nwfconceptschainpriorities">Filtering chain
priorities</a></h3>
+ <h3><a id="nwfconceptschainpriorities">Filtering chain
priorities</a></h3>
<p>
All chains are connected to the <code>root</code> chain. The order in
which those chains are accessed is influenced by the priority of the
@@ -236,7 +236,7 @@
node. The above example filter shows the default priority of -500
for <code>arp</code> chains.
</p>
- <h3><a name="nwfconceptsvars">Usage of variables in
filters</a></h3>
+ <h3><a id="nwfconceptsvars">Usage of variables in
filters</a></h3>
<p>
Two variables names have so far been reserved for usage by the
@@ -374,7 +374,7 @@ DSTPORTS = [ 80, 8080 ]
former notation always assumes the iterator with Id '0'.
</p>
- <h3><a name="nwfelemsRulesAdvIPAddrDetection">Automatic IP
address detection</a></h3>
+ <h3><a id="nwfelemsRulesAdvIPAddrDetection">Automatic IP
address detection</a></h3>
<p>
The detection of IP addresses used on a virtual machine's interface
is automatically activated if the variable <code>IP</code> is
referenced
@@ -448,7 +448,7 @@ DSTPORTS = [ 80, 8080 ]
</interface>
</pre>
- <h3><a name="nwfelemsReservedVars">Reserved
Variables</a></h3>
+ <h3><a id="nwfelemsReservedVars">Reserved
Variables</a></h3>
<p>
The following table lists reserved variables in use by libvirt.
</p>
@@ -485,7 +485,7 @@ DSTPORTS = [ 80, 8080 ]
</tr>
</table>
- <h2><a name="nwfelems">Element and attribute
overview</a></h2>
+ <h2><a id="nwfelems">Element and attribute
overview</a></h2>
<p>
The root element required for all network filters is
@@ -498,7 +498,7 @@ DSTPORTS = [ 80, 8080 ]
ipv4, ipv6, arp and rarp</code>.
</p>
- <h3><a name="nwfelemsRefs">References to other
filters</a></h3>
+ <h3><a id="nwfelemsRefs">References to other
filters</a></h3>
<p>
Any filter may hold references to other filters. Individual
filters may be referenced multiple times in a filter tree but
@@ -536,7 +536,7 @@ DSTPORTS = [ 80, 8080 ]
attached.
</p>
- <h3><a name="nwfelemsRules">Filter rules</a></h3>
+ <h3><a id="nwfelemsRules">Filter rules</a></h3>
<p>
The following XML shows a simple example of a network
traffic filter implementing a rule to drop traffic if
@@ -618,7 +618,7 @@ DSTPORTS = [ 80, 8080 ]
filtered.
</p>
- <h4><a name="nwfelemsRulesProto">Supported
protocols</a></h4>
+ <h4><a id="nwfelemsRulesProto">Supported
protocols</a></h4>
<p>
The following sections enumerate the list of protocols that
are supported by the network filtering subsystem. The
@@ -677,7 +677,7 @@ DSTPORTS = [ 80, 8080 ]
</p>
- <h5><a name="nwfelemsRulesProtoMAC">MAC
(Ethernet)</a></h5>
+ <h5><a id="nwfelemsRulesProtoMAC">MAC
(Ethernet)</a></h5>
<p>
Protocol ID: <code>mac</code>
<br/>
@@ -729,7 +729,7 @@ DSTPORTS = [ 80, 8080 ]
[...]
</pre>
- <h5><a name="nwfelemsRulesProtoVLAN">VLAN (802.1Q)</a>
+ <h5><a id="nwfelemsRulesProtoVLAN">VLAN (802.1Q)</a>
<span class="since">(Since 0.9.8)</span>
</h5>
<p>
@@ -784,7 +784,7 @@ DSTPORTS = [ 80, 8080 ]
Valid Strings for <code>encap-protocol</code> are: arp, ipv4, ipv6
</p>
- <h5><a name="nwfelemsRulesProtoSTP">STP (Spanning Tree
Protocol)</a>
+ <h5><a id="nwfelemsRulesProtoSTP">STP (Spanning Tree
Protocol)</a>
<span class="since">(Since 0.9.8)</span>
</h5>
<p>
@@ -926,7 +926,7 @@ DSTPORTS = [ 80, 8080 ]
</tr>
</table>
- <h5><a
name="nwfelemsRulesProtoARP">ARP/RARP</a></h5>
+ <h5><a
id="nwfelemsRulesProtoARP">ARP/RARP</a></h5>
<p>
Protocol ID: <code>arp</code> or <code>rarp</code>
<br/>
@@ -1022,7 +1022,7 @@ DSTPORTS = [ 80, 8080 ]
<br/><br/>
</p>
- <h5><a name="nwfelemsRulesProtoIP">IPv4</a></h5>
+ <h5><a id="nwfelemsRulesProtoIP">IPv4</a></h5>
<p>
Protocol ID: <code>ip</code>
<br/>
@@ -1118,7 +1118,7 @@ DSTPORTS = [ 80, 8080 ]
</p>
- <h5><a name="nwfelemsRulesProtoIPv6">IPv6</a></h5>
+ <h5><a id="nwfelemsRulesProtoIPv6">IPv6</a></h5>
<p>
Protocol ID: <code>ipv6</code>
<br/>
@@ -1228,7 +1228,7 @@ DSTPORTS = [ 80, 8080 ]
<br/><br/>
</p>
- <h5><a
name="nwfelemsRulesProtoTCP-ipv4">TCP/UDP/SCTP</a></h5>
+ <h5><a
id="nwfelemsRulesProtoTCP-ipv4">TCP/UDP/SCTP</a></h5>
<p>
Protocol ID: <code>tcp</code>, <code>udp</code>,
<code>sctp</code>
<br/>
@@ -1344,7 +1344,7 @@ DSTPORTS = [ 80, 8080 ]
</p>
- <h5><a name="nwfelemsRulesProtoICMP">ICMP</a></h5>
+ <h5><a id="nwfelemsRulesProtoICMP">ICMP</a></h5>
<p>
Protocol ID: <code>icmp</code>
<br/>
@@ -1458,7 +1458,7 @@ DSTPORTS = [ 80, 8080 ]
<br/><br/>
</p>
- <h5><a name="nwfelemsRulesProtoMisc">IGMP, ESP, AH, UDPLITE,
'ALL'</a></h5>
+ <h5><a id="nwfelemsRulesProtoMisc">IGMP, ESP, AH, UDPLITE,
'ALL'</a></h5>
<p>
Protocol ID: <code>igmp</code>, <code>esp</code>,
<code>ah</code>, <code>udplite</code>,
<code>all</code>
<br/>
@@ -1563,7 +1563,7 @@ DSTPORTS = [ 80, 8080 ]
</p>
- <h5><a name="nwfelemsRulesProtoTCP-ipv6">TCP/UDP/SCTP over
IPV6</a></h5>
+ <h5><a id="nwfelemsRulesProtoTCP-ipv6">TCP/UDP/SCTP over
IPV6</a></h5>
<p>
Protocol ID: <code>tcp-ipv6</code>, <code>udp-ipv6</code>,
<code>sctp-ipv6</code>
<br/>
@@ -1679,7 +1679,7 @@ DSTPORTS = [ 80, 8080 ]
</p>
- <h5><a
name="nwfelemsRulesProtoICMPv6">ICMPv6</a></h5>
+ <h5><a
id="nwfelemsRulesProtoICMPv6">ICMPv6</a></h5>
<p>
Protocol ID: <code>icmpv6</code>
<br/>
@@ -1779,7 +1779,7 @@ DSTPORTS = [ 80, 8080 ]
<br/><br/>
</p>
- <h5><a name="nwfelemsRulesProtoMiscv6">ESP, AH, UDPLITE,
'ALL' over IPv6</a></h5>
+ <h5><a id="nwfelemsRulesProtoMiscv6">ESP, AH, UDPLITE,
'ALL' over IPv6</a></h5>
<p>
Protocol ID: <code>esp-ipv6</code>, <code>ah-ipv6</code>,
<code>udplite-ipv6</code>, <code>all-ipv6</code>
<br/>
@@ -1868,13 +1868,13 @@ DSTPORTS = [ 80, 8080 ]
<br/><br/>
</p>
- <h3><a name="nwfelemsRulesAdv">Advanced Filter Configuration
Topics</a></h3>
+ <h3><a id="nwfelemsRulesAdv">Advanced Filter Configuration
Topics</a></h3>
<p>
The following sections discuss advanced filter configuration
topics.
</p>
- <h4><a name="nwfelemsRulesAdvTracking">Connection
tracking</a></h4>
+ <h4><a id="nwfelemsRulesAdvTracking">Connection
tracking</a></h4>
<p>
The network filtering subsystem (on Linux) makes use of the connection
tracking support of iptables. This helps in enforcing the
@@ -1908,7 +1908,7 @@ DSTPORTS = [ 80, 8080 ]
which may or may not be desirable.
</p>
- <h4><a name="nwfelemsRulesAdvLimiting">Limiting Number of
Connections</a></h4>
+ <h4><a id="nwfelemsRulesAdvLimiting">Limiting Number of
Connections</a></h4>
<p>
To limit the number of connections a VM may establish, a rule must
be provided that sets a limit of connections for a given
@@ -1981,7 +1981,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
traffic behavior in relation to idle connections.
</p>
- <h2><a name="nwfcli">Command line tools</a></h2>
+ <h2><a id="nwfcli">Command line tools</a></h2>
<p>
The libvirt command line tool <code>virsh</code> has been extended
with life-cycle support for network filters. All commands related
@@ -1996,7 +1996,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
<li>nwfilter-edit : edit a network filter given its name</li>
</ul>
- <h2><a name="nwfexamples">Pre-existing network
filters</a></h2>
+ <h2><a id="nwfexamples">Pre-existing network
filters</a></h2>
<p>
The following is a list of example network filters that are
automatically installed with libvirt.</p>
@@ -2051,7 +2051,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
on top of the prevention of packet spoofing.
</p>
- <h2><a name="nwfwrite">Writing your own
filters</a></h2>
+ <h2><a id="nwfwrite">Writing your own
filters</a></h2>
<p>
Since libvirt only provides a couple of example networking filters, you
@@ -2124,7 +2124,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
<code>udp-ipv6</code> traffic filtering node.
</p>
- <h3><a name="nwfwriteexample">Example custom
filter</a></h3>
+ <h3><a id="nwfwriteexample">Example custom
filter</a></h3>
<p>
As an example we want to now build a filter that fulfills the following
list of requirements:
@@ -2227,7 +2227,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
</rule>
</pre>
- <h3><a name="nwfwriteexample2nd">Second example custom
filter</a></h3>
+ <h3><a id="nwfwriteexample2nd">Second example custom
filter</a></h3>
<p>
In this example we now want to build a similar filter as in the
example above, but extend the list of requirements with an
@@ -2400,13 +2400,13 @@ modprobe ip_conntrack_ftp # if above is not available
</pre>
- <h2><a name="nwflimits">Limitations</a></h2>
+ <h2><a id="nwflimits">Limitations</a></h2>
<p>
The following sections list (current) limitations of the network
filtering subsystem.
</p>
- <h3><a name="nwflimitsmigr">VM Migration</a></h3>
+ <h3><a id="nwflimitsmigr">VM Migration</a></h3>
<p>
VM migration is only supported if the whole filter tree
that is referenced by a virtual machine's top level filter
@@ -2424,7 +2424,7 @@ modprobe ip_conntrack_ftp # if above is not available
0.8.1 or later in order not to lose the network traffic filters
associated with an interface.
</p>
- <h3><a name="nwflimitsvlan">VLAN filtering on
Linux</a></h3>
+ <h3><a id="nwflimitsvlan">VLAN filtering on
Linux</a></h3>
<p>
VLAN (802.1Q) packets, if sent by a virtual machine, cannot be filtered
with rules for protocol IDs <code>arp</code>,
<code>rarp</code>,
diff --git a/docs/formatsecret.html.in b/docs/formatsecret.html.in
index 21b93397c..86b8de5b9 100644
--- a/docs/formatsecret.html.in
+++ b/docs/formatsecret.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="SecretAttributes">Secret XML</a></h2>
+ <h2><a id="SecretAttributes">Secret XML</a></h2>
<p>
Secrets stored by libvirt may have attributes associated with them, using
@@ -47,7 +47,7 @@
</dd>
</dl>
- <h3><a name="VolumeUsageType">Usage type
"volume"</a></h3>
+ <h3><a id="VolumeUsageType">Usage type
"volume"</a></h3>
<p>
This secret is associated with a volume, whether the format is either
@@ -120,7 +120,7 @@ Secret value set
#
</pre>
- <h3><a name="CephUsageType">Usage type
"ceph"</a></h3>
+ <h3><a id="CephUsageType">Usage type
"ceph"</a></h3>
<p>
This secret is associated with a Ceph RBD (rados block device).
The <code><usage type='ceph'></code> element must
contain
@@ -187,7 +187,7 @@ Secret value set
</auth>
</pre>
- <h3><a name="iSCSIUsageType">Usage type
"iscsi"</a></h3>
+ <h3><a id="iSCSIUsageType">Usage type
"iscsi"</a></h3>
<p>
This secret is associated with an iSCSI target for CHAP authentication.
@@ -272,7 +272,7 @@ Secret value set
</auth>
</pre>
- <h3><a name="tlsUsageType">Usage type
"tls"</a></h3>
+ <h3><a id="tlsUsageType">Usage type
"tls"</a></h3>
<p>
This secret may be used in order to provide the passphrase for the
diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in
index 5e8e21c8a..52682646b 100644
--- a/docs/formatsnapshot.html.in
+++ b/docs/formatsnapshot.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="SnapshotAttributes">Snapshot
XML</a></h2>
+ <h2><a id="SnapshotAttributes">Snapshot
XML</a></h2>
<p>
There are several types of snapshots:
@@ -243,7 +243,7 @@
</dd>
</dl>
- <h2><a name="example">Examples</a></h2>
+ <h2><a id="example">Examples</a></h2>
<p>Using this XML to create a disk snapshot of just vda on a qemu
domain with two disks:</p>
diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in
index 4946ddf70..c6eab0278 100644
--- a/docs/formatstorage.html.in
+++ b/docs/formatstorage.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="StoragePool">Storage pool
XML</a></h2>
+ <h2><a id="StoragePool">Storage pool XML</a></h2>
<p>
Although all storage pool backends share the same public APIs and
@@ -29,7 +29,7 @@
3.1.0</span>). This corresponds to the
storage backend drivers listed further along in this document.
</p>
- <h3><a name="StoragePoolFirst">General
metadata</a></h3>
+ <h3><a id="StoragePoolFirst">General
metadata</a></h3>
<pre>
<pool type="iscsi">
@@ -66,7 +66,7 @@
pool. <span class="since">Since 0.4.1</span></dd>
</dl>
- <h3><a name="StoragePoolSource">Source
elements</a></h3>
+ <h3><a id="StoragePoolSource">Source
elements</a></h3>
<p>
A single <code>source</code> element is contained within the top level
@@ -394,7 +394,7 @@
is backend specific. <span class="since">Since
0.8.4</span></dd>
</dl>
- <h3><a name="StoragePoolTarget">Target
elements</a></h3>
+ <h3><a id="StoragePoolTarget">Target
elements</a></h3>
<p>
A single <code>target</code> element is contained within the top level
@@ -458,7 +458,7 @@
</dd>
</dl>
- <h3><a name="StoragePoolExtents">Device
extents</a></h3>
+ <h3><a id="StoragePoolExtents">Device
extents</a></h3>
<p>
If a storage pool exposes information about its underlying
@@ -478,7 +478,7 @@
device, measured in bytes. <span class="since">Since
0.4.1</span>
</p>
- <h2><a name="StorageVol">Storage volume
XML</a></h2>
+ <h2><a id="StorageVol">Storage volume XML</a></h2>
<p>
A storage volume will generally be either a file or a device
node; <span class="since">since 1.2.0</span>, an optional
@@ -488,7 +488,7 @@
XML format is available <span class="since">since
0.4.1</span>
</p>
- <h3><a name="StorageVolFirst">General
metadata</a></h3>
+ <h3><a id="StorageVolFirst">General
metadata</a></h3>
<pre>
<volume type='file'>
@@ -567,7 +567,7 @@
on the local host. <span class="since">Since
0.4.1</span></dd>
</dl>
- <h3><a name="StorageVolTarget">Target
elements</a></h3>
+ <h3><a id="StorageVolTarget">Target
elements</a></h3>
<p>
A single <code>target</code> element is contained within the top level
@@ -683,7 +683,7 @@
</dd>
</dl>
- <h3><a name="StorageVolBacking">Backing store
elements</a></h3>
+ <h3><a id="StorageVolBacking">Backing store
elements</a></h3>
<p>
A single <code>backingStore</code> element is contained within the top
level
@@ -729,14 +729,14 @@
</dd>
</dl>
- <h2><a name="examples">Example
configuration</a></h2>
+ <h2><a id="examples">Example
configuration</a></h2>
<p>
Here are a couple of examples, for a more complete set demonstrating
every type of storage pool, consult the <a
href="storage.html">storage driver page</a>
</p>
- <h3><a name="exampleFile">File based storage
pool</a></h3>
+ <h3><a id="exampleFile">File based storage
pool</a></h3>
<pre>
<pool type="dir">
@@ -746,7 +746,7 @@
</target>
</pool></pre>
- <h3><a name="exampleISCSI">iSCSI based storage
pool</a></h3>
+ <h3><a id="exampleISCSI">iSCSI based storage
pool</a></h3>
<pre>
<pool type="iscsi">
@@ -763,7 +763,7 @@
</target>
</pool></pre>
- <h3><a name="exampleVol">Storage volume</a></h3>
+ <h3><a id="exampleVol">Storage volume</a></h3>
<pre>
<volume>
@@ -781,7 +781,7 @@
</target>
</volume></pre>
- <h3><a name="exampleLuks">Storage volume using
LUKS</a></h3>
+ <h3><a id="exampleLuks">Storage volume using
LUKS</a></h3>
<pre>
<volume>
diff --git a/docs/formatstorageencryption.html.in b/docs/formatstorageencryption.html.in
index ec09bc661..ba19e268a 100644
--- a/docs/formatstorageencryption.html.in
+++ b/docs/formatstorageencryption.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="StorageEncryption">Storage volume encryption
XML</a></h2>
+ <h2><a id="StorageEncryption">Storage volume encryption
XML</a></h2>
<p>
Storage volumes may be encrypted, the XML snippet described below is used
@@ -37,7 +37,7 @@
secret value at the time of volume creation, and store it using the
specified <code>uuid</code>.
</p>
- <h3><a name="StorageEncryptionDefault">"default"
format</a></h3>
+ <h3><a id="StorageEncryptionDefault">"default"
format</a></h3>
<p>
<code><encryption format="default"/></code> can
be specified only
when creating a qcow volume. If the volume is successfully created, the
@@ -47,7 +47,7 @@
in later operations with the volume, or when setting up a domain that
uses the volume.
</p>
- <h3><a name="StorageEncryptionQcow">"qcow"
format</a></h3>
+ <h3><a id="StorageEncryptionQcow">"qcow"
format</a></h3>
<p>
The <code>qcow</code> format specifies that the built-in encryption
support in <code>qcow</code>- or
<code>qcow2</code>-formatted volume
@@ -56,7 +56,7 @@
the <code>secret</code> element is not present during volume creation,
a secret is automatically generated and attached to the volume.
</p>
- <h3><a name="StorageEncryptionLuks">"luks"
format</a></h3>
+ <h3><a id="StorageEncryptionLuks">"luks"
format</a></h3>
<p>
The <code>luks</code> format is specific to a luks encrypted volume
and the secret is used in order to either encrypt during volume creation
@@ -119,7 +119,7 @@
</dl>
- <h2><a name="example">Examples</a></h2>
+ <h2><a id="example">Examples</a></h2>
<p>
Here is a simple example, specifying use of the <code>qcow</code>
format:
diff --git a/docs/governance.html.in b/docs/governance.html.in
index 2f0428130..81c093bbd 100644
--- a/docs/governance.html.in
+++ b/docs/governance.html.in
@@ -14,7 +14,7 @@
influence, within the community.
</p>
- <h2><a name="codeofconduct">Code of
conduct</a></h2>
+ <h2><a id="codeofconduct">Code of conduct</a></h2>
<p>
The libvirt project community covers people from a wide variety of
@@ -49,7 +49,7 @@
from them. Playing a blame game doesn't help anyone.</li>
</ul>
- <h2><a name="roles">Roles and
responsibilities</a></h2>
+ <h2><a id="roles">Roles and
responsibilities</a></h2>
<h3><a href="users">Users</a></h3>
@@ -91,7 +91,7 @@
ways listed in the next section.
</p>
- <h3><a name="contributors">Contributors</a></h3>
+ <h3><a id="contributors">Contributors</a></h3>
<p>
The contributors are community members who have some concrete impact
@@ -156,7 +156,7 @@
covered are found in the source repositories, or website in question.
</p>
- <h3><a name="committers">Committers</a></h3>
+ <h3><a id="committers">Committers</a></h3>
<p>
The committers are the subset of contributors who have direct access
@@ -227,7 +227,7 @@
to retain their role as a committer.
</p>
- <h3><a name="secteam">Security team</a></h3>
+ <h3><a id="secteam">Security team</a></h3>
<p>
The security team consists of a subset of the project committers
@@ -252,7 +252,7 @@
before disclosing a private issue.
</p>
- <h2><a name="roughconsensus">Rough
consensus</a></h2>
+ <h2><a id="roughconsensus">Rough
consensus</a></h2>
<p>
A core concept for governance of the project described above is
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 975ee6935..efd053d16 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="patches">General tips for contributing
patches</a></h2>
+ <h2><a id="patches">General tips for contributing
patches</a></h2>
<ol>
<li>
<p>Discuss any large changes on the mailing list first. Post patches
@@ -336,7 +336,7 @@
Richard Jones' guide to working with open source projects</a>.
</p>
- <h2><a name="tooling">Tooling</a></h2>
+ <h2><a id="tooling">Tooling</a></h2>
<p>
libvirt includes support for some useful development tools right in its
@@ -356,7 +356,7 @@
</li>
</ul>
- <h2><a name="naming">Naming conventions</a></h2>
+ <h2><a id="naming">Naming conventions</a></h2>
<p>
When reading libvirt code, a number of different naming conventions will
@@ -450,7 +450,7 @@
</dd>
</dl>
- <h2><a name="indent">Code indentation</a></h2>
+ <h2><a id="indent">Code indentation</a></h2>
<p>
Libvirt's C source code generally adheres to some basic code-formatting
conventions. The existing code base is not totally consistent on this
@@ -487,7 +487,7 @@
which will load the .lvimrc only when you edit libvirt code.
</p>
- <h2><a name="formatting">Code formatting (especially for new
code)</a></h2>
+ <h2><a id="formatting">Code formatting (especially for new
code)</a></h2>
<p>
With new code, we can be even more strict.
@@ -523,7 +523,7 @@
</p>
- <h2><a name="bracket_spacing">Bracket
spacing</a></h2>
+ <h2><a id="bracket_spacing">Bracket
spacing</a></h2>
<p>
The keywords <code>if</code>, <code>for</code>,
<code>while</code>,
@@ -572,7 +572,7 @@
int foo(int wizz); // Good
</pre>
- <h2><a name="comma">Commas</a></h2>
+ <h2><a id="comma">Commas</a></h2>
<p>
Commas should always be followed by a space or end of line, and
@@ -609,7 +609,7 @@
};
</pre>
- <h2><a name="semicolon">Semicolons</a></h2>
+ <h2><a id="semicolon">Semicolons</a></h2>
<p>
Semicolons should never have a space beforehand. Inside the
@@ -638,7 +638,7 @@
}
</pre>
- <h2><a name="curly_braces">Curly braces</a></h2>
+ <h2><a id="curly_braces">Curly braces</a></h2>
<p>
Omit the curly braces around an <code>if</code>,
<code>while</code>,
@@ -819,7 +819,7 @@
}
</pre>
- <h2><a name="preprocessor">Preprocessor</a></h2>
+ <h2><a id="preprocessor">Preprocessor</a></h2>
<p>Macros defined with an ALL_CAPS name should generally be
assumed to be unsafe with regards to arguments with side-effects
@@ -844,7 +844,7 @@
#endif
</pre>
- <h2><a name="types">C types</a></h2>
+ <h2><a id="types">C types</a></h2>
<p>
Use the right type.
@@ -919,7 +919,7 @@
it points to, or it is aliased to another pointer that is.
</p>
- <h2><a name="memalloc">Low level memory
management</a></h2>
+ <h2><a id="memalloc">Low level memory
management</a></h2>
<p>
Use of the malloc/free/realloc/calloc APIs is deprecated in the libvirt
@@ -1013,7 +1013,7 @@
</li>
</ul>
- <h2><a name="file_handling">File handling</a></h2>
+ <h2><a id="file_handling">File handling</a></h2>
<p>
Usage of the <code>fdopen()</code>, <code>close()</code>,
<code>fclose()</code>
@@ -1059,7 +1059,7 @@
</li>
</ul>
- <h2><a name="string_comparision">String
comparisons</a></h2>
+ <h2><a id="string_comparision">String
comparisons</a></h2>
<p>
Do not use the strcmp, strncmp, etc functions directly. Instead use
@@ -1109,7 +1109,7 @@
</ul>
- <h2><a name="string_copying">String
copying</a></h2>
+ <h2><a id="string_copying">String copying</a></h2>
<p>
Do not use the strncpy function. According to the man page, it
@@ -1169,7 +1169,7 @@
and usually considered a flaw.
</p>
- <h2><a name="strbuf">Variable length string
buffer</a></h2>
+ <h2><a id="strbuf">Variable length string
buffer</a></h2>
<p>
If there is a need for complex string concatenations, avoid using
@@ -1202,7 +1202,7 @@
</pre>
- <h2><a name="includes">Include files</a></h2>
+ <h2><a id="includes">Include files</a></h2>
<p>
There are now quite a large number of include files, both libvirt
@@ -1251,7 +1251,7 @@
</p>
- <h2><a name="printf">Printf-style
functions</a></h2>
+ <h2><a id="printf">Printf-style functions</a></h2>
<p>
Whenever you add a new printf-style function, i.e., one with a format
@@ -1280,7 +1280,7 @@
does for snprintf.
</p>
- <h2><a name="goto">Use of goto</a></h2>
+ <h2><a id="goto">Use of goto</a></h2>
<p>
The use of goto is not forbidden, and goto is widely used
@@ -1363,7 +1363,7 @@ int foo()
- <h2><a name="committers">Libvirt committer
guidelines</a></h2>
+ <h2><a id="committers">Libvirt committer
guidelines</a></h2>
<p>
The AUTHORS files indicates the list of people with commit access right
diff --git a/docs/hooks.html.in b/docs/hooks.html.in
index 11073cb78..7a04ac198 100644
--- a/docs/hooks.html.in
+++ b/docs/hooks.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="intro">Custom event scripts</a></h2>
+ <h2><a id="intro">Custom event scripts</a></h2>
<p>Beginning with libvirt 0.8.0, specific events on a host system will
trigger custom scripts.</p>
<p>These custom <b>hook</b> scripts are executed when any of the
following
@@ -26,7 +26,7 @@
(<span class="since">since
1.2.2</span>)<br/><br/></li>
</ul>
- <h2><a name="location">Script location</a></h2>
+ <h2><a id="location">Script location</a></h2>
<p>The libvirt hook scripts are located in the directory
<code>$SYSCONFDIR/libvirt/hooks/</code>.</p>
<ul>
@@ -42,7 +42,7 @@
them executable.</p>
<br/>
- <h2><a name="names">Script names</a></h2>
+ <h2><a id="names">Script names</a></h2>
<p>At present, there are five hook scripts that can be called:</p>
<ul>
<li><code>/etc/libvirt/hooks/daemon</code><br/><br/>
@@ -61,7 +61,7 @@
</ul>
<br/>
- <h2><a name="structure">Script structure</a></h2>
+ <h2><a id="structure">Script structure</a></h2>
<p>The hook scripts are executed using standard Linux process creation
functions. Therefore, they must begin with the declaration of the
command interpreter to use.</p>
@@ -73,7 +73,7 @@
binary, so you are welcome to use your favourite languages.</p>
<br/>
- <h2><a name="arguments">Script arguments</a></h2>
+ <h2><a id="arguments">Script arguments</a></h2>
<p>The hook scripts are called with specific command line arguments,
depending upon the script, and the operation being performed.</p>
<p>The guest hook scripts, qemu and lxc, are also given the
<b>full</b>
@@ -128,10 +128,10 @@
none.</li>
</ol>
- <h4><a
name="arguments_specifics">Specifics</a></h4>
+ <h4><a id="arguments_specifics">Specifics</a></h4>
<p>This translates to the following specifics for each hook script:</p>
- <h5><a
name="daemon">/etc/libvirt/hooks/daemon</a></h5>
+ <h5><a
id="daemon">/etc/libvirt/hooks/daemon</a></h5>
<ul>
<li>When the libvirt daemon is started, this script is called as:<br/>
<pre>/etc/libvirt/hooks/daemon - start - start</pre></li>
@@ -146,7 +146,7 @@
with the "start" operation. There is no specific operation to indicate
a "restart" is occurring.</p>
- <h5><a
name="qemu">/etc/libvirt/hooks/qemu</a></h5>
+ <h5><a id="qemu">/etc/libvirt/hooks/qemu</a></h5>
<ul>
<li>Before a QEMU guest is started, the qemu hook script is
called in three locations; if any location fails, the guest
@@ -206,7 +206,7 @@
</li>
</ul>
- <h5><a name="lxc">/etc/libvirt/hooks/lxc</a></h5>
+ <h5><a id="lxc">/etc/libvirt/hooks/lxc</a></h5>
<ul>
<li>Before a LXC guest is started, the lxc hook script is
called in three locations; if any location fails, the guest
@@ -240,7 +240,7 @@
</li>
</ul>
- <h5><a
name="libxl">/etc/libvirt/hooks/libxl</a></h5>
+ <h5><a
id="libxl">/etc/libvirt/hooks/libxl</a></h5>
<ul>
<li>Before a Xen guest is started using libxl driver, the libxl hook
script is called in three locations; if any location fails, the guest
@@ -284,7 +284,7 @@
</li>
</ul>
- <h5><a
name="network">/etc/libvirt/hooks/network</a></h5>
+ <h5><a
id="network">/etc/libvirt/hooks/network</a></h5>
<ul>
<li><span class="since">Since 1.2.2</span>, before a
network is started,
this script is called as:<br/>
@@ -310,7 +310,7 @@
<br/>
- <h2><a name="execution">Script execution</a></h2>
+ <h2><a id="execution">Script execution</a></h2>
<ul>
<li>The "start" operation for the guest and network hook scripts,
executes <b>prior</b> to the object (guest or network) being
created.
@@ -335,7 +335,7 @@
</ul>
<br/>
- <h2><a name="qemu_migration">QEMU guest
migration</a></h2>
+ <h2><a id="qemu_migration">QEMU guest
migration</a></h2>
<p>Migration of a QEMU guest involves running hook scripts on both the
source and destination hosts:</p>
<ol>
@@ -357,14 +357,14 @@
</ol>
<br/>
- <h2><a name="recursive">Calling libvirt functions from within a
hook script</a></h2>
+ <h2><a id="recursive">Calling libvirt functions from within a
hook script</a></h2>
<p><b>DO NOT DO THIS!</b></p>
<p>A hook script must not call back into libvirt, as the libvirt daemon
is already waiting for the script to exit.</p>
<p>A deadlock is likely to occur.</p>
<br/>
- <h2><a name="return_codes">Return codes and
logging</a></h2>
+ <h2><a id="return_codes">Return codes and
logging</a></h2>
<p>If a hook script returns with an exit code of 0, the libvirt daemon
regards this as successful and performs no logging of it.</p>
<p>However, if a hook script returns with a non zero exit code, the libvirt
diff --git a/docs/internals/command.html.in b/docs/internals/command.html.in
index 2d8b09308..e21b12e53 100644
--- a/docs/internals/command.html.in
+++ b/docs/internals/command.html.in
@@ -12,7 +12,7 @@
All code is required to use these APIs
</p>
- <h2><a name="posix">Problems with standard POSIX
APIs</a></h2>
+ <h2><a id="posix">Problems with standard POSIX
APIs</a></h2>
<p>
The POSIX specification includes a number of APIs for
@@ -62,7 +62,7 @@
error prone, particularly wrt memory leak / OOM handling.
</p>
- <h2><a name="api">The libvirt command execution
API</a></h2>
+ <h2><a id="api">The libvirt command execution
API</a></h2>
<p>
There is now a high level API that provides a safe and
@@ -72,7 +72,7 @@
header which can be imported using <code>#include
"vircommand.h"</code>
</p>
- <h3><a name="initial">Defining commands in
libvirt</a></h3>
+ <h3><a id="initial">Defining commands in
libvirt</a></h3>
<p>
The first step is to declare what command is to be
@@ -92,7 +92,7 @@ virCommandPtr cmd = virCommandNew("/usr/bin/dnsmasq");
reported at a later time.
</p>
- <h3><a name="args">Adding arguments to the
command</a></h3>
+ <h3><a id="args">Adding arguments to the
command</a></h3>
<p>
There are a number of APIs for adding arguments to a
@@ -150,7 +150,7 @@ virCommandPtr cmd2 =
virCommandNewArgList("/usr/bin/dnsmasq",
"--domain", "localdomain",
NULL);
</pre>
- <h3><a name="env">Setting up the
environment</a></h3>
+ <h3><a id="env">Setting up the
environment</a></h3>
<p>
By default a command will inherit all environment variables
@@ -199,7 +199,7 @@ virCommandAddEnvPair(cmd, "TERM", "xterm");
virCommandAddEnvString(cmd, "TERM=xterm");
</pre>
- <h3><a name="misc">Miscellaneous other
options</a></h3>
+ <h3><a id="misc">Miscellaneous other
options</a></h3>
<p>
Normally the spawned command will retain the current
@@ -229,7 +229,7 @@ virCommandSetPidFile(cmd, "/var/run/dnsmasq.pid");
the intermediate process exits.
</p>
- <h3><a name="privs">Reducing command
privileges</a></h3>
+ <h3><a id="privs">Reducing command
privileges</a></h3>
<p>
Normally a command will inherit all privileges of
@@ -243,7 +243,7 @@ virCommandSetPidFile(cmd, "/var/run/dnsmasq.pid");
virCommandClearCaps(cmd);
</pre>
- <h3><a name="fds">Managing file handles</a></h3>
+ <h3><a id="fds">Managing file handles</a></h3>
<p>
To prevent unintended resource leaks to child processes, the
@@ -329,7 +329,7 @@ virCommandSetErrorFD(cmd, &errfd);
virCommandNonblockingFDs(cmd);
</pre>
- <h3><a name="buffers">Feeding & capturing strings
to/from the child</a></h3>
+ <h3><a id="buffers">Feeding & capturing strings to/from
the child</a></h3>
<p>
Often dealing with file handles for stdin/out/err is
@@ -382,7 +382,7 @@ virCommandSetErrorBuffer(cmd, &errors);
case the child process interleaves output into a single string.
</p>
- <h3><a name="directory">Setting working
directory</a></h3>
+ <h3><a id="directory">Setting working
directory</a></h3>
<p>
Daemonized commands are always run with "/" as the current
@@ -395,7 +395,7 @@ virCommandSetErrorBuffer(cmd, &errors);
virCommandSetWorkingDirectory(cmd, LOCALSTATEDIR);
</pre>
- <h3><a name="hooks">Any additional hooks</a></h3>
+ <h3><a id="hooks">Any additional hooks</a></h3>
<p>
If anything else is needed, it is possible to request a hook
@@ -409,7 +409,7 @@ virCommandSetWorkingDirectory(cmd, LOCALSTATEDIR);
virCommandSetPreExecHook(cmd, hook, opaque);
</pre>
- <h3><a name="logging">Logging commands</a></h3>
+ <h3><a id="logging">Logging commands</a></h3>
<p>
Sometimes, it is desirable to log what command will be run, or
@@ -434,7 +434,7 @@ if (virCommandRun(cmd, NULL) < 0)
return -1;
</pre>
- <h3><a name="sync">Running commands
synchronously</a></h3>
+ <h3><a id="sync">Running commands
synchronously</a></h3>
<p>
For most commands, the desired behaviour is to spawn
@@ -480,7 +480,7 @@ if (WIFEXITED(status) && WEXITSTATUS(status) == 1) {
}
</pre>
- <h3><a name="async">Running commands
asynchronously</a></h3>
+ <h3><a id="async">Running commands
asynchronously</a></h3>
<p>
In certain complex scenarios, particularly special
@@ -530,7 +530,7 @@ if (WEXITSTATUS(status)...) {
virCommandAbort to reap the process.
</p>
- <h3><a name="release">Releasing resources</a></h3>
+ <h3><a id="release">Releasing resources</a></h3>
<p>
Once the command has been executed, or if execution
@@ -550,7 +550,7 @@ virCommandFree(cmd);
it will be forcibly killed and cleaned up (via waitpid).
</p>
- <h2><a name="example">Complete examples</a></h2>
+ <h2><a id="example">Complete examples</a></h2>
<p>
This shows a complete example usage of the APIs roughly
diff --git a/docs/internals/eventloop.html.in b/docs/internals/eventloop.html.in
index a01e104e8..fe7bf3aaf 100644
--- a/docs/internals/eventloop.html.in
+++ b/docs/internals/eventloop.html.in
@@ -11,7 +11,7 @@
libvirt. Both server and client.
</p>
- <h2><a name="event_loop">Event driven
programming</a></h2>
+ <h2><a id="event_loop">Event driven
programming</a></h2>
<p>Traditionally, a program simply ran once, then terminated.
This type of program was very common in the early days of
@@ -38,7 +38,7 @@
file descriptor which is then watched for incoming events,
e.g. messages. </p>
- <h2><a name="api">The event loop API</a></h2>
+ <h2><a id="api">The event loop API</a></h2>
<p>To work with event loop from our code we have plenty of
APIs.</p>
@@ -62,7 +62,7 @@
<p>For more information on these APIs continue reading <a
href="../html/libvirt-libvirt-event.html">here</a>.</p>
- <h2><a name="worker_pool">Worker pool</a></h2>
+ <h2><a id="worker_pool">Worker pool</a></h2>
<p>Looking back at the image above we can see one big
limitation. While processing a message event loop is blocked
diff --git a/docs/internals/locking.html.in b/docs/internals/locking.html.in
index 09cc2ba4a..4222c44d3 100644
--- a/docs/internals/locking.html.in
+++ b/docs/internals/locking.html.in
@@ -12,7 +12,7 @@
access to content.
</p>
- <h2><a name="goals">Goals</a></h2>
+ <h2><a id="goals">Goals</a></h2>
<p>
The high level goal is to prevent the same disk image being
@@ -36,7 +36,7 @@
</li>
</ol>
- <h2><a name="requirement">Requirements</a></h2>
+ <h2><a id="requirement">Requirements</a></h2>
<p>
The high level goal leads to a set of requirements
@@ -67,7 +67,7 @@
</li>
</ol>
- <h2><a name="design">Design</a></h2>
+ <h2><a id="design">Design</a></h2>
<p>
Within a lock manager the following series of operations
@@ -102,7 +102,7 @@
</li>
</ul>
- <h2><a name="impl">Plugin Implementations</a></h2>
+ <h2><a id="impl">Plugin Implementations</a></h2>
<p>
Lock manager implementations are provided as LGPLv2+
@@ -132,7 +132,7 @@
in the previously mentioned header file
</p>
- <h2><a name="qemuIntegrate">QEMU Driver
integration</a></h2>
+ <h2><a id="qemuIntegrate">QEMU Driver
integration</a></h2>
<p>
With the QEMU driver, the lock plugin will be set
@@ -149,7 +149,7 @@ lockManager="sanlock"
for backwards compatibility
</p>
- <h2><a name="usagePatterns">Lock usage
patterns</a></h2>
+ <h2><a id="usagePatterns">Lock usage
patterns</a></h2>
<p>
The following pseudo code illustrates the common
@@ -157,7 +157,7 @@ lockManager="sanlock"
manager plugin callbacks.
</p>
- <h3><a name="usageLockAcquire">Lock
acquisition</a></h3>
+ <h3><a id="usageLockAcquire">Lock
acquisition</a></h3>
<p>
Initial lock acquisition will be performed from the
@@ -205,7 +205,7 @@ if (virLockManagerAcquire(lock, NULL, 0) < 0);
...abort...
</pre>
- <h3><a name="usageLockAttach">Lock
release</a></h3>
+ <h3><a id="usageLockAttach">Lock release</a></h3>
<p>
The locks are all implicitly released when the process
diff --git a/docs/internals/oomtesting.html.in b/docs/internals/oomtesting.html.in
index c5edacff6..aca8fde13 100644
--- a/docs/internals/oomtesting.html.in
+++ b/docs/internals/oomtesting.html.in
@@ -26,7 +26,7 @@ $ ./configure --enable-test-oom
</pre>
- <h2><a name="basicoom">Basic OOM testing
support</a></h2>
+ <h2><a id="basicoom">Basic OOM testing
support</a></h2>
<p>
The first step in validating OOM usage is to run a test suite
@@ -64,7 +64,7 @@ $ VIR_TEST_OOM=1 ./qemuxml2argvtest
of memory allocations from that test case.
</p>
- <h3><a name="valgrind">Tracking failures with
valgrind</a></h3>
+ <h3><a id="valgrind">Tracking failures with
valgrind</a></h3>
<p>
The test suite should obviously *not* crash during OOM testing.
@@ -88,7 +88,7 @@ $ VIR_TEST_OOM=1 VIR_TEST_RANGE=5 ../run valgrind ./qemuxml2argvtest
access.
</p>
- <h3><a name="stacktraces">Tracking failures with stack
traces</a></h3>
+ <h3><a id="stacktraces">Tracking failures with stack
traces</a></h3>
<p>
With some really difficult bugs valgrind is not sufficient to
@@ -191,7 +191,7 @@ _start
??:?
</pre>
- <h3><a name="noncrash">Non-crash related
problems</a></h3>
+ <h3><a id="noncrash">Non-crash related
problems</a></h3>
<p>
Not all memory allocation bugs result in code crashing. Sometimes
diff --git a/docs/internals/rpc.html.in b/docs/internals/rpc.html.in
index 9107b97a2..98f8be07b 100644
--- a/docs/internals/rpc.html.in
+++ b/docs/internals/rpc.html.in
@@ -17,7 +17,7 @@
</p>
- <h2><a name="protocol">RPC protocol</a></h2>
+ <h2><a id="protocol">RPC protocol</a></h2>
<p>
libvirt uses a simple, variable length, packet based RPC protocol.
@@ -193,14 +193,14 @@
definition for the program+version in question
</p>
- <h3><a name="wireexamples">Wire examples</a></h3>
+ <h3><a id="wireexamples">Wire examples</a></h3>
<p>
The following diagrams illustrate some example packet exchanges
between a client and server
</p>
- <h4><a name="wireexamplescall">Method
call</a></h4>
+ <h4><a id="wireexamplescall">Method call</a></h4>
<p>
A single method call and successful
@@ -219,7 +219,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
+--+-----------------------+--------+
</pre>
- <h4><a name="wireexamplescallerr">Method call with
error</a></h4>
+ <h4><a id="wireexamplescallerr">Method call with
error</a></h4>
<p>
An unsuccessful method call will instead return an error object
@@ -235,7 +235,7 @@ C <-- |48| 8 | 1 | 3 | 2 | 1 | 0 | .o.oOo.o.oOo.o.oOo.o.oOo |
<-- S (er
+--+-----------------------+--------------------------+
</pre>
- <h4><a name="wireexamplescallup">Method call with upload
stream</a></h4>
+ <h4><a id="wireexamplescallup">Method call with upload
stream</a></h4>
<p>
A method call which also involves uploading some data over
@@ -272,7 +272,7 @@ C <-- |24| 8 | 1 | 3 | 3 | 1 | 0 | <-- S (stream
finish)
+--+-----------------------+
</pre>
- <h4><a name="wireexamplescallbi">Method call bidirectional
stream</a></h4>
+ <h4><a id="wireexamplescallbi">Method call bidirectional
stream</a></h4>
<p>
A method call which also involves a bi-directional stream will
@@ -328,7 +328,7 @@ C <-- |24| 8 | 1 | 3 | 3 | 1 | 0 | <-- S (stream
finish)
</pre>
- <h4><a name="wireexamplescallmany">Method calls
overlapping</a></h4>
+ <h4><a id="wireexamplescallmany">Method calls
overlapping</a></h4>
<pre>
+--+-----------------------+-----------+
C --> |38| 8 | 1 | 3 | 0 | 1 | 0 | .o.oOo.o. | --> S (call 1)
@@ -356,7 +356,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 4 | 0 | .o.oOo | <-- S
(reply 4)
+--+-----------------------+--------+
</pre>
- <h4><a name="wireexamplescallfd">Method call with passed
FD</a></h4>
+ <h4><a id="wireexamplescallfd">Method call with passed
FD</a></h4>
<p>
A single method call with 2 passed file descriptors and successful
@@ -378,14 +378,14 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
</pre>
- <h2><a name="security">RPC security</a></h2>
+ <h2><a id="security">RPC security</a></h2>
<p>
There are various things to consider to ensure an implementation
of the RPC protocol can be satisfactorily secured
</p>
- <h3><a
name="securitytls">Authentication/encryption</a></h3>
+ <h3><a
id="securitytls">Authentication/encryption</a></h3>
<p>
The basic RPC protocol does not define or require any specific
@@ -399,7 +399,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
stream can of course be tunnelled over transports such as SSH.
</p>
- <h3><a name="securitylimits">Data limits</a></h3>
+ <h3><a id="securitylimits">Data limits</a></h3>
<p>
Although the protocol itself defines many arbitrary sized data values in the
@@ -411,7 +411,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
breaking compatibility of the RPC data on the wire.
</p>
- <h3><a name="securityvalidate">Data
validation</a></h3>
+ <h3><a id="securityvalidate">Data
validation</a></h3>
<p>
It is important that all data be fully validated before performing
@@ -427,7 +427,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
execution API (e.g. corresponding libvirt public API).
</p>
- <h2><a name="internals">RPC internal APIs</a></h2>
+ <h2><a id="internals">RPC internal APIs</a></h2>
<p>
The generic internal RPC library code lives in the
<code>src/rpc/</code>
@@ -436,7 +436,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
purposes are:
</p>
- <h3><a name="apioverview">Overview of RPC
objects</a></h3>
+ <h3><a id="apioverview">Overview of RPC
objects</a></h3>
<p>
The following is a high level overview of the role of each
@@ -568,7 +568,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
</dd>
</dl>
- <h3><a name="apiclientdispatch">Client RPC
dispatch</a></h3>
+ <h3><a id="apiclientdispatch">Client RPC
dispatch</a></h3>
<p>
The client RPC code must allow for multiple overlapping RPC method
@@ -601,7 +601,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
grabs the buck, and re-enabled when the buck is released.
</p>
- <h4><a name="apiclientdispatchex1">Example with buck
passing</a></h4>
+ <h4><a id="apiclientdispatchex1">Example with buck
passing</a></h4>
<p>
In the first example, a second thread issues an API call
@@ -649,7 +649,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
Return API2()
</pre>
- <h4><a name="apiclientdispatchex2">Example without buck
passing</a></h4>
+ <h4><a id="apiclientdispatchex2">Example without buck
passing</a></h4>
<p>
In this second example, a second thread issues an API call
@@ -699,7 +699,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
Return API1()
</pre>
- <h4><a name="apiclientdispatchex3">Example with async
events</a></h4>
+ <h4><a id="apiclientdispatchex3">Example with async
events</a></h4>
<p>
In this example, only one thread is present and it has to
@@ -739,7 +739,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
...
</pre>
- <h3><a name="apiserverdispatch">Server RPC
dispatch</a></h3>
+ <h3><a id="apiserverdispatch">Server RPC
dispatch</a></h3>
<p>
The RPC server code must support receipt of incoming RPC requests from
@@ -827,7 +827,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
queue.
</p>
- <h4><a name="apiserverdispatchex1">Example with overlapping
methods</a></h4>
+ <h4><a id="apiserverdispatchex1">Example with overlapping
methods</a></h4>
<p>
This example illustrates processing of two incoming methods with
@@ -874,7 +874,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S
(reply)
...
</pre>
- <h4><a name="apiserverdispatchex2">Example with stream
data</a></h4>
+ <h4><a id="apiserverdispatchex2">Example with stream
data</a></h4>
<p>
This example illustrates processing of stream data
diff --git a/docs/locking-lockd.html.in b/docs/locking-lockd.html.in
index fe007b107..42fcf0e68 100644
--- a/docs/locking-lockd.html.in
+++ b/docs/locking-lockd.html.in
@@ -12,7 +12,7 @@
plugin for virtual machine disk mutual exclusion.
</p>
- <h2><a name="background">virtlockd
background</a></h2>
+ <h2><a id="background">virtlockd
background</a></h2>
<p>
The virtlockd daemon is a single purpose binary which
@@ -26,7 +26,7 @@
commonly used filesystems.
</p>
- <h2><a name="sanlock">virtlockd daemon
setup</a></h2>
+ <h2><a id="sanlock">virtlockd daemon
setup</a></h2>
<p>
In most OS, the virtlockd daemon itself will not require
@@ -53,7 +53,7 @@
setup at all.
</p>
- <h2><a name="lockdplugin">libvirt lockd plugin
configuration</a></h2>
+ <h2><a id="lockdplugin">libvirt lockd plugin
configuration</a></h2>
<p>
Once the virtlockd daemon is running, or setup to autostart,
@@ -127,7 +127,7 @@ $ su - root
the same locking mechanism
</p>
- <h2><a name="qemuconfig">QEMU/KVM driver
configuration</a></h2>
+ <h2><a id="qemuconfig">QEMU/KVM driver
configuration</a></h2>
<p>
The QEMU driver is capable of using the virtlockd plugin
diff --git a/docs/locking-sanlock.html.in b/docs/locking-sanlock.html.in
index 12fc3d724..08182065d 100644
--- a/docs/locking-sanlock.html.in
+++ b/docs/locking-sanlock.html.in
@@ -13,7 +13,7 @@
plugin for virtual machine disk mutual exclusion.
</p>
- <h2><a name="sanlock">Sanlock daemon
setup</a></h2>
+ <h2><a id="sanlock">Sanlock daemon setup</a></h2>
<p>
On many operating systems, the <strong>sanlock</strong> plugin
@@ -68,7 +68,7 @@ SANLOCKOPTS="-w 0"
steps as necessary.
</p>
- <h2><a name="sanlockplugin">libvirt sanlock plugin
configuration</a></h2>
+ <h2><a id="sanlockplugin">libvirt sanlock plugin
configuration</a></h2>
<p>
Once the sanlock daemon is running, the next step is to
@@ -91,7 +91,7 @@ $ su - root
unique value for the host.
</p>
- <h2><a name="sanlockstorage">libvirt sanlock storage
configuration</a></h2>
+ <h2><a id="sanlockstorage">libvirt sanlock storage
configuration</a></h2>
<p>
The sanlock plugin needs to create leases in a directory
@@ -152,7 +152,7 @@ augtool -s set /files/etc/libvirt/qemu-sanlock.conf/group sanlock
it should be sufficient to run the cleanup once a week.
</p>
- <h2><a name="qemuconfig">QEMU/KVM driver
configuration</a></h2>
+ <h2><a id="qemuconfig">QEMU/KVM driver
configuration</a></h2>
<p>
The QEMU/KVM driver is fully integrated with the lock
@@ -219,7 +219,7 @@ __LIBVIRT__DISKS__
</pool>
</pre>
- <h2><a name="domainconfig">Domain
configuration</a></h2>
+ <h2><a id="domainconfig">Domain
configuration</a></h2>
<p>
In case sanlock loses access to disk locks for some reason, it will
diff --git a/docs/locking.html.in b/docs/locking.html.in
index aca18113d..f0e0a3868 100644
--- a/docs/locking.html.in
+++ b/docs/locking.html.in
@@ -15,7 +15,7 @@
aware filesystem.
</p>
- <h2><a name="plugins">Lock manager
plugins</a></h2>
+ <h2><a id="plugins">Lock manager plugins</a></h2>
<p>
The lock manager framework has a pluggable architecture,
diff --git a/docs/logging.html.in b/docs/logging.html.in
index bcec17940..534afa1cd 100644
--- a/docs/logging.html.in
+++ b/docs/logging.html.in
@@ -12,7 +12,7 @@
<ul id="toc"/>
<h2>
- <a name="log_library">Logging in the library</a>
+ <a id="log_library">Logging in the library</a>
</h2>
<p>The logging functionalities in libvirt are based on 3 key concepts,
similar to the one present in other generic logging facilities like
@@ -40,7 +40,7 @@
</ul>
<h2>
- <a name="log_config">Configuring logging in the library</a>
+ <a id="log_config">Configuring logging in the library</a>
</h2>
<p>The library configuration of logging is through 3 environment variables
allowing to control the logging behaviour:</p>
@@ -61,7 +61,7 @@
have an error in a filter or output string, some of the settings may be
applied up to the point at which libvirt encountered the error.</p>
<h2>
- <a name="log_daemon">Logging in the daemon</a>
+ <a id="log_daemon">Logging in the daemon</a>
</h2>
<p>Similarly the daemon logging behaviour can be tuned using 3 config
variables, stored in the configuration file:</p>
@@ -96,7 +96,7 @@
for debugging purposes by sending the daemon a USR2 signal:</p>
<pre>killall -USR2 libvirtd</pre>
<h2>
- <a name="log_syntax">Syntax for filters and output
values</a>
+ <a id="log_syntax">Syntax for filters and output values</a>
</h2>
<p>The syntax for filters and outputs is the same for both types of
variables.</p>
@@ -149,7 +149,7 @@ x:+name (log message + stack trace)</pre>
but also log all debug and information included in the
file <code>/tmp/libvirt.log</code></p>
- <h2><a name="journald">Systemd journal
fields</a></h2>
+ <h2><a id="journald">Systemd journal
fields</a></h2>
<p>
When logging to the systemd journal, the following fields
@@ -176,7 +176,7 @@ x:+name (log message + stack trace)</pre>
<dd>The libvirt error code (values from virErrorCode enum), if
LIBVIRT_SOURCE="error"</dd>
</dl>
- <h3><a name="journaldids">Well known message ID
values</a></h3>
+ <h3><a id="journaldids">Well known message ID
values</a></h3>
<p>
Certain areas of the code will emit log records tagged with well known
@@ -221,7 +221,7 @@ $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361
--output=json
</pre>
<h2>
- <a name="log_examples">Examples</a>
+ <a id="log_examples">Examples</a>
</h2>
<p>For example setting up the following:</p>
<pre>export LIBVIRT_DEBUG=1
diff --git a/docs/migration.html.in b/docs/migration.html.in
index a57f27918..d82fb54b4 100644
--- a/docs/migration.html.in
+++ b/docs/migration.html.in
@@ -13,7 +13,7 @@
libvirt implements several options for migration.
</p>
- <h2><a name="transport">Network data
transports</a></h2>
+ <h2><a id="transport">Network data
transports</a></h2>
<p>
There are two options for the data transport used during migration, either
@@ -21,7 +21,7 @@
over a libvirtd connection.
</p>
- <h3><a name="transportnative">Hypervisor native
transport</a></h3>
+ <h3><a id="transportnative">Hypervisor native
transport</a></h3>
<p>
<em>Native</em> data transports may or may not support encryption,
depending
on the hypervisor in question, but will typically have the lowest computational
costs
@@ -35,7 +35,7 @@
<img class="diagram" src="migration-native.png"
alt="Migration native path"/>
</p>
- <h3><a name="transporttunnel">libvirt tunnelled
transport</a></h3>
+ <h3><a id="transporttunnel">libvirt tunnelled
transport</a></h3>
<p>
<em>Tunnelled</em> data transports will always be capable of strong
encryption
since they are able to leverage the capabilities built in to the libvirt RPC
protocol.
@@ -53,7 +53,7 @@
<img class="diagram" src="migration-tunnel.png"
alt="Migration tunnel path"/>
</p>
- <h2><a name="flow">Communication control
paths/flows</a></h2>
+ <h2><a id="flow">Communication control
paths/flows</a></h2>
<p>
Migration of virtual machines requires close co-ordination of the two
@@ -61,7 +61,7 @@
which may be on the source, the destination, or a third host.
</p>
- <h3><a name="flowmanageddirect">Managed direct
migration</a></h3>
+ <h3><a id="flowmanageddirect">Managed direct
migration</a></h3>
<p>
With <em>managed direct</em> migration, the libvirt client process
@@ -81,7 +81,7 @@
</p>
- <h3><a name="flowpeer2peer">Managed peer to peer
migration</a></h3>
+ <h3><a id="flowpeer2peer">Managed peer to peer
migration</a></h3>
<p>
With <em>peer to peer</em> migration, the libvirt client process only
@@ -103,7 +103,7 @@
</p>
- <h3><a name="flowunmanageddirect">Unmanaged direct
migration</a></h3>
+ <h3><a id="flowunmanageddirect">Unmanaged direct
migration</a></h3>
<p>
With <em>unmanaged direct</em> migration, neither the libvirt client
@@ -119,7 +119,7 @@
</p>
- <h2><a name="security">Data security</a></h2>
+ <h2><a id="security">Data security</a></h2>
<p>
Since the migration data stream includes a complete copy of the guest
@@ -138,7 +138,7 @@
facility should be used.
</p>
- <h2><a name="offline">Offline migration</a></h2>
+ <h2><a id="offline">Offline migration</a></h2>
<p>
Offline migration transfers inactive the definition of a domain
@@ -153,7 +153,7 @@
offline migration.
</p>
- <h2><a name="uris">Migration URIs</a></h2>
+ <h2><a id="uris">Migration URIs</a></h2>
<p>
Initiating a guest migration requires the client application to
@@ -203,7 +203,7 @@
to comply with local firewall policies.</li>
</ol>
- <h2><a name="config">Configuration file
handling</a></h2>
+ <h2><a id="config">Configuration file
handling</a></h2>
<p>
There are two types of virtual machine known to libvirt. A
<em>transient</em>
@@ -446,10 +446,10 @@
</tbody>
</table>
- <h2><a name="scenarios">Migration
scenarios</a></h2>
+ <h2><a id="scenarios">Migration scenarios</a></h2>
- <h3><a name="scenarionativedirect">Native migration, client to
two libvirtd servers</a></h3>
+ <h3><a id="scenarionativedirect">Native migration, client to
two libvirtd servers</a></h3>
<p>
At an API level this requires use of virDomainMigrate, without the
@@ -479,7 +479,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
Supported by Xen, QEMU, VMware and VirtualBox drivers
</p>
- <h3><a name="scenarionativepeer2peer">Native migration, client
to and peer2peer between, two libvirtd servers</a></h3>
+ <h3><a id="scenarionativepeer2peer">Native migration, client to
and peer2peer between, two libvirtd servers</a></h3>
<p>
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set,
@@ -503,7 +503,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
Supported by QEMU driver
</p>
- <h3><a name="scenariotunnelpeer2peer1">Tunnelled migration,
client and peer2peer between two libvirtd servers</a></h3>
+ <h3><a id="scenariotunnelpeer2peer1">Tunnelled migration,
client and peer2peer between two libvirtd servers</a></h3>
<p>
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED
@@ -526,7 +526,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
Supported by QEMU driver
</p>
- <h3><a name="nativedirectunmanaged">Native migration, client to
one libvirtd server</a></h3>
+ <h3><a id="nativedirectunmanaged">Native migration, client to
one libvirtd server</a></h3>
<p>
virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set,
@@ -550,7 +550,7 @@ virsh migrate --direct web1 xenmigr://desthost/
Supported by Xen driver
</p>
- <h3><a name="nativepeer2peer">Native migration, peer2peer
between two libvirtd servers</a></h3>
+ <h3><a id="nativepeer2peer">Native migration, peer2peer between
two libvirtd servers</a></h3>
<p>
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set,
@@ -587,7 +587,7 @@ virsh migrate --p2p web1 qemu+ssh://desthost/system
qemu+ssh://10.0.0.1/system
Supported by the QEMU driver
</p>
- <h3><a name="scenariotunnelpeer2peer2">Tunnelled migration,
peer2peer between two libvirtd servers</a></h3>
+ <h3><a id="scenariotunnelpeer2peer2">Tunnelled migration,
peer2peer between two libvirtd servers</a></h3>
<p>
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER &
VIR_MIGRATE_TUNNELLED
diff --git a/docs/nss.html.in b/docs/nss.html.in
index 2a5a46cd1..369c9ff61 100644
--- a/docs/nss.html.in
+++ b/docs/nss.html.in
@@ -25,7 +25,7 @@
users. This is where NSS module comes handy.
</p>
- <h2><a name="Installation">Installation</a></h2>
+ <h2><a id="Installation">Installation</a></h2>
<p>
Installing the module is really easy:
@@ -35,7 +35,7 @@
# yum install libvirt-nss
</pre>
- <h2><a name="Configuration">Configuration</a></h2>
+ <h2><a id="Configuration">Configuration</a></h2>
<p>
Enabling the module is really easy. Just add <b>libvirt</b> into
@@ -62,7 +62,7 @@ hosts: files libvirt dns
lookup given host name.
</p>
- <h2><a name="Sources">Sources of
information</a></h2>
+ <h2><a id="Sources">Sources of
information</a></h2>
<p>
As of <code>v3.0.0</code> release, libvirt offers two NSS modules
@@ -104,7 +104,7 @@ hosts: files libvirt libvirt_guest dns
resolved).
</p>
- <h2><a name="Internals">How does it work?</a></h2>
+ <h2><a id="Internals">How does it work?</a></h2>
<p>
Whenever an Unix process wants to do a host name translation
@@ -139,7 +139,7 @@ hosts: files libvirt libvirt_guest dns
should carefully chose the lookup order.
</p>
- <h2><a name="Limitations">Limitations</a></h2>
+ <h2><a id="Limitations">Limitations</a></h2>
<ol>
<li>The <code>libvirt</code> NSS module matches only hostnames
provided by guest.
diff --git a/docs/page.xsl b/docs/page.xsl
index 1d662c670..57f85e618 100644
--- a/docs/page.xsl
+++ b/docs/page.xsl
@@ -27,30 +27,30 @@
<xsl:for-each select="/html:html/html:body/html:h2[count(html:a) =
1]">
<xsl:variable name="thish2" select="."/>
<li>
- <a href="#{html:a/@name}"><xsl:value-of
select="html:a/text()"/></a>
+ <a href="#{html:a/@id}"><xsl:value-of
select="html:a/text()"/></a>
<xsl:if
test="count(./following-sibling::html:h3[preceding-sibling::html:h2[1] = $thish2 and
count(html:a) = 1]) > 0">
<ul>
<xsl:for-each
select="./following-sibling::html:h3[preceding-sibling::html:h2[1] = $thish2 and
count(html:a) = 1]">
<xsl:variable name="thish3" select="."/>
<li>
- <a href="#{html:a/@name}"><xsl:value-of
select="html:a/text()"/></a>
+ <a href="#{html:a/@id}"><xsl:value-of
select="html:a/text()"/></a>
<xsl:if
test="count(./following-sibling::html:h4[preceding-sibling::html:h3[1] = $thish3 and
count(html:a) = 1]) > 0">
<ul>
<xsl:for-each
select="./following-sibling::html:h4[preceding-sibling::html:h3[1] = $thish3 and
count(html:a) = 1]">
<xsl:variable name="thish4"
select="."/>
<li>
- <a href="#{html:a/@name}"><xsl:value-of
select="html:a/text()"/></a>
+ <a href="#{html:a/@id}"><xsl:value-of
select="html:a/text()"/></a>
<xsl:if
test="count(./following-sibling::html:h5[preceding-sibling::html:h4[1] = $thish4 and
count(html:a) = 1]) > 0">
<ul>
<xsl:for-each
select="./following-sibling::html:h5[preceding-sibling::html:h4[1] = $thish4 and
count(html:a) = 1]">
<xsl:variable name="thish5"
select="."/>
<li>
- <a
href="#{html:a/@name}"><xsl:value-of
select="html:a/text()"/></a>
+ <a
href="#{html:a/@id}"><xsl:value-of
select="html:a/text()"/></a>
<xsl:if
test="count(./following-sibling::html:h6[preceding-sibling::html:h5[1] = $thish5 and
count(html:a) = 1]) > 0">
<ul>
<xsl:for-each
select="./following-sibling::html:h6[preceding-sibling::html:h5[1] = $thish5 and
count(html:a) = 1]">
<li>
- <a
href="#{html:a/@name}"><xsl:value-of
select="html:a/text()"/></a>
+ <a
href="#{html:a/@id}"><xsl:value-of
select="html:a/text()"/></a>
</li>
</xsl:for-each>
</ul>
@@ -155,8 +155,8 @@
<xsl:template match="html:h2 | html:h3 | html:h4 | html:h5 | html:h6"
mode="content">
<xsl:element name="{name()}">
<xsl:apply-templates mode="copy" />
- <xsl:if test="./html:a/@name">
- <a class="headerlink" href="#{html:a/@name}"
title="Permalink to this headline">¶</a>
+ <xsl:if test="./html:a/@id">
+ <a class="headerlink" href="#{html:a/@id}"
title="Permalink to this headline">¶</a>
</xsl:if>
</xsl:element>
</xsl:template>
diff --git a/docs/remote.html.in b/docs/remote.html.in
index 117ee3477..47e95400b 100644
--- a/docs/remote.html.in
+++ b/docs/remote.html.in
@@ -10,7 +10,7 @@ machines through authenticated and encrypted connections.
<ul id="toc"></ul>
<h2>
- <a name="Remote_basic_usage">Basic usage</a>
+ <a id="Remote_basic_usage">Basic usage</a>
</h2>
<p>
On the remote machine, <code>libvirtd</code> should be running in general.
@@ -50,7 +50,7 @@ relating to failures in the remote transport itself. </li>
much slower than, say, direct hypervisor calls. </li>
</ul>
<h2>
- <a name="Remote_transports">Transports</a>
+ <a id="Remote_transports">Transports</a>
</h2>
<p>
Remote libvirt supports a range of transports:
@@ -111,7 +111,7 @@ netcat is required on the remote side.</dd>
The default transport, if no other is specified, is <code>tls</code>.
</p>
<h2>
- <a name="Remote_URI_reference">Remote URIs</a>
+ <a id="Remote_URI_reference">Remote URIs</a>
</h2>
<p>
See also: <a href="uri.html">documentation on ordinary
("local") URIs</a>.
@@ -158,7 +158,7 @@ Connect to a remote host using a ssh connection with the libssh
driver
and use a different known_hosts file.</li>
</ul>
<h3>
- <a name="Remote_URI_parameters">Extra parameters</a>
+ <a id="Remote_URI_parameters">Extra parameters</a>
</h3>
<p>
Extra parameters can be added to remote URIs as part
@@ -364,10 +364,10 @@ Note that parameter values must be
</tr>
</table>
<h2>
- <a name="Remote_certificates">Generating TLS
certificates</a>
+ <a id="Remote_certificates">Generating TLS certificates</a>
</h2>
<h3>
- <a name="Remote_PKI">Public Key Infrastructure set up</a>
+ <a id="Remote_PKI">Public Key Infrastructure set up</a>
</h3>
<p>
If you are unsure how to create TLS certificates, skip to the
@@ -472,7 +472,7 @@ next section.
<li> For the root user, the global default locations will always be
used.</li>
</ul>
<h3>
- <a name="Remote_TLS_background">Background to TLS
certificates</a>
+ <a id="Remote_TLS_background">Background to TLS
certificates</a>
</h3>
<p>
Libvirt supports TLS certificates for verifying the identity
@@ -507,7 +507,7 @@ address. You may want to change this to make it less (or more)
permissive, depending on your needs.
</p>
<h3>
- <a name="Remote_TLS_CA">Setting up a Certificate Authority
(CA)</a>
+ <a id="Remote_TLS_CA">Setting up a Certificate Authority
(CA)</a>
</h3>
<p>
You will need the <a
href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-c...
@@ -578,7 +578,7 @@ key carefully as you will need it when you come to issue certificates
for your clients and servers.
</p>
<h3>
- <a name="Remote_TLS_server_certificates">Issuing server
certificates</a>
+ <a id="Remote_TLS_server_certificates">Issuing server
certificates</a>
</h3>
<p>
For each server (libvirtd) you need to issue a certificate
@@ -661,7 +661,7 @@ which can be installed on the server as
</li>
</ul>
<h3>
- <a name="Remote_TLS_client_certificates">Issuing client
certificates</a>
+ <a id="Remote_TLS_client_certificates">Issuing client
certificates</a>
</h3>
<p>
For each client (ie. any program linked with libvirt, such as
@@ -714,7 +714,7 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem
</li>
</ol>
<h3>
- <a name="Remote_TLS_troubleshooting">Troubleshooting TLS
certificate problems</a>
+ <a id="Remote_TLS_troubleshooting">Troubleshooting TLS certificate
problems</a>
</h3>
<dl>
<dt> failed to verify client's certificate </dt>
@@ -732,7 +732,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>
<h2>
- <a name="Remote_libvirtd_configuration">libvirtd configuration
file</a>
+ <a id="Remote_libvirtd_configuration">libvirtd configuration
file</a>
</h2>
<p>
Libvirtd (the remote daemon) is configured from a file called
@@ -900,7 +900,7 @@ Blank lines and comments beginning with <code>#</code> are
ignored.
</tr>
</table>
<h2>
- <a name="Remote_IPv6">IPv6 support</a>
+ <a id="Remote_IPv6">IPv6 support</a>
</h2>
<p>
The libvirtd service and libvirt remote client driver both use the
@@ -913,7 +913,7 @@ connection will be made, otherwise IPv4 will be used. In summary it
should just 'do the right thing(tm)'.
</p>
<h2>
- <a name="Remote_limitations">Limitations</a>
+ <a id="Remote_limitations">Limitations</a>
</h2>
<ul>
<li> Fine-grained authentication: libvirt in general,
diff --git a/docs/secureusage.html.in b/docs/secureusage.html.in
index af47a0f53..6a9490bac 100644
--- a/docs/secureusage.html.in
+++ b/docs/secureusage.html.in
@@ -14,9 +14,9 @@
</p>
- <h2><a name="diskimage">Disk image
handling</a></h2>
+ <h2><a id="diskimage">Disk image handling</a></h2>
- <h3><a name="diskimageformat">Disk image format
probing</a></h3>
+ <h3><a id="diskimageformat">Disk image format
probing</a></h3>
<p>
Historically there have been multiple flaws in QEMU and most
@@ -40,7 +40,7 @@
are accessible to / originate from an untrusted source.
</p>
- <h3><a name="diskimagebacking">Disk image backing
files</a></h3>
+ <h3><a id="diskimagebacking">Disk image backing
files</a></h3>
<p>
If a management application allows users to upload pre-created
@@ -59,7 +59,7 @@
file set. If a backing file is seen, reject the image.
</p>
- <h3><a name="diskimagesize">Disk image size
validation</a></h3>
+ <h3><a id="diskimagesize">Disk image size
validation</a></h3>
<p>
If an application allows users to upload pre-created disk
@@ -78,7 +78,7 @@
limit.
</p>
- <h3><a name="diskimageaccess">Disk image data
access</a></h3>
+ <h3><a id="diskimageaccess">Disk image data
access</a></h3>
<p>
If an untrusted disk image is ever mounted on the host OS by
@@ -104,7 +104,7 @@
tools and APIs for accessing disks
</p>
- <h2><a name="migration">Guest migration
network</a></h2>
+ <h2><a id="migration">Guest migration
network</a></h2>
<p>
Most hypervisors with support for guest migration between hosts
@@ -145,7 +145,7 @@
RPC protocol connections.</li>
</ul>
- <h2><a name="storage">Storage encryption</a></h2>
+ <h2><a id="storage">Storage encryption</a></h2>
<p>
Virtual disk images will typically contain confidential data
diff --git a/docs/securityprocess.html.in b/docs/securityprocess.html.in
index bdef1e9d8..d37276d15 100644
--- a/docs/securityprocess.html.in
+++ b/docs/securityprocess.html.in
@@ -15,7 +15,7 @@
potential security issues.
</p>
- <h2><a name="reporting">Reporting security
issues</a></h2>
+ <h2><a id="reporting">Reporting security
issues</a></h2>
<p>
In the event that a bug in libvirt is found which is
@@ -37,7 +37,7 @@
moderator and the reporter copied on any replies.
</p>
- <h2><a name="seclist">Security team</a></h2>
+ <h2><a id="seclist">Security team</a></h2>
<p>
The libvirt security team is made up of a subset of the libvirt
@@ -61,7 +61,7 @@
described below.
</p>
- <h2><a name="embargo">Publication embargo
policy</a></h2>
+ <h2><a id="embargo">Publication embargo
policy</a></h2>
<p>
The libvirt security team operates a policy of
@@ -84,7 +84,7 @@
</p>
- <h2><a name="cve">CVE allocation</a></h2>
+ <h2><a id="cve">CVE allocation</a></h2>
<p>
The libvirt security team will associate each security issue with
@@ -92,7 +92,7 @@
the vendor security engineers on the security team.
</p>
- <h2><a name="branches">Branch fixing
policy</a></h2>
+ <h2><a id="branches">Branch fixing policy</a></h2>
<p>
The libvirt community maintains one or more stable release branches
@@ -103,7 +103,7 @@
other release branches where applicable.
</p>
- <h2><a name="notification">Notification of
issues</a></h2>
+ <h2><a id="notification">Notification of
issues</a></h2>
<p>
When an embargo expires, security issues will be announced on both
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 89ebb7097..aad5751ef 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -85,7 +85,7 @@
</p>
<ul id="toc"></ul>
- <h2><a name="StorageBackendDir">Directory
pool</a></h2>
+ <h2><a id="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,
@@ -138,7 +138,7 @@
</p>
- <h2><a name="StorageBackendFS">Filesystem
pool</a></h2>
+ <h2><a id="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
@@ -212,7 +212,7 @@
</p>
- <h2><a name="StorageBackendNetFS">Network filesystem
pool</a></h2>
+ <h2><a id="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
@@ -266,7 +266,7 @@
</p>
- <h2><a name="StorageBackendLogical">Logical volume
pool</a></h2>
+ <h2><a id="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
@@ -303,7 +303,7 @@
</p>
- <h2><a name="StorageBackendDisk">Disk
pool</a></h2>
+ <h2><a id="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
@@ -394,7 +394,7 @@
</ul>
- <h2><a name="StorageBackendISCSI">iSCSI
pool</a></h2>
+ <h2><a id="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
@@ -433,7 +433,7 @@
The iSCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendSCSI">SCSI
pool</a></h2>
+ <h2><a id="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
@@ -465,7 +465,7 @@
The SCSI volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendMultipath">Multipath
pool</a></h2>
+ <h2><a id="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.
@@ -498,7 +498,7 @@
The Multipath volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendRBD">RBD pool</a></h2>
+ <h2><a id="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
@@ -571,7 +571,7 @@
The RBD pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendSheepdog">Sheepdog
pool</a></h2>
+ <h2><a id="StorageBackendSheepdog">Sheepdog
pool</a></h2>
<p>
This provides a pool based on a Sheepdog Cluster.
Sheepdog is a distributed storage system for QEMU/KVM.
@@ -630,7 +630,7 @@
The Sheepdog pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendGluster">Gluster
pool</a></h2>
+ <h2><a id="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
@@ -716,7 +716,7 @@
pool type.
</p>
- <h2><a name="StorageBackendZFS">ZFS pool</a></h2>
+ <h2><a id="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
@@ -754,7 +754,7 @@
<p>
The ZFS volume pool does not use the volume format type element.
</p>
- <h2><a name="StorageBackendVstorage">Vstorage
pool</a></h2>
+ <h2><a id="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
diff --git a/docs/uri.html.in b/docs/uri.html.in
index 7702ccc6e..defb9eec2 100644
--- a/docs/uri.html.in
+++ b/docs/uri.html.in
@@ -16,7 +16,7 @@ machine over the network.
To this end, libvirt uses URIs as used on the Web and as defined in <a
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. This page
documents libvirt URIs.
</p>
- <h2><a name="URI_libvirt">Specifying URIs to
libvirt</a></h2>
+ <h2><a id="URI_libvirt">Specifying URIs to
libvirt</a></h2>
<p>
The URI is passed as the <code>name</code> parameter to
@@ -33,7 +33,7 @@ documents libvirt URIs.
virConnectPtr conn = virConnectOpenReadOnly
(<b>"test:///default"</b>);
</pre>
<h2>
- <a name="URI_config">Configuring URI aliases</a>
+ <a id="URI_config">Configuring URI aliases</a>
</h2>
<p>
@@ -61,7 +61,7 @@ uri_aliases = [
set, no alias lookup will be attempted.
</p>
- <h2><a name="URI_default">Default URI
choice</a></h2>
+ <h2><a id="URI_default">Default URI
choice</a></h2>
<p>
If the URI passed to <code>virConnectOpen*</code> is NULL, then libvirt will
use the following
@@ -75,7 +75,7 @@ logic to determine what URI to use.
</ol>
<h2>
- <a name="URI_virsh">Specifying URIs to virsh, virt-manager and
virt-install</a>
+ <a id="URI_virsh">Specifying URIs to virsh, virt-manager and
virt-install</a>
</h2>
<p>
In virsh use the <code>-c</code> or <code>--connect</code>
option:
@@ -107,7 +107,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>
<h2>
- <a name="URI_xen">xen:/// URI</a>
+ <a id="URI_xen">xen:/// URI</a>
</h2>
<p>
<i>This section describes a feature which is new in libvirt >
@@ -118,7 +118,7 @@ To access a Xen hypervisor running on the local machine
use the URI <code>xen:///</code>.
</p>
<h2>
- <a name="URI_qemu">qemu:///... QEMU and KVM URIs</a>
+ <a id="URI_qemu">qemu:///... QEMU and KVM URIs</a>
</h2>
<p>
To use QEMU support in libvirt you must be running the
@@ -150,7 +150,7 @@ KVM guests in the <a href="format.html#KVM1">guest XML
as described
here</a>.
</p>
<h2>
- <a name="URI_remote">Remote URIs</a>
+ <a id="URI_remote">Remote URIs</a>
</h2>
<p>
Remote URIs are formed by taking ordinary local URIs and adding a
@@ -213,7 +213,7 @@ remote URI reference</a> and <a
href="remote.html">full documentation
for libvirt remote support</a>.
</p>
<h2>
- <a name="URI_test">test:///... Test URIs</a>
+ <a id="URI_test">test:///... Test URIs</a>
</h2>
<p>
The test driver is a dummy hypervisor for test purposes.
@@ -227,10 +227,10 @@ a set of host definitions held in the named file.
</li>
</ul>
<h2>
- <a name="URI_legacy">Other & legacy URI formats</a>
+ <a id="URI_legacy">Other & legacy URI formats</a>
</h2>
<h3>
- <a name="URI_NULL">NULL and empty string URIs</a>
+ <a id="URI_NULL">NULL and empty string URIs</a>
</h3>
<p>
Libvirt allows you to pass a <code>NULL</code> pointer to
@@ -254,7 +254,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>
<h3>
- <a name="URI_file">File paths (xend-unix-server)</a>
+ <a id="URI_file">File paths (xend-unix-server)</a>
</h3>
<p>
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
@@ -271,7 +271,7 @@ using a file URI such as:
virsh -c ///var/run/xend/xend-socket
</pre>
<h3>
- <a name="URI_http">Legacy: <code>http://...</code>
(xend-http-server)</a>
+ <a id="URI_http">Legacy: <code>http://...</code>
(xend-http-server)</a>
</h3>
<p>
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
@@ -307,7 +307,7 @@ Notes:
documentation as "unix server" or "http server".</li>
</ol>
<h3>
- <a name="URI_legacy_xen">Legacy:
<code>"xen"</code></a>
+ <a id="URI_legacy_xen">Legacy:
<code>"xen"</code></a>
</h3>
<p>
Another legacy URI is to specify name as the string
@@ -315,7 +315,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>
<h3>
- <a name="URI_legacy_proxy">Legacy: Xen proxy</a>
+ <a id="URI_legacy_proxy">Legacy: Xen proxy</a>
</h3>
<p>
Libvirt continues to support connections to a separately running Xen
diff --git a/docs/virshcmdref.html.in b/docs/virshcmdref.html.in
index 5503ca0da..f7cc5ddae 100644
--- a/docs/virshcmdref.html.in
+++ b/docs/virshcmdref.html.in
@@ -6,7 +6,7 @@
<ul id="toc"></ul>
- <h2><a name="description">Description</a></h2>
+ <h2><a id="description">Description</a></h2>
<p>
The new <b>Virsh Command Reference</b>, for documenting the commands
@@ -24,7 +24,7 @@
<p> </p>
- <h2><a name="viewing">Viewing Online</a></h2>
+ <h2><a id="viewing">Viewing Online</a></h2>
<p>
The latest version can be viewed directly online:
@@ -41,7 +41,7 @@
<p> </p>
- <h2><a name="downloading">Downloading</a></h2>
+ <h2><a id="downloading">Downloading</a></h2>
<p>
The latest version of the Virsh Command Reference can be downloaded:
@@ -68,7 +68,7 @@
</li>
</ul>
- <h2><a name="git">DocBook source GIT
repository</a></h2>
+ <h2><a id="git">DocBook source GIT
repository</a></h2>
<p>
The DocBook source is maintained in a <a
href="http://git-scm.com/">git</a> repository available on
diff --git a/docs/windows.html.in b/docs/windows.html.in
index a0fe533a3..708bb1b18 100644
--- a/docs/windows.html.in
+++ b/docs/windows.html.in
@@ -12,7 +12,7 @@
as well but we either haven't tested or received reports for them.
</p>
- <h2><a name="installer">Installation
packages</a></h2>
+ <h2><a id="installer">Installation
packages</a></h2>
<p>
Users who need pre-built Windows DLLs of libvirt are advised
@@ -29,7 +29,7 @@
against libvirt.
</p>
- <h2><a name="conntypes">Connection types</a></h2>
+ <h2><a id="conntypes">Connection types</a></h2>
<p>
These connection types are known to work:
@@ -71,7 +71,7 @@
be used in security sensitive environments.</b>
</p>
- <h2><a name="esx">Connecting to VMware
ESX/vSphere</a></h2>
+ <h2><a id="esx">Connecting to VMware
ESX/vSphere</a></h2>
<p>
Details on the capabilities, certificates, and connection string
@@ -81,7 +81,7 @@
<a
href="http://libvirt.org/drvesx.html">http://libvirt.org/drv...
- <h2><a name="tlscerts">TLS Certificates</a></h2>
+ <h2><a id="tlscerts">TLS Certificates</a></h2>
<p>
TLS certificates need to have been created and placed in the correct
@@ -141,21 +141,21 @@
<li>C:\Users\someuser\AppData\Roaming\libvirt\pki\libvirt\private\clientkey.pem</li>
</ul>
- <h2><a name="feedback">Feedback</a></h2>
+ <h2><a id="feedback">Feedback</a></h2>
<p>
Feedback and suggestions on changes to make and what else to include
<a href="contact.html">are desired</a>.
</p>
- <h2><a name="compiling">Compiling
yourself</a></h2>
+ <h2><a id="compiling">Compiling yourself</a></h2>
<p>
Libvirt can be compiled on Windows using the free
<a
href="http://www.mingw.org/">MinGW compiler</a>.
</p>
- <h3><a name="msys_setup">MSYS Build
script</a></h3>
+ <h3><a id="msys_setup">MSYS Build script</a></h3>
<p>
The easiest way is to use the <b>msys_setup</b> script, developed by
@@ -165,7 +165,7 @@
<a
href="https://github.com/photron/msys_setup">https://github....
- <h3><a name="cross-compile">Cross
compiling</a></h3>
+ <h3><a id="cross-compile">Cross compiling</a></h3>
<p>
You can also cross-compile to a Windows target from a Fedora machine
@@ -174,7 +174,7 @@
(which includes a working libvirt specfile).
</p>
- <h3><a name="configure">By hand</a></h3>
+ <h3><a id="configure">By hand</a></h3>
<p>
Use these options when following the instructions on the
--
2.13.3