mirror of https://gitee.com/openkylin/libvirt.git
docs: remove mention of legacy Xen driver
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
Jim Fehlig
parent
1dac5fbbbb
commit
e2e76de055
|
|
@ -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>Note that the libvirt libxl driver only supports root access.</p>
|
||||
|
||||
<h2><a id="QEMU">QEMU and KVM support</a></h2>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@
|
|||
--without-avahi \
|
||||
--without-polkit \
|
||||
--without-python \
|
||||
--without-xen \
|
||||
--without-libxl \
|
||||
--without-qemu \
|
||||
--without-lxc \
|
||||
--without-openvz \
|
||||
|
|
|
|||
Loading…
Reference in New Issue