Re: [libvirt] [PATCH 6/7] docs: remove mention of legacy Xen driver

2018-03-31 Thread Ján Tomko 

On Wed, Mar 28, 2018 at 08:58:31PM -0600, Jim Fehlig wrote:

Signed-off-by: Jim Fehlig 
---
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(-)

-
-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).
-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.
+The library will interact with libxl for all management operations
+on a Xen system.
+Not that the libvirt libxl driver only supports root access.


Note



QEmu and KVM support



Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 6/7] docs: remove mention of legacy Xen driver

2018-03-28 Thread Jim Fehlig 
Signed-off-by: Jim Fehlig 
---
 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:
 
-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:
-
-  a connection to the Xen Daemon though an HTTP RPC layer
-  a read/write connection to the Xen Store
-  use Xen Hypervisor calls
-  when used as non-root libvirt connect to a proxy daemon running
-  as root and providing read-only support
-
-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).
-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.
+The library will interact with libxl for all management operations
+on a Xen system.
+Not that the libvirt libxl driver only supports root access.
 
 QEmu and KVM support
 
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 @@
   The hardware architecture being used
   The name of the hypervisor (Xen, QEMU, KVM)
   The XML config of the guest domain if relevant
-  For Xen hypervisor, the XenD logfile from /var/log/xen
+  For Xen hypervisor, the domain logfiles from /var/log/xen and
+  /var/log/libvirt/libxl
   For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu
 
 
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 xen:/// URI.
 
-
-  File paths (xend-unix-server)
-
-
-If XenD is running and configured in /etc/xen/xend-config.sxp:
-
-
-(xend-unix-server yes)
-
-
-then it listens on a Unix domain socket, usually at
-/var/lib/xend/xend-socket.  You may pass a different path
-using a file URI such as:
-
-
-virsh -c ///var/run/xend/xend-socket
-
-
-  Legacy: http://... (xend-http-server)
-
-
-If XenD is running and configured in /etc/xen/xend-config.sxp:
-
-
-
-(xend-http-server yes)
-
-
-then it listens on TCP port 8000.  libvirt allows you to
-try to connect to xend running on remote machines by passing
-http://hostname[:port]/, for example:
-
-
-
-virsh -c http://oirase/ list
-
-
-This method is unencrypted and insecure and is definitely not
-recommended for production use.  Instead use libvirt's 
remote support.
-
-
-Notes:
-
-
-   The HTTP client does not fully support IPv6. 
-   Many features do not work as expected across HTTP connections, in
- particular, virConnectGetCapabilities.
- The remote support however does work
- correctly. 
-   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".
-
 
   Legacy: "xen"
 
@@ -313,27 +260,6 @@ Notes:
 Another legacy URI is to specify name as the string
 "xen".  This will continue to refer to the Xen
 hypervisor.  However you should prefer a full xen:/// URI in all