12:24 p.m.
Compare the table of contents on http://libvirt.org/migration.html to
most other pages on libvirt.org. For some reason, the build process of
converting migration.html.in into live html is rendering all links to
internal anchors as '#' instead of full '#name' links. I'm throwing
this out there in case someone else knows more quickly how to fix the
problem (I'm not very fluent with all the xsltproc conversion stuff in
the docs directory).
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4:24 p.m.
On Thu, Oct 04, 2012 at 11:24:53AM -0600, Eric Blake wrote:
Compare the table of contents on http://libvirt.org/migration.html
to
most other pages on libvirt.org. For some reason, the build process of
converting migration.html.in into live html is rendering all links to
internal anchors as '#' instead of full '#name' links. I'm throwing
this out there in case someone else knows more quickly how to fix the
problem (I'm not very fluent with all the xsltproc conversion stuff in
the docs directory).
It is because the <a></a> tags inside the <h2>/<h3> headings are
using
id=XXXX instead of name=XXXX.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
5:59 p.m.
New subject: [libvirt] [PATCH] docs: fix links in migration.html TOC
Use of the wrong attribute name caused the table of contents to
be useless. Fix suggested by Daniel P. Berrange.
* docs/migration.html.in: Use correct anchoring attribute.
---
Pushing under the trivial rule.
docs/migration.html.in | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/docs/migration.html.in b/docs/migration.html.in
index be3f9b7..c6b62f7 100644
--- a/docs/migration.html.in
+++ b/docs/migration.html.in
@@ -11,7 +11,7 @@
libvirt implements several options for migration.
</p>
- <h2><a id="transport">Network data
transports</a></h2>
+ <h2><a name="transport">Network data
transports</a></h2>
<p>
There are two options for the data transport used during migration, either
@@ -19,7 +19,7 @@
over a libvirtd connection.
</p>
- <h3><a id="transportnative">Hypervisor native
transport</a></h3>
+ <h3><a name="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
@@ -33,7 +33,7 @@
<img class="diagram" src="migration-native.png"
alt="Migration native path">
</p>
- <h3><a id="transporttunnel">libvirt tunnelled
transport</a></h3>
+ <h3><a name="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.
@@ -51,7 +51,7 @@
<img class="diagram" src="migration-tunnel.png"
alt="Migration tunnel path">
</p>
- <h2><a id="flow">Communication control
paths/flows</a></h2>
+ <h2><a name="flow">Communication control
paths/flows</a></h2>
<p>
Migration of virtual machines requires close co-ordination of the two
@@ -59,7 +59,7 @@
which may be on the source, the destination, or a third host.
</p>
- <h3><a id="flowmanageddirect">Managed direct
migration</a></h3>
+ <h3><a name="flowmanageddirect">Managed direct
migration</a></h3>
<p>
With <em>managed direct</em> migration, the libvirt client process
@@ -79,7 +79,7 @@
</p>
- <h3><a id="flowpeer2peer">Managed peer to peer
migration</a></h3>
+ <h3><a name="flowpeer2peer">Managed peer to peer
migration</a></h3>
<p>
With <em>peer to peer</em> migration, the libvirt client process only
@@ -101,7 +101,7 @@
</p>
- <h3><a id="flowunmanageddirect">Unmanaged direct
migration</a></h3>
+ <h3><a name="flowunmanageddirect">Unmanaged direct
migration</a></h3>
<p>
With <em>unmanaged direct</em> migration, neither the libvirt client
@@ -117,7 +117,7 @@
</p>
- <h2><a id="security">Data security</a></h2>
+ <h2><a name="security">Data security</a></h2>
<p>
Since the migration data stream includes a complete copy of the guest
@@ -136,7 +136,7 @@
facility should be used.
</p>
- <h2><a id="uris">Migration URIs</a></h2>
+ <h2><a name="uris">Migration URIs</a></h2>
<p>
Initiating a guest migration requires the client application to
@@ -186,7 +186,7 @@
to comply with local firewall policies</li>
</ol>
- <h2><a id="config">Configuration file
handling</a></h2>
+ <h2><a name="config">Configuration file
handling</a></h2>
<p>
There are two types of virtual machine known to libvirt. A
<em>transient</em>
@@ -429,10 +429,10 @@
</tbody>
</table>
- <h2><a id="scenarios">Migration scenarios</a></h2>
+ <h2><a name="scenarios">Migration
scenarios</a></h2>
- <h3><a id="scenarionativedirect">Native migration, client to
two libvirtd servers</a></h3>
+ <h3><a name="scenarionativedirect">Native migration, client to
two libvirtd servers</a></h3>
<p>
At an API level this requires use of virDomainMigrate, without the
@@ -462,7 +462,7 @@
Supported by Xen, QEMU, VMWare and VirtualBox drivers
</p>
- <h3><a id="scenarionativepeer2peer">Native migration, client to
and peer2peer between, two libvirtd servers</a></h3>
+ <h3><a name="scenarionativepeer2peer">Native migration, client
to and peer2peer between, two libvirtd servers</a></h3>
<p>
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set,
@@ -486,7 +486,7 @@
Supported by QEMU driver
</p>
- <h3><a id="scenariotunnelpeer2peer1">Tunnelled migration,
client and peer2peer between two libvirtd servers</a></h3>
+ <h3><a name="scenariotunnelpeer2peer1">Tunnelled migration,
client and peer2peer between two libvirtd servers</a></h3>
<p>
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED
@@ -509,7 +509,7 @@
Supported by QEMU driver
</p>
- <h3><a id="nativedirectunmanaged">Native migration, client to
one libvirtd server</a></h3>
+ <h3><a name="nativedirectunmanaged">Native migration, client to
one libvirtd server</a></h3>
<p>
virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set,
@@ -533,7 +533,7 @@
Supported by Xen driver
</p>
- <h3><a id="nativepeer2peer">Native migration, peer2peer between
two libvirtd servers</a></h3>
+ <h3><a name="nativepeer2peer">Native migration, peer2peer
between two libvirtd servers</a></h3>
<p>
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set,
@@ -570,7 +570,7 @@
Supported by the QEMU driver
</p>
- <h3><a id="scenariotunnelpeer2peer2">Tunnelled migration,
peer2peer between two libvirtd servers</a></h3>
+ <h3><a name="scenariotunnelpeer2peer2">Tunnelled migration,
peer2peer between two libvirtd servers</a></h3>
<p>
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER &
VIR_MIGRATE_TUNNELLED
--
1.7.11.4
4433
days inactive
4433
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Eric Blake