[libvirt] [PATCH 6/7] docs: remove mention of legacy Xen driver
Jim Fehlig
jfehlig at suse.com
Thu Mar 29 02:58:31 UTC 2018
Signed-off-by: Jim Fehlig <jfehlig at suse.com>
---
docs/architecture.html.in | 28 ++++--------------
docs/bugs.html.in | 3 +-
docs/uri.html.in | 74 -----------------------------------------------
docs/windows.html.in | 2 +-
4 files changed, 9 insertions(+), 98 deletions(-)
diff --git a/docs/architecture.html.in b/docs/architecture.html.in
index f1461ba88..cab4880a5 100644
--- a/docs/architecture.html.in
+++ b/docs/architecture.html.in
@@ -19,32 +19,16 @@
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
kernel provides most if not all of the actual drivers used by the set of
domains. It also runs the Xen Store, a database of information shared by the
-hypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemon
-supervise the control and execution of the sets of domains. The hypervisor,
+hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
+libxl provides a set of APIs for creating and managing domains, which can be used
+by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
drivers, kernels and daemons communicate though a shared system bus
implemented in the hypervisor. The figure below tries to provide a view of
this environment:</p>
<img src="architecture.gif" alt="The Xen architecture" />
- <p>The library can be initialized in 2 ways depending on the level of
-privilege of the embedding program. If it runs with root access,
-virConnectOpen() can be used, it will use three different ways to connect to
-the Xen infrastructure:</p>
- <ul>
- <li>a connection to the Xen Daemon though an HTTP RPC layer</li>
- <li>a read/write connection to the Xen Store</li>
- <li>use Xen Hypervisor calls</li>
- <li>when used as non-root libvirt connect to a proxy daemon running
- as root and providing read-only support</li>
- </ul>
- <p>The library will usually interact with the Xen daemon for any operation
-changing the state of the system, but for performance and accuracy reasons
-may talk directly to the hypervisor when gathering state information at
-least when possible (i.e. when the running program using libvirt has root
-privilege access).</p>
- <p>If it runs without root access virConnectOpenReadOnly() should be used to
-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>
+ <p>The library will interact with libxl for all management operations
+on a Xen system.</p>
+ <p>Not that the libvirt libxl driver only supports root access.</p>
<h2><a id="QEmu">QEmu and KVM support</a></h2>
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 12a1090c1..553422338 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -122,7 +122,8 @@
<li>The hardware architecture being used</li>
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
<li>The XML config of the guest domain if relevant</li>
- <li>For Xen hypervisor, the XenD logfile from /var/log/xen</li>
+ <li>For Xen hypervisor, the domain logfiles from /var/log/xen and
+ /var/log/libvirt/libxl</li>
<li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
</ul>
diff --git a/docs/uri.html.in b/docs/uri.html.in
index ade726089..5df73613a 100644
--- a/docs/uri.html.in
+++ b/docs/uri.html.in
@@ -253,59 +253,6 @@ the user to type a URI in directly (if that is appropriate). If your
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 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>:
-</p>
- <pre>
-(xend-unix-server yes)
-</pre>
- <p>
-then it listens on a Unix domain socket, usually at
-<code>/var/lib/xend/xend-socket</code>. You may pass a different path
-using a file URI such as:
-</p>
- <pre>
-virsh -c ///var/run/xend/xend-socket
-</pre>
- <h3>
- <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>:
-
-</p>
- <pre>
-(xend-http-server yes)
-</pre>
- <p>
-then it listens on TCP port 8000. libvirt allows you to
-try to connect to xend running on remote machines by passing
-<code>http://<i>hostname</i>[:<i>port</i>]/</code>, for example:
-
-</p>
- <pre>
-virsh -c http://oirase/ list
-</pre>
- <p>
-This method is unencrypted and insecure and is definitely not
-recommended for production use. Instead use <a href="remote.html">libvirt's remote support</a>.
-</p>
- <p>
-Notes:
-</p>
- <ol>
- <li> The HTTP client does not fully support IPv6. </li>
- <li> Many features do not work as expected across HTTP connections, in
- particular, <a href="html/libvirt-libvirt-host.html#virConnectGetCapabilities">virConnectGetCapabilities</a>.
- The <a href="remote.html">remote support</a> however does work
- correctly. </li>
- <li> XenD's new-style XMLRPC interface is not supported by
- libvirt, only the old-style sexpr interface known in the Xen
- documentation as "unix server" or "http server".</li>
- </ol>
<h3>
<a id="URI_legacy_xen">Legacy: <code>"xen"</code></a>
</h3>
@@ -313,27 +260,6 @@ Notes:
Another legacy URI is to specify name as the string
<code>"xen"</code>. This will continue to refer to the Xen
hypervisor. However you should prefer a full <a href="#URI_xen"><code>xen:///</code> URI</a> in all future code.
-</p>
- <h3>
- <a id="URI_legacy_proxy">Legacy: Xen proxy</a>
- </h3>
- <p>
-Libvirt continues to support connections to a separately running Xen
-proxy daemon. This provides a way to allow non-root users to make a
-safe (read-only) subset of queries to the hypervisor.
-</p>
- <p>
-There is no specific "Xen proxy" URI. However if a Xen URI of any of
-the ordinary or legacy forms is used (eg. <code>NULL</code>,
-<code>""</code>, <code>"xen"</code>, ...) which fails, <i>and</i> the
-user is not root, <i>and</i> the Xen proxy socket can be connected to
-(<code>/tmp/libvirt_proxy_conn</code>), then libvirt will use a proxy
-connection.
-</p>
- <p>
-You should consider using <a href="remote.html">libvirt remote support</a>
-in future. <span class="since">Since 0.8.6</span> libvirt doesn't contain
-the Xen proxy anymore and you should use libvirtd instead.
</p>
</body>
</html>
diff --git a/docs/windows.html.in b/docs/windows.html.in
index 3f012d18d..57abf8fde 100644
--- a/docs/windows.html.in
+++ b/docs/windows.html.in
@@ -185,7 +185,7 @@
--without-avahi \
--without-polkit \
--without-python \
- --without-xen \
+ --without-libxl \
--without-qemu \
--without-lxc \
--without-openvz \
--
2.16.2
More information about the libvir-list
mailing list