diff --git a/docs/architecture.html.in b/docs/architecture.html.in index 5e56716615..7a5cf2dca8 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 Xen architecture -

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:

- -

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.

+

Note 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 12a1090c14..5534223384 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 ade7260896..5df73613ae 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: -

    -
      -
    1. The HTTP client does not fully support IPv6.
      2. -
    2. Many features do not work as expected across HTTP connections, in - particular, virConnectGetCapabilities. - The remote support however does work - correctly.
      3. -
    3. 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".
      4. -

    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 future code. -

    -

    - Legacy: Xen proxy -

    -

    -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. -

    -

    -There is no specific "Xen proxy" URI. However if a Xen URI of any of -the ordinary or legacy forms is used (eg. NULL, -"", "xen", ...) which fails, and the -user is not root, and the Xen proxy socket can be connected to -(/tmp/libvirt_proxy_conn), then libvirt will use a proxy -connection. -

    -

    -You should consider using libvirt remote support -in future. Since 0.8.6 libvirt doesn't contain -the Xen proxy anymore and you should use libvirtd instead.

    diff --git a/docs/windows.html.in b/docs/windows.html.in index 3f012d18da..57abf8fde5 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 \