提交 e2e76de0 编写于 作者: J Jim Fehlig

docs: remove mention of legacy Xen driver

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
上级 1dac5fbb
...@@ -19,32 +19,16 @@ ...@@ -19,32 +19,16 @@
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS 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 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 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 hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
supervise the control and execution of the sets of domains. The hypervisor, 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 drivers, kernels and daemons communicate though a shared system bus
implemented in the hypervisor. The figure below tries to provide a view of implemented in the hypervisor. The figure below tries to provide a view of
this environment:</p> this environment:</p>
<img src="architecture.gif" alt="The Xen architecture" /> <img src="architecture.gif" alt="The Xen architecture" />
<p>The library can be initialized in 2 ways depending on the level of <p>The library will interact with libxl for all management operations
privilege of the embedding program. If it runs with root access, on a Xen system.</p>
virConnectOpen() can be used, it will use three different ways to connect to <p>Note that the libvirt libxl driver only supports root access.</p>
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>
<h2><a id="QEMU">QEMU and KVM support</a></h2> <h2><a id="QEMU">QEMU and KVM support</a></h2>
......
...@@ -122,7 +122,8 @@ ...@@ -122,7 +122,8 @@
<li>The hardware architecture being used</li> <li>The hardware architecture being used</li>
<li>The name of the hypervisor (Xen, QEMU, KVM)</li> <li>The name of the hypervisor (Xen, QEMU, KVM)</li>
<li>The XML config of the guest domain if relevant</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> <li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
</ul> </ul>
......
...@@ -253,59 +253,6 @@ the user to type a URI in directly (if that is appropriate). If your ...@@ -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 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>. for future proofing it should choose a full <a href="#URI_xen"><code>xen:///</code> URI</a>.
</p> </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> <h3>
<a id="URI_legacy_xen">Legacy: <code>"xen"</code></a> <a id="URI_legacy_xen">Legacy: <code>"xen"</code></a>
</h3> </h3>
...@@ -313,27 +260,6 @@ Notes: ...@@ -313,27 +260,6 @@ Notes:
Another legacy URI is to specify name as the string Another legacy URI is to specify name as the string
<code>"xen"</code>. This will continue to refer to the Xen <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. 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> </p>
</body> </body>
</html> </html>
...@@ -185,7 +185,7 @@ ...@@ -185,7 +185,7 @@
--without-avahi \ --without-avahi \
--without-polkit \ --without-polkit \
--without-python \ --without-python \
--without-xen \ --without-libxl \
--without-qemu \ --without-qemu \
--without-lxc \ --without-lxc \
--without-openvz \ --without-openvz \
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册