maint: this branch is now dead

Upstream is no longer willing to backport patches to a branch
this old.  If you disagree with the policy, please volunteer
to become the branch maintainer on libvir-list@redhat.com

Signed-off-by: Eric Blake <eblake@redhat.com>

.color_coded.in

@@ -1,40 +0,0 @@
--I@abs_top_builddir@
--I@abs_top_srcdir@
--I@abs_top_builddir@/gnulib/lib
--I@abs_top_srcdir@/gnulib/lib
--I@abs_top_builddir@/include
--I@abs_top_srcdir@/include
--I@abs_top_builddir@/src
--I@abs_top_srcdir@/src
--I@abs_top_builddir@/src/access
--I@abs_top_srcdir@/src/access
--I@abs_top_builddir@/src/admin
--I@abs_top_srcdir@/src/admin
--I@abs_top_builddir@/src/bhyve
--I@abs_top_srcdir@/src/bhyve
--I@abs_top_builddir@/src/conf
--I@abs_top_srcdir@/src/conf
--I@abs_top_builddir@/src/libxl
--I@abs_top_srcdir@/src/libxl
--I@abs_top_builddir@/src/locking
--I@abs_top_srcdir@/src/locking
--I@abs_top_builddir@/src/logging
--I@abs_top_srcdir@/src/logging
--I@abs_top_builddir@/src/lxc
--I@abs_top_srcdir@/src/lxc
--I@abs_top_builddir@/src/qemu
--I@abs_top_srcdir@/src/qemu
--I@abs_top_builddir@/src/remote
--I@abs_top_srcdir@/src/remote
--I@abs_top_builddir@/src/rpc
--I@abs_top_srcdir@/src/rpc
--I@abs_top_builddir@/src/secret
--I@abs_top_srcdir@/src/secret
--I@abs_top_builddir@/src/security
--I@abs_top_srcdir@/src/security
--I@abs_top_builddir@/src/util
--I@abs_top_srcdir@/src/util
--I@abs_top_builddir@/src/vmx
--I@abs_top_srcdir@/src/vmx
--I@abs_top_builddir@/src/xenconfig
--I@abs_top_srcdir@/src/xenconfig

.ctags

@@ -1,6 +0,0 @@
---recurse
---exclude=*.orig
---exclude=*.html
---exclude=*.html.in
---langmap=c:+.h.in
---c-kinds=+p

.ctags.d/libvirt.ctags

@@ -1 +0,0 @@
-../.ctags

.dir-locals.el

@@ -1,20 +0,0 @@
-(
- (c-mode . (
-            (c-file-style . "K&R")
-            (indent-tabs-mode . nil)
-            (c-indent-level . 4)
-            (c-basic-offset . 4)
-            ))
- (html-mode . (
-	       (indent-tabs-mode . nil)
-	       ))
- (sh-mode . (
-	     (indent-tabs-mode . nil)
-	     ))
- (nxml-mode . (
-	       (indent-tabs-mode . nil)
-	       ))
- (perl-mode . (
-	       (indent-tabs-mode . nil)
-	       ))
- )

.editorconfig

@@ -1,21 +0,0 @@
-# EditorConfig is a file format and collection of text editor plugins
-# for maintaining consistent coding styles between different editors
-# and IDEs. Most popular editors support this either natively or via
-# plugin.
-#
-# Check https://editorconfig.org for details.
-
-root = true
-
-[*]
-end_of_line = lf
-insert_final_newline = true
-charset = utf-8
-
-[*.c]
-indent_style = space
-indent_size = 4
-
-[*.{rng,xml}]
-indent_style = space
-indent_size = 2

.gitignore

@@ -1,44 +1,95 @@
-# vim related ignores
-*.swp
-.lvimrc
-
-# emacs related ignores
 *#*#
 *.#*#
-.#*
-
-# autotools related ignores
-!/m4/virt-*.m4
-*.cov
-/AUTHORS
-/INSTALL
-/aclocal.m4
-/autom4te.cache
-/build-aux/.gitignore
-/build-aux/compile
-/build-aux/depcomp
-/build-aux/missing
-/build-aux/test-driver
-/config.h.in
-/config.log
-/configure
-/m4/*
-Makefile.in
-
-# gnulib related ignores
-!/gnulib/lib/Makefile.am
-!/gnulib/tests/Makefile.am
+*.a
+*.exe
+*.gcda
+*.gcno
+*.gcov
+*.la
+*.lo
+*.o
+*.orig
 *.rej
 *~
+.git
+.git-module-status
+.lvimrc
+.sc-start-sc_*
+/ABOUT-NLS
+/COPYING
+/ChangeLog
+/GNUmakefile
+/INSTALL
+/NEWS
+/aclocal.m4
+/autom4te.cache
+/build-aux
+/build-aux/
+/build/
+/config.cache
+/config.guess
+/config.h
+/config.h.in
+/config.log
+/config.rpath
+/config.status
+/config.sub
+/configure
+/configure.lineno
+/daemon/*_dispatch.h
+/docs/apibuild.py.stamp
+/docs/hvsupport.html.in
+/docs/libvirt-qemu-*.xml
 /gnulib/lib/*
 /gnulib/m4/*
 /gnulib/tests/*
-
-# git related ignores
-*.orig
-.git-module-status
-
-# libvirt related ignores
-/build/
-/ci/scratch/
-tags
+/libtool
+/libvirt-*.tar.gz
+/libvirt-[0-9]*
+/libvirt.pc
+/libvirt.spec
+/ltconfig
+/ltmain.sh
+/m4/*
+/maint.mk
+/mingw32-libvirt.spec
+/mkinstalldirs
+/po/*
+/proxy/
+/python/generator.py.stamp
+/python/libvirt-qemu-export.c
+/python/libvirt-qemu.[ch]
+/python/libvirt_qemu.py
+/sc_*
+/src/hyperv/*.generated.*
+/src/libvirt_iohelper
+/src/locking/qemu-sanlock.conf
+/src/remote/*_client_bodies.h
+/src/remote/*_protocol.[ch]
+/src/rpc/virnetprotocol.[ch]
+/src/util/virkeymaps.h
+/tests/*.log
+/tests/cputest
+/tests/hashtest
+/tests/jsontest
+/tests/networkxml2argvtest
+/tests/nwfilterxml2xmltest
+/tests/openvzutilstest
+/tests/shunloadtest
+/update.log
+Makefile
+Makefile.in
+TAGS
+coverage
+cscope.files
+cscope.out
+results.log
+stamp-h
+stamp-h.in
+stamp-h1
+!/gnulib/lib/Makefile.am
+!/gnulib/tests/Makefile.am
+!/m4/virt-*.m4
+!/po/*.po
+!/po/POTFILES.in
+!/po/libvirt.pot

.gitlab-ci.yml

@@ -1,46 +0,0 @@
-.job_template: &job_definition
-  script:
-    - mkdir build
-    - cd build
-    - ../autogen.sh $CONFIGURE_OPTS || (cat config.log && exit 1)
-    - make -j $(getconf _NPROCESSORS_ONLN)
-
-# We could run every arch on every versions, but it is a little
-# overkill. Instead we split jobs evenly across 9, 10 and sid
-# to achieve reasonable cross-coverage.
-
-debian-9-cross-armv6l:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-armv6l:latest
-
-debian-9-cross-mips64el:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips64el:latest
-
-debian-9-cross-mips:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips:latest
-
-debian-10-cross-aarch64:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-aarch64:latest
-
-debian-10-cross-ppc64le:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-ppc64le:latest
-
-debian-10-cross-s390x:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-s390x:latest
-
-debian-sid-cross-armv7l:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-armv7l:latest
-
-debian-sid-cross-i686:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-i686:latest
-
-debian-sid-cross-mipsel:
-  <<: *job_definition
-  image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-mipsel:latest

.gitmodules

@@ -1,6 +1,3 @@
 [submodule "gnulib"]
 	path = .gnulib
-	url = https://git.savannah.gnu.org/git/gnulib.git/
-[submodule "keycodemapdb"]
-	path = src/keycodemapdb
-	url = https://gitlab.com/keycodemap/keycodemapdb.git
+	url = git://git.sv.gnu.org/gnulib.git

.gitpublish

@@ -1,3 +0,0 @@
-[gitpublishprofile "default"]
-base = master
-to = libvir-list@redhat.com

.mailmap

@@ -1,79 +0,0 @@
-# 'git shortlog --help' and look for mailmap for the format of each line
-
-# Email consolidation:
-# <Preferred address in AUTHORS> <other alias used by same author>
-
-<bozzolan@gmail.com> <redshift@gmx.com>
-<charles_duffy@messageone.com> <charles@dyfis.net>
-<claudio.bley@gmail.com> <cbley@av-test.de>
-<dfj@redhat.com> <dfj@dfj.bne.redhat.com>
-<dpkshetty@gmail.com> <deepakcs@linux.vnet.ibm.com>
-<dpkshetty@gmail.com> <deepakcs@redhat.com>
-<eblake@redhat.com> <ebb9@byu.net>
-<gdolley@arpnetworks.com> <gdolley@ucla.edu>
-<gerhard.stenzel@de.ibm.com> <gstenzel@linux.vnet.ibm.com>
-<jamie@canonical.com> <jamie@ubuntu.com>
-<laine@redhat.com> <laine@laine.org>
-<meyering@redhat.com> <jim@meyering.net>
-<socketpair@gmail.com> <socketpair gmail com>
-<soren@linux2go.dk> <soren@ubuntu.com>
-<jfehlig@suse.com> <jfehlig@novell.com>
-<jfehlig@suse.com> <jfehlig@linux-ypgk.site>
-<jclift@redhat.com> <justin@salasaga.org>
-<soren@linux2go.dk> <soren@canonical.com>
-<cfergeau@redhat.com> <teuf@gnome.org>
-<wency@cn.fujitsu.com> <wency cn fujitsu com>
-<cardoe@cardoe.com> <cardoe@gentoo.org>
-<fsimonce@redhat.com> <federico.simoncelli@gmail.com>
-<marcandre.lureau@redhat.com> <marcandre.lureau@gmail.com>
-<supriyak@linux.vnet.ibm.com> <supriyak@in.ibm.com>
-<neil@aldur.co.uk> <neil@brightbox.co.uk>
-<stefanb@us.ibm.com> <stefanb@linux.vnet.ibm.com>
-<stefanb@us.ibm.com> <stefannb@linux.vnet.ibm.com>
-<josh.durgin@inktank.com> <joshd@hq.newdream.net>
-<josh.durgin@inktank.com> <josh.durgin@dreamhost.com>
-<gerd@egidy.de> <lists@egidy.de>
-<gerd@egidy.de> <gerd.von.egidy@intra2net.com>
-<benoar@dolka.fr> <benjamin.cama@telecom-bretagne.eu>
-<zhlcindy@linux.vnet.ibm.com> <zhlcindy@gmail.com>
-<serge.hallyn@canonical.com> <serue@us.ibm.com>
-<pritesh.kothari@sun.com> <Pritesh.Kothari@Sun.COM>
-<cbosdonnat@suse.com> <cedric.bosdonnat@free.fr>
-<mnestratov@virtuozzo.com> <mnestratov@parallels.com>
-<nshirokovskiy@virtuozzo.com> <nshirokovskiy@parallels.com>
-<jyang@redhat.com> <osier@yunify.com>
-<kkoukiou@redhat.com> <k.koukiou@googlemail.com>
-<intrigeri@boum.org> <intrigeri+libvirt@boum.org>
-<fidencio@redhat.com> <fabiano@fidencio.org>
-<shi_lei@massclouds.com> <shilei.massclouds@gmx.com>
-<adrian.brzezinski@eo.pl> <redhat@adrb.pl>
-
-# Name consolidation:
-# Preferred author spelling <preferred email>
-Alex Jia <ajia@redhat.com>
-Royce Lv <lvroyce@linux.vnet.ibm.com>
-Daniel J Walsh <dwalsh@redhat.com>
-Ján Tomko <jtomko@redhat.com>
-Gerd von Egidy <gerd@egidy.de>
-MATSUDA Daiki <matsudadik@intellilink.co.jp>
-Tang Chen <tangchen@cn.fujitsu.com>
-Peng Zhou <ailvpeng25@gmail.com>
-Dirk Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
-Thibault VINCENT <thibault.vincent@smartjog.com>
-Aurelien Rougemont <beorn@binaries.fr>
-Serge E. Hallyn <serge.hallyn@canonical.com>
-Henrik Persson E <henrik.e.persson@ericsson.com>
-Philipp Hahn <hahn@univention.de>
-Pritesh Kothari <pritesh.kothari@sun.com>
-Wang Yufei (James) <james.wangyufei@huawei.com>
-Deepak C Shetty <dpkshetty@gmail.com>
-Dave Allan <dallan@redhat.com>
-Richard W.M. Jones <rjones@redhat.com>
-
-# Non-trivial consolidation:
-# see git documentation for information about the format
-Daniel P. Berrangé <berrange@redhat.com>
-Daniel P. Berrangé <berrange@redhat.com> <dan@berrange.com>
-Michal Prívozník <mprivozn@redhat.com>
-Michal Prívozník <mprivozn@redhat.com> <miso.privoznik@gmail.com>
-Marco Bozzolan <bozzolan@gmail.com> <redshift@gmx.com>

.travis.yml

@@ -1,118 +0,0 @@
-sudo: required
-language: generic
-
-branches:
-  except:
-    - /^.*-maint$/
-
-addons:
-  homebrew:
-    update: true
-    packages:
-      - ccache
-      - rpcgen
-      - xz
-      - yajl
-      - glib
-      - docutils
-
-matrix:
-  include:
-    - services:
-        - docker
-      env:
-        - IMAGE="ubuntu-1804"
-        - MAKE_ARGS="syntax-check distcheck"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS"
-    - services:
-        - docker
-      env:
-        - IMAGE="centos-7"
-        - MAKE_ARGS="syntax-check distcheck"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS"
-    - services:
-        - docker
-      env:
-        - IMAGE="debian-9"
-        - MAKE_ARGS="syntax-check distcheck"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS"
-    - services:
-        - docker
-      env:
-        - IMAGE="fedora-31"
-        - MAKE_ARGS="syntax-check distcheck"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS"
-    - services:
-        - docker
-      env:
-        - IMAGE="fedora-rawhide"
-        - MAKE_ARGS="syntax-check distcheck"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_MAKE_ARGS="$MAKE_ARGS"
-    - services:
-        - docker
-      env:
-        - IMAGE="fedora-30"
-        - MINGW="mingw32"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_CONFIGURE="$MINGW-configure"
-    - services:
-        - docker
-      env:
-        - IMAGE="fedora-30"
-        - MINGW="mingw64"
-      script:
-        - make -C ci/ ci-build@$IMAGE CI_CONFIGURE="$MINGW-configure"
-    - compiler: clang
-      language: c
-      os: osx
-      osx_image: xcode10.3
-      env:
-        - PATH="/usr/local/opt/gettext/bin:/usr/local/opt/ccache/libexec:/usr/local/opt/rpcgen/bin:$PATH"
-        - PKG_CONFIG_PATH="/usr/local/opt/libxml2/lib/pkgconfig"
-      before_script:
-        # Hack to blow away py2
-        - brew link --overwrite python
-      script:
-        # We can't run 'distcheck' or 'syntax-check' because they fail on
-        # macOS, but doing 'install' and 'dist' gives us some useful coverage
-        - mkdir build && cd build
-        - ../autogen.sh --prefix=$(pwd)/install-root && make -j3 && make -j3 install && make -j3 dist
-    - compiler: clang
-      language: c
-      os: osx
-      osx_image: xcode11.3
-      env:
-        - PATH="/usr/local/opt/gettext/bin:/usr/local/opt/ccache/libexec:/usr/local/opt/rpcgen/bin:$PATH"
-        - PKG_CONFIG_PATH="/usr/local/opt/libxml2/lib/pkgconfig"
-      before_script:
-        # Hack to blow away py2
-        - brew link --overwrite python
-      script:
-        # We can't run 'distcheck' or 'syntax-check' because they fail on
-        # macOS, but doing 'install' and 'dist' gives us some useful coverage
-        - mkdir build && cd build
-        - ../autogen.sh --prefix=$(pwd)/install-root && make -j3 && make -j3 install && make -j3 dist
-
-git:
-  submodules: true
-
-notifications:
-  irc:
-    # The channel name "irc.oftc.net#virt" is encrypted against libvirt/libvirt
-    # to prevent IRC notifications from github forks. This was created using:
-    # $ travis encrypt -r "libvirt/libvirt" "irc.oftc.net#virt"
-    channels:
-      - secure: "hUPdkLxX7nh75+clpnk4U0XLExLfV9DFKSvQSAUtf5JtDNMslj7AeOCf2wcbkNsEhkiF557odTAnov1s5m1w/yaa56zbjFAh5agzqRKya3QjqsrvlBKw/WuN+l82iMNLLeebTgCPAXrbAbGWH8YmYssp/7+eMsnKaVh84EQQNbMCHlLg6ovE26Fs18mZ6J5RC3OPa1vbv+xkdCHvGg/Oyp4K8bpU7RYyimA56jdxI/OfdTH9HxntHYSzykR7hDbyzZhdIlAUyRKReQVjcV5+R8fdDL/1imyGA/88KTztMeKXpZ5Rf+Ss3vYLZb6qsLLegCZ4AU/q0vvbWxjpZGJZoeyrVpfBTZdYGIzmLTMl9GYXXa/gDwFlbvRDiPDG4TIy6GlMUROinj7KRKEHu1fWRYu012ife5OjidxcwrTnz21vYaCv3AKWPpMPxwIzQPkY1hex9uLLX6z+TrAxxDLF+7UzRT9w2RLFBkLYlj2aDVrLAVb/ynRsxDz5CGzC61FSQVft2e308SkGjdn8YxvguCuXv+N70Fu1cvFyh5XYeHb4fbBRo0Ctzaec78leHlQvRGWKJxXDXRkE2lvvBc7YbBNSAYh7Fs8Y+zY7l7rMxvXdrt3nuaNQhe74V3yhxPDAld66qmAn9TYMmaZW2f5/KKKILLbCa0t2MxiAc6L2OI8="
-    on_success: change
-    on_failure: always
-  email:
-    # The list name 'libvirt-ci@redhat.com" is encrypted against libvirt/libvirt
-    # to prevent IRC notifications from github forks. This was created using:
-    # $ travis encrypt -r "libvirt/libvirt" "libvirt-ci@redhat.com"
-    recipients:
-      - secure: "QcU9eP96P0RlDNzVRZl/4sxyydPStGzECrpgJhr2IPB/7pHk23yaBrmUsq9S830tB+jwLGma1IscNB8uf7Sf7WY+cYIpfR8v030OffWnaipo/Gcs0dpnlfURWHjOFQI3RJzGEihsqvbwUFOwsM+3IDyO3qdWaiT6cN2Tj9ROlwYCySSX5YWzLyX7arBZ4lp8ESs7ohQaEwp2cegnMP2oGPJJe4SebvlCDjHZbjkU5aEradwUWnRQDJZWTKknpNLArVFxN2/ixp6f/MGY4DmkHoDweio6mHIPN5zTs5Jt32aiX6wDBa+bBa4v8TCRqzhYkQ63ZZhNV8bY5Uf9ufTdyvt96yIANyakd85b1QpMdAX76IyJi1l0/Uub6DTQZAcq3vK7iPjGeTVSpyoXrqTfGy4JxMjqDoocpWvv8ALX1wrYI/HfN2R2Aepw9jModTimOsebYhJ1yMhSt8qnh5AQNftGKL2JBKoA1LWdU2YJ5fO1bGjKNiVEkGFQTPYFWrYCUY5JcT+s5WCzNeMNm8s9na8liYhGl3WtS3rPr5M8bof+BMsBhG2hQ0loduc94x2GkvyhQZUgRbqrwNR+y4hn+rWFC3hBzzyiAULs43vY/PJ+eBdKEf3VAc0MkhQ8GgXGSA61fR6aXYonroI/WnBVItwDmUnnMfSziZXxk09GLl4="

.ycm_extra_conf.py.in

@@ -1,45 +0,0 @@
-flags = [
-  '-I@abs_top_builddir@',
-  '-I@abs_top_srcdir@',
-  '-I@abs_top_builddir@/gnulib/lib',
-  '-I@abs_top_srcdir@/gnulib/lib',
-  '-I@abs_top_builddir@/include',
-  '-I@abs_top_srcdir@/include',
-  '-I@abs_top_builddir@/src',
-  '-I@abs_top_srcdir@/src',
-  '-I@abs_top_builddir@/src/access',
-  '-I@abs_top_srcdir@/src/access',
-  '-I@abs_top_builddir@/src/admin',
-  '-I@abs_top_srcdir@/src/admin',
-  '-I@abs_top_builddir@/src/bhyve',
-  '-I@abs_top_srcdir@/src/bhyve',
-  '-I@abs_top_builddir@/src/conf',
-  '-I@abs_top_srcdir@/src/conf',
-  '-I@abs_top_builddir@/src/libxl',
-  '-I@abs_top_srcdir@/src/libxl',
-  '-I@abs_top_builddir@/src/locking',
-  '-I@abs_top_srcdir@/src/locking',
-  '-I@abs_top_builddir@/src/logging',
-  '-I@abs_top_srcdir@/src/logging',
-  '-I@abs_top_builddir@/src/lxc',
-  '-I@abs_top_srcdir@/src/lxc',
-  '-I@abs_top_builddir@/src/qemu',
-  '-I@abs_top_srcdir@/src/qemu',
-  '-I@abs_top_builddir@/src/remote',
-  '-I@abs_top_srcdir@/src/remote',
-  '-I@abs_top_builddir@/src/rpc',
-  '-I@abs_top_srcdir@/src/rpc',
-  '-I@abs_top_builddir@/src/secret',
-  '-I@abs_top_srcdir@/src/secret',
-  '-I@abs_top_builddir@/src/security',
-  '-I@abs_top_srcdir@/src/security',
-  '-I@abs_top_builddir@/src/util',
-  '-I@abs_top_srcdir@/src/util',
-  '-I@abs_top_builddir@/src/vmx',
-  '-I@abs_top_srcdir@/src/vmx',
-  '-I@abs_top_builddir@/src/xenconfig',
-  '-I@abs_top_srcdir@/src/xenconfig',
-]
-
-def FlagsForFile(filename, **kwargs):
-  return { 'flags': flags, 'do_cache': True }

ABOUT-NLS

@@ -1 +0,0 @@
-po/README.md

AUTHORS.in

@@ -1,102 +0,0 @@
-   libvirt Authors
-   ===============
-
-The libvirt project was initiated by:
-
-Daniel Veillard <veillard@redhat.com> or <daniel@veillard.com>
-
-The primary maintainers and people with commit access rights:
-
-Alex Jia <ajia@redhat.com>
-Andrea Bolognani <abologna@redhat.com>
-Cédric Bosdonnat <cbosdonnat@suse.com>
-Christian Ehrhardt <christian.ehrhardt@canonical.com>
-Christophe Fergeau <cfergeau@redhat.com>
-Claudio Bley <claudio.bley@gmail.com>
-Cole Robinson <crobinso@redhat.com>
-Daniel P. Berrangé <berrange@redhat.com>
-Daniel Veillard <veillard@redhat.com>
-Doug Goldstein <cardoe@gentoo.org>
-Eric Blake <eblake@redhat.com>
-Erik Skultety <eskultet@redhat.com>
-Fabiano Fidêncio <fidencio@redhat.com>
-Gao Feng <gaofeng@cn.fujitsu.com>
-Guido Günther <agx@sigxcpu.org>
-Ján Tomko <jtomko@redhat.com>
-Jim Fehlig <jfehlig@suse.com>
-Jiří Denemark <jdenemar@redhat.com>
-John Ferlan <jferlan@redhat.com>
-Katerina Koukiou <kkoukiou@redhat.com>
-Laine Stump <laine@redhat.com>
-Mark McLoughlin <markmc@redhat.com>
-Martin Kletzander <mkletzan@redhat.com>
-Matthias Bolte <matthias.bolte@googlemail.com>
-Maxim Nestratov <mnestratov@virtuozzo.com>
-Michal Prívozník <mprivozn@redhat.com>
-Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
-Pavel Hrdina <phrdina@redhat.com>
-Peter Krempa <pkrempa@redhat.com>
-Richard W.M. Jones <rjones@redhat.com>
-Roman Bogorodskiy <bogorodskiy@gmail.com>
-Stefan Berger <stefanb@us.ibm.com>
-Wen Congyang <wency@cn.fujitsu.com>
-
-Previous maintainers:
-
-Anthony Liguori <aliguori@us.ibm.com>
-Atsushi SAKAI <sakaia@jp.fujitsu.com>
-Chris Lalancette <clalance@redhat.com>
-Dan Smith <danms@us.ibm.com>
-Dave Allan <dallan@redhat.com>
-Dave Leskovec <dlesko@linux.vnet.ibm.com>
-Dmitry Guryanov <dguryanov@parallels.com>
-Guannan Ren <gren@redhat.com>
-Jim Meyering <meyering@redhat.com>
-John Levon <john.levon@sun.com>
-Justin Clift <jclift@redhat.com>
-Karel Zak <kzak@redhat.com>
-Osier Yang <jyang@redhat.com>
-
-Patches have also been contributed by:
-
-Abel Míguez Rodríguez <amiguezr@pdi.ucm.es>
-Amit Shah <amit.shah@redhat.com>
-Andrew Puch <apuch@redhat.com>
-Anton Protopopov <aspsk2@gmail.com>
-Ben Guthro <ben.guthro@gmail.com>
-Daniel Hokka Zakrisson <daniel@hozac.com>
-Dan Wendlandt <dan@nicira.com>
-David Lively <dlively@virtualiron.com>
-David Lutterkort <dlutter@redhat.com>
-Evgeniy Sokolov <evg@openvz.org>
-Hugh Brock <hbrock@redhat.com>
-Itamar Heim <iheim@redhat.com>
-James Morris <jmorris@namei.org>
-Javier Fontan <jfontan@gmail.com>
-Jeremy Katz <katzj@redhat.com>
-Kaitlin Rupert <kaitlin@linux.vnet.ibm.com>
-Kazuki Mizushima <mizushima.kazuk@jp.fujitsu.com>
-Mads Chr. Olesen <shiyee@shiyee.dk>
-Mark Johnson <johnson.nh@gmail.com>
-Markus Armbruster <armbru@redhat.com>
-Masayuki Sunou <fj1826dm@aa.jp.fujitsu.com>
-Matthias Witte <witte@netzquadrat.de>
-Michel Ponceau <michel.ponceau@bull.net>
-Nobuhiro Itou <fj0873gn@aa.jp.fujitsu.com>
-Pete Vetere <pvetere@redhat.com>
-Philippe Berthault <philippe.berthault@Bull.net>
-Saori Fukuta <fukuta.saori@jp.fujitsu.com>
-Shigeki Sakamoto <fj0588di@aa.jp.fujitsu.com>
-Shuveb Hussain <shuveb@binarykarma.com>
-Stefan de Konink <dekonink@kinkrsoftware.nl>
-Takahashi Tomohiro <takatom@jp.fujitsu.com>
-Tatsuro Enokura <fj7716hz@aa.jp.fujitsu.com>
-
-#contributorslist#
-
-The libvirt logo was designed by Diana Fong
-
--- End
-;; Local Variables:
-;; coding: utf-8
-;; End:

COPYING

@@ -1,339 +0,0 @@
-                    GNU GENERAL PUBLIC LICENSE
-                       Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-                            Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Lesser General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-                    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-                            NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
-                     END OF TERMS AND CONDITIONS
-
-            How to Apply These Terms to Your New Programs
-
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-
-    You should have received a copy of the GNU General Public License along
-    with this program; if not, write to the Free Software Foundation, Inc.,
-    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
-    Gnomovision version 69, Copyright (C) year name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Lesser General
-Public License instead of this License.

COPYING.LESSER

@@ -1,502 +0,0 @@
-                  GNU LESSER GENERAL PUBLIC LICENSE
-                       Version 2.1, February 1999
-
- Copyright (C) 1991, 1999 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-[This is the first released version of the Lesser GPL.  It also counts
- as the successor of the GNU Library Public License, version 2, hence
- the version number 2.1.]
-
-                            Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-Licenses are intended to guarantee your freedom to share and change
-free software--to make sure the software is free for all its users.
-
-  This license, the Lesser General Public License, applies to some
-specially designated software packages--typically libraries--of the
-Free Software Foundation and other authors who decide to use it.  You
-can use it too, but we suggest you first think carefully about whether
-this license or the ordinary General Public License is the better
-strategy to use in any particular case, based on the explanations below.
-
-  When we speak of free software, we are referring to freedom of use,
-not price.  Our General Public Licenses are designed to make sure that
-you have the freedom to distribute copies of free software (and charge
-for this service if you wish); that you receive source code or can get
-it if you want it; that you can change the software and use pieces of
-it in new free programs; and that you are informed that you can do
-these things.
-
-  To protect your rights, we need to make restrictions that forbid
-distributors to deny you these rights or to ask you to surrender these
-rights.  These restrictions translate to certain responsibilities for
-you if you distribute copies of the library or if you modify it.
-
-  For example, if you distribute copies of the library, whether gratis
-or for a fee, you must give the recipients all the rights that we gave
-you.  You must make sure that they, too, receive or can get the source
-code.  If you link other code with the library, you must provide
-complete object files to the recipients, so that they can relink them
-with the library after making changes to the library and recompiling
-it.  And you must show them these terms so they know their rights.
-
-  We protect your rights with a two-step method: (1) we copyright the
-library, and (2) we offer you this license, which gives you legal
-permission to copy, distribute and/or modify the library.
-
-  To protect each distributor, we want to make it very clear that
-there is no warranty for the free library.  Also, if the library is
-modified by someone else and passed on, the recipients should know
-that what they have is not the original version, so that the original
-author's reputation will not be affected by problems that might be
-introduced by others.
-
-  Finally, software patents pose a constant threat to the existence of
-any free program.  We wish to make sure that a company cannot
-effectively restrict the users of a free program by obtaining a
-restrictive license from a patent holder.  Therefore, we insist that
-any patent license obtained for a version of the library must be
-consistent with the full freedom of use specified in this license.
-
-  Most GNU software, including some libraries, is covered by the
-ordinary GNU General Public License.  This license, the GNU Lesser
-General Public License, applies to certain designated libraries, and
-is quite different from the ordinary General Public License.  We use
-this license for certain libraries in order to permit linking those
-libraries into non-free programs.
-
-  When a program is linked with a library, whether statically or using
-a shared library, the combination of the two is legally speaking a
-combined work, a derivative of the original library.  The ordinary
-General Public License therefore permits such linking only if the
-entire combination fits its criteria of freedom.  The Lesser General
-Public License permits more lax criteria for linking other code with
-the library.
-
-  We call this license the "Lesser" General Public License because it
-does Less to protect the user's freedom than the ordinary General
-Public License.  It also provides other free software developers Less
-of an advantage over competing non-free programs.  These disadvantages
-are the reason we use the ordinary General Public License for many
-libraries.  However, the Lesser license provides advantages in certain
-special circumstances.
-
-  For example, on rare occasions, there may be a special need to
-encourage the widest possible use of a certain library, so that it becomes
-a de-facto standard.  To achieve this, non-free programs must be
-allowed to use the library.  A more frequent case is that a free
-library does the same job as widely used non-free libraries.  In this
-case, there is little to gain by limiting the free library to free
-software only, so we use the Lesser General Public License.
-
-  In other cases, permission to use a particular library in non-free
-programs enables a greater number of people to use a large body of
-free software.  For example, permission to use the GNU C Library in
-non-free programs enables many more people to use the whole GNU
-operating system, as well as its variant, the GNU/Linux operating
-system.
-
-  Although the Lesser General Public License is Less protective of the
-users' freedom, it does ensure that the user of a program that is
-linked with the Library has the freedom and the wherewithal to run
-that program using a modified version of the Library.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.  Pay close attention to the difference between a
-"work based on the library" and a "work that uses the library".  The
-former contains code derived from the library, whereas the latter must
-be combined with the library in order to run.
-
-                  GNU LESSER GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License Agreement applies to any software library or other
-program which contains a notice placed by the copyright holder or
-other authorized party saying it may be distributed under the terms of
-this Lesser General Public License (also called "this License").
-Each licensee is addressed as "you".
-
-  A "library" means a collection of software functions and/or data
-prepared so as to be conveniently linked with application programs
-(which use some of those functions and data) to form executables.
-
-  The "Library", below, refers to any such software library or work
-which has been distributed under these terms.  A "work based on the
-Library" means either the Library or any derivative work under
-copyright law: that is to say, a work containing the Library or a
-portion of it, either verbatim or with modifications and/or translated
-straightforwardly into another language.  (Hereinafter, translation is
-included without limitation in the term "modification".)
-
-  "Source code" for a work means the preferred form of the work for
-making modifications to it.  For a library, complete source code means
-all the source code for all modules it contains, plus any associated
-interface definition files, plus the scripts used to control compilation
-and installation of the library.
-
-  Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running a program using the Library is not restricted, and output from
-such a program is covered only if its contents constitute a work based
-on the Library (independent of the use of the Library in a tool for
-writing it).  Whether that is true depends on what the Library does
-and what the program that uses the Library does.
-
-  1. You may copy and distribute verbatim copies of the Library's
-complete source code as you receive it, in any medium, provided that
-you conspicuously and appropriately publish on each copy an
-appropriate copyright notice and disclaimer of warranty; keep intact
-all the notices that refer to this License and to the absence of any
-warranty; and distribute a copy of this License along with the
-Library.
-
-  You may charge a fee for the physical act of transferring a copy,
-and you may at your option offer warranty protection in exchange for a
-fee.
-
-  2. You may modify your copy or copies of the Library or any portion
-of it, thus forming a work based on the Library, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) The modified work must itself be a software library.
-
-    b) You must cause the files modified to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    c) You must cause the whole of the work to be licensed at no
-    charge to all third parties under the terms of this License.
-
-    d) If a facility in the modified Library refers to a function or a
-    table of data to be supplied by an application program that uses
-    the facility, other than as an argument passed when the facility
-    is invoked, then you must make a good faith effort to ensure that,
-    in the event an application does not supply such function or
-    table, the facility still operates, and performs whatever part of
-    its purpose remains meaningful.
-
-    (For example, a function in a library to compute square roots has
-    a purpose that is entirely well-defined independent of the
-    application.  Therefore, Subsection 2d requires that any
-    application-supplied function or table used by this function must
-    be optional: if the application does not supply it, the square
-    root function must still compute square roots.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Library,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Library, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote
-it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Library.
-
-In addition, mere aggregation of another work not based on the Library
-with the Library (or with a work based on the Library) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may opt to apply the terms of the ordinary GNU General Public
-License instead of this License to a given copy of the Library.  To do
-this, you must alter all the notices that refer to this License, so
-that they refer to the ordinary GNU General Public License, version 2,
-instead of to this License.  (If a newer version than version 2 of the
-ordinary GNU General Public License has appeared, then you can specify
-that version instead if you wish.)  Do not make any other change in
-these notices.
-
-  Once this change is made in a given copy, it is irreversible for
-that copy, so the ordinary GNU General Public License applies to all
-subsequent copies and derivative works made from that copy.
-
-  This option is useful when you wish to copy part of the code of
-the Library into a program that is not a library.
-
-  4. You may copy and distribute the Library (or a portion or
-derivative of it, under Section 2) in object code or executable form
-under the terms of Sections 1 and 2 above provided that you accompany
-it with the complete corresponding machine-readable source code, which
-must be distributed under the terms of Sections 1 and 2 above on a
-medium customarily used for software interchange.
-
-  If distribution of object code is made by offering access to copy
-from a designated place, then offering equivalent access to copy the
-source code from the same place satisfies the requirement to
-distribute the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  5. A program that contains no derivative of any portion of the
-Library, but is designed to work with the Library by being compiled or
-linked with it, is called a "work that uses the Library".  Such a
-work, in isolation, is not a derivative work of the Library, and
-therefore falls outside the scope of this License.
-
-  However, linking a "work that uses the Library" with the Library
-creates an executable that is a derivative of the Library (because it
-contains portions of the Library), rather than a "work that uses the
-library".  The executable is therefore covered by this License.
-Section 6 states terms for distribution of such executables.
-
-  When a "work that uses the Library" uses material from a header file
-that is part of the Library, the object code for the work may be a
-derivative work of the Library even though the source code is not.
-Whether this is true is especially significant if the work can be
-linked without the Library, or if the work is itself a library.  The
-threshold for this to be true is not precisely defined by law.
-
-  If such an object file uses only numerical parameters, data
-structure layouts and accessors, and small macros and small inline
-functions (ten lines or less in length), then the use of the object
-file is unrestricted, regardless of whether it is legally a derivative
-work.  (Executables containing this object code plus portions of the
-Library will still fall under Section 6.)
-
-  Otherwise, if the work is a derivative of the Library, you may
-distribute the object code for the work under the terms of Section 6.
-Any executables containing that work also fall under Section 6,
-whether or not they are linked directly with the Library itself.
-
-  6. As an exception to the Sections above, you may also combine or
-link a "work that uses the Library" with the Library to produce a
-work containing portions of the Library, and distribute that work
-under terms of your choice, provided that the terms permit
-modification of the work for the customer's own use and reverse
-engineering for debugging such modifications.
-
-  You must give prominent notice with each copy of the work that the
-Library is used in it and that the Library and its use are covered by
-this License.  You must supply a copy of this License.  If the work
-during execution displays copyright notices, you must include the
-copyright notice for the Library among them, as well as a reference
-directing the user to the copy of this License.  Also, you must do one
-of these things:
-
-    a) Accompany the work with the complete corresponding
-    machine-readable source code for the Library including whatever
-    changes were used in the work (which must be distributed under
-    Sections 1 and 2 above); and, if the work is an executable linked
-    with the Library, with the complete machine-readable "work that
-    uses the Library", as object code and/or source code, so that the
-    user can modify the Library and then relink to produce a modified
-    executable containing the modified Library.  (It is understood
-    that the user who changes the contents of definitions files in the
-    Library will not necessarily be able to recompile the application
-    to use the modified definitions.)
-
-    b) Use a suitable shared library mechanism for linking with the
-    Library.  A suitable mechanism is one that (1) uses at run time a
-    copy of the library already present on the user's computer system,
-    rather than copying library functions into the executable, and (2)
-    will operate properly with a modified version of the library, if
-    the user installs one, as long as the modified version is
-    interface-compatible with the version that the work was made with.
-
-    c) Accompany the work with a written offer, valid for at
-    least three years, to give the same user the materials
-    specified in Subsection 6a, above, for a charge no more
-    than the cost of performing this distribution.
-
-    d) If distribution of the work is made by offering access to copy
-    from a designated place, offer equivalent access to copy the above
-    specified materials from the same place.
-
-    e) Verify that the user has already received a copy of these
-    materials or that you have already sent this user a copy.
-
-  For an executable, the required form of the "work that uses the
-Library" must include any data and utility programs needed for
-reproducing the executable from it.  However, as a special exception,
-the materials to be distributed need not include anything that is
-normally distributed (in either source or binary form) with the major
-components (compiler, kernel, and so on) of the operating system on
-which the executable runs, unless that component itself accompanies
-the executable.
-
-  It may happen that this requirement contradicts the license
-restrictions of other proprietary libraries that do not normally
-accompany the operating system.  Such a contradiction means you cannot
-use both them and the Library together in an executable that you
-distribute.
-
-  7. You may place library facilities that are a work based on the
-Library side-by-side in a single library together with other library
-facilities not covered by this License, and distribute such a combined
-library, provided that the separate distribution of the work based on
-the Library and of the other library facilities is otherwise
-permitted, and provided that you do these two things:
-
-    a) Accompany the combined library with a copy of the same work
-    based on the Library, uncombined with any other library
-    facilities.  This must be distributed under the terms of the
-    Sections above.
-
-    b) Give prominent notice with the combined library of the fact
-    that part of it is a work based on the Library, and explaining
-    where to find the accompanying uncombined form of the same work.
-
-  8. You may not copy, modify, sublicense, link with, or distribute
-the Library except as expressly provided under this License.  Any
-attempt otherwise to copy, modify, sublicense, link with, or
-distribute the Library is void, and will automatically terminate your
-rights under this License.  However, parties who have received copies,
-or rights, from you under this License will not have their licenses
-terminated so long as such parties remain in full compliance.
-
-  9. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Library or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Library (or any work based on the
-Library), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Library or works based on it.
-
-  10. Each time you redistribute the Library (or any work based on the
-Library), the recipient automatically receives a license from the
-original licensor to copy, distribute, link with or modify the Library
-subject to these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties with
-this License.
-
-  11. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Library at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Library by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Library.
-
-If any portion of this section is held invalid or unenforceable under any
-particular circumstance, the balance of the section is intended to apply,
-and the section as a whole is intended to apply in other circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  12. If the distribution and/or use of the Library is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Library under this License may add
-an explicit geographical distribution limitation excluding those countries,
-so that distribution is permitted only in or among countries not thus
-excluded.  In such case, this License incorporates the limitation as if
-written in the body of this License.
-
-  13. The Free Software Foundation may publish revised and/or new
-versions of the Lesser General Public License from time to time.
-Such new versions will be similar in spirit to the present version,
-but may differ in detail to address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Library
-specifies a version number of this License which applies to it and
-"any later version", you have the option of following the terms and
-conditions either of that version or of any later version published by
-the Free Software Foundation.  If the Library does not specify a
-license version number, you may choose any version ever published by
-the Free Software Foundation.
-
-  14. If you wish to incorporate parts of the Library into other free
-programs whose distribution conditions are incompatible with these,
-write to the author to ask for permission.  For software which is
-copyrighted by the Free Software Foundation, write to the Free
-Software Foundation; we sometimes make exceptions for this.  Our
-decision will be guided by the two goals of preserving the free status
-of all derivatives of our free software and of promoting the sharing
-and reuse of software generally.
-
-                            NO WARRANTY
-
-  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
-WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
-EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
-OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
-KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
-PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
-LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
-THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
-
-  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
-WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
-AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
-FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
-CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
-LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
-RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
-FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
-SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
-DAMAGES.
-
-                     END OF TERMS AND CONDITIONS
-
-           How to Apply These Terms to Your New Libraries
-
-  If you develop a new library, and you want it to be of the greatest
-possible use to the public, we recommend making it free software that
-everyone can redistribute and change.  You can do so by permitting
-redistribution under these terms (or, alternatively, under the terms of the
-ordinary General Public License).
-
-  To apply these terms, attach the following notices to the library.  It is
-safest to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least the
-"copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the library's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-
-    This library is free software; you can redistribute it and/or
-    modify it under the terms of the GNU Lesser General Public
-    License as published by the Free Software Foundation; either
-    version 2.1 of the License, or (at your option) any later version.
-
-    This library is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    Lesser General Public License for more details.
-
-    You should have received a copy of the GNU Lesser General Public
-    License along with this library; if not, write to the Free Software
-    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
-
-Also add information on how to contact you by electronic and paper mail.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the library, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the
-  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
-
-  <signature of Ty Coon>, 1 April 1990
-  Ty Coon, President of Vice
-
-That's all there is to it!

ChangeLog

@@ -1,15 +0,0 @@
-libvirt ChangeLog
-=================
-
-The libvirt project doesn't include a detailed ChangeLog in its release
-archives.
-
-If you're interested in the full list of changes made to libvirt since
-the project was started, you can clone the git repository from
-
-  https://libvirt.org/git/libvirt.git
-
-and browse them locally using your favorite git history viewer or,
-alternatively, browse them online at
-
-  https://libvirt.org/git/?p=libvirt.git;a=log

GNUmakefile

@@ -1,74 +0,0 @@
-# Having a separate GNUmakefile lets me 'include' the dynamically
-# generated rules created via cfg.mk (package-local configuration)
-# as well as maint.mk (generic maintainer rules).
-# This makefile is used only if you run GNU Make.
-# It is necessary if you want to build targets usually of interest
-# only to the maintainer.
-
-# Copyright (C) 2001, 2003, 2006-2019 Free Software Foundation, Inc.
-
-# This program is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <https://www.gnu.org/licenses/>.
-
-_build-aux ?= build-aux
-_autoreconf ?= autoreconf -v
-
-# If the user runs GNU make but has not yet run ./configure,
-# give them a diagnostic.
-_gl-Makefile := $(wildcard [M]akefile)
-ifneq ($(_gl-Makefile),)
-
-# Make tar archive easier to reproduce.
-export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
-
-# Allow the user to add to this in the Makefile.
-ALL_RECURSIVE_TARGETS =
-
-include Makefile
-include $(srcdir)/$(_build-aux)/syntax-check.mk
-
-else
-
-.DEFAULT_GOAL := abort-due-to-no-makefile
-srcdir = .
-
-# The package can override .DEFAULT_GOAL to run actions like autoreconf.
-include $(srcdir)/$(_build-aux)/syntax-check.mk
-
-ifeq ($(.DEFAULT_GOAL),abort-due-to-no-makefile)
-$(MAKECMDGOALS): abort-due-to-no-makefile
-endif
-
-abort-due-to-no-makefile:
-	@echo There seems to be no Makefile in this directory.   1>&2
-	@echo "You must run ./configure before running 'make'." 1>&2
-	@exit 1
-
-endif
-
-# Tell version 3.79 and up of GNU make to not build goals in this
-# directory in parallel, in case someone tries to build multiple
-# targets, and one of them can cause a recursive target to be invoked.
-
-# Only set this if Automake doesn't provide it.
-AM_RECURSIVE_TARGETS ?= $(RECURSIVE_TARGETS:-recursive=) \
-  $(RECURSIVE_CLEAN_TARGETS:-recursive=) \
-  dist distcheck tags ctags
-
-ALL_RECURSIVE_TARGETS += $(AM_RECURSIVE_TARGETS)
-
-ifneq ($(word 2, $(MAKECMDGOALS)), )
-ifneq ($(filter $(ALL_RECURSIVE_TARGETS), $(MAKECMDGOALS)), )
-.NOTPARALLEL:
-endif
-endif

Makefile.am

@@ -1,156 +0,0 @@
-## Process this file with automake to produce Makefile.in
-
-## Copyright (C) 2005-2013 Red Hat, Inc.
-##
-## This library is free software; you can redistribute it and/or
-## modify it under the terms of the GNU Lesser General Public
-## License as published by the Free Software Foundation; either
-## version 2.1 of the License, or (at your option) any later version.
-##
-## This library is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-## Lesser General Public License for more details.
-##
-## You should have received a copy of the GNU Lesser General Public
-## License along with this library.  If not, see
-## <http://www.gnu.org/licenses/>.
-
-LCOV = lcov
-GENHTML = genhtml
-
-# when building from tarball -Werror isn't auto enabled
-# so force it explicitly
-DISTCHECK_CONFIGURE_FLAGS = --enable-werror
-
-SUBDIRS = . gnulib/lib include/libvirt src tools docs gnulib/tests \
-  tests po examples
-
-XZ_OPT ?= -v -T0
-export XZ_OPT
-
-ACLOCAL_AMFLAGS = -I m4
-
-EXTRA_DIST = \
-  config-post.h \
-  libvirt.spec libvirt.spec.in \
-  mingw-libvirt.spec.in \
-  libvirt.pc.in \
-  libvirt-qemu.pc.in \
-  libvirt-lxc.pc.in \
-  libvirt-admin.pc.in \
-  Makefile.nonreentrant \
-  autogen.sh \
-  GNUmakefile \
-  run.in \
-  README.md \
-  AUTHORS.in \
-  scripts/apibuild.py \
-  scripts/augeas-gentest.py \
-  build-aux/check-spacing.pl \
-  scripts/check-aclperms.py \
-  scripts/check-aclrules.py \
-  scripts/check-drivername.py \
-  scripts/check-driverimpls.py \
-  scripts/check-file-access.py \
-  scripts/check-remote-protocol.py \
-  scripts/check-symfile.py \
-  scripts/check-symsorting.py \
-  scripts/dtrace2systemtap.py \
-  scripts/esx_vi_generator.py \
-  scripts/genaclperms.py \
-  scripts/genpolkit.py \
-  scripts/gensystemtap.py \
-  scripts/group-qemu-caps.py \
-  scripts/header-ifdef.py \
-  scripts/hvsupport.py \
-  scripts/hyperv_wmi_generator.py \
-  scripts/minimize-po.py \
-  scripts/mock-noinline.py \
-  scripts/prohibit-duplicate-header.py \
-  scripts/reformat-news.py \
-  scripts/test-wrap-argv.py \
-  build-aux/syntax-check.mk \
-  build-aux/useless-if-before-free \
-  build-aux/vc-list-files \
-  ci/Makefile \
-  ci/build.sh \
-  ci/list-images.sh \
-  ci/prepare.sh \
-  $(NULL)
-
-pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = libvirt.pc libvirt-qemu.pc libvirt-lxc.pc libvirt-admin.pc
-
-NEWS: \
-	  $(srcdir)/docs/news.xml \
-	  $(srcdir)/docs/news-ascii.xsl \
-	  $(top_srcdir)/scripts/reformat-news.py
-	$(AM_V_GEN) \
-	if [ -x $(XSLTPROC) ]; then \
-	  $(XSLTPROC) --nonet \
-	    $(srcdir)/docs/news-ascii.xsl \
-	    $(srcdir)/docs/news.xml \
-	  >$@-tmp \
-	    || { rm -f $@-tmp; exit 1; }; \
-	  $(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/reformat-news.py $@-tmp >$@ \
-	    || { rm -f $@-tmp; exit 1; }; \
-	  rm -f $@-tmp; \
-	fi
-EXTRA_DIST += \
-	$(srcdir)/docs/news.xml \
-	$(srcdir)/docs/news-ascii.xsl \
-	$(NULL)
-
-rpm: clean
-	@(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.xz)
-
-srpm: clean
-	@(unset CDPATH ; $(MAKE) dist && rpmbuild -ts $(distdir).tar.xz)
-
-check-local: all tests
-
-check-access: all
-	@($(MAKE) $(AM_MAKEFLAGS) -C tests check-access)
-
-cov: clean-cov
-	$(MKDIR_P) $(top_builddir)/coverage
-	$(LCOV) -c -o $(top_builddir)/coverage/libvirt.info.tmp \
-	  -d $(top_builddir)/src \
-	  -d $(top_builddir)/tests
-	$(LCOV) -r $(top_builddir)/coverage/libvirt.info.tmp \
-	  -o $(top_builddir)/coverage/libvirt.info
-	rm $(top_builddir)/coverage/libvirt.info.tmp
-	$(GENHTML) --show-details -t "libvirt" -o $(top_builddir)/coverage \
-	  --legend $(top_builddir)/coverage/libvirt.info
-
-clean-cov:
-	rm -rf $(top_builddir)/coverage
-
-MAINTAINERCLEANFILES = .git-module-status
-
-distclean-local: clean-GNUmakefile
-clean-GNUmakefile:
-	test '$(srcdir)' = . || rm -f $(top_builddir)/GNUmakefile
-
-dist-hook: gen-AUTHORS
-
-.PHONY: gen-AUTHORS
-gen-AUTHORS:
-	$(AM_V_GEN)\
-	if test -d $(srcdir)/.git; then \
-	  ( \
-	    cd $(srcdir) && \
-	    git log --pretty=format:'%aN <%aE>' | sort -u \
-	  ) > all.list && \
-	  sort -u $(srcdir)/AUTHORS.in > maint.list && \
-	  comm -23 all.list maint.list > contrib.list && \
-	  contrib="`cat contrib.list`" && \
-	  perl -p -e "s/#contributorslist#// and print '$$contrib'" \
-	    < $(srcdir)/AUTHORS.in > $(distdir)/AUTHORS-tmp && \
-	  mv -f $(distdir)/AUTHORS-tmp $(distdir)/AUTHORS && \
-	  rm -f all.list maint.list contrib.list; \
-	fi
-
-ci-%:
-	$(MAKE) -C $(srcdir)/ci/ $@

Makefile.nonreentrant

@@ -1,127 +0,0 @@
-## Copyright (C) 2009-2010, 2013 Red Hat, Inc.
-##
-## This library is free software; you can redistribute it and/or
-## modify it under the terms of the GNU Lesser General Public
-## License as published by the Free Software Foundation; either
-## version 2.1 of the License, or (at your option) any later version.
-##
-## This library is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-## Lesser General Public License for more details.
-##
-## You should have received a copy of the GNU Lesser General Public
-## License along with this library.  If not, see
-## <http://www.gnu.org/licenses/>.
-
-#
-# Generated by running the following on Fedora 26:
-#
-#  nm -D --defined-only /lib64/libc.so.6 \
-#      | grep '_r$' \
-#      | awk '{print $3}' \
-#      | grep -v __ \
-#      | grep -v qsort \ # Red herring since we don't need to pass extra args to qsort comparator
-#      | grep -v readdir \ # This is safe as long as each DIR * instance is only used by one thread
-#      | sort \
-#      | uniq \
-#      | sed -e 's/_r//'
-#
-# Also manually add in all inet_* functions some of which
-# are not threadsafe and do not have _r variants. They are
-# all deprecated in favour of getnameinfo/getaddrinfo
-#
-
-NON_REENTRANT =
-NON_REENTRANT += asctime
-NON_REENTRANT += ctime
-NON_REENTRANT += drand48
-NON_REENTRANT += ecvt
-NON_REENTRANT += erand48
-NON_REENTRANT += ether_aton
-NON_REENTRANT += ether_ntoa
-NON_REENTRANT += fcvt
-NON_REENTRANT += fgetgrent
-NON_REENTRANT += fgetpwent
-NON_REENTRANT += fgetsgent
-NON_REENTRANT += fgetspent
-NON_REENTRANT += getaliasbyname
-NON_REENTRANT += getaliasent
-NON_REENTRANT += getdate
-NON_REENTRANT += getgrent
-NON_REENTRANT += getgrgid
-NON_REENTRANT += getgrnam
-NON_REENTRANT += gethostbyaddr
-NON_REENTRANT += gethostbyname2
-NON_REENTRANT += gethostbyname
-NON_REENTRANT += gethostent
-NON_REENTRANT += getlogin
-NON_REENTRANT += getmntent
-NON_REENTRANT += getnetbyaddr
-NON_REENTRANT += getnetbyname
-NON_REENTRANT += getnetent
-NON_REENTRANT += getnetgrent
-NON_REENTRANT += getprotobyname
-NON_REENTRANT += getprotobynumber
-NON_REENTRANT += getprotoent
-NON_REENTRANT += getpwent
-NON_REENTRANT += getpwnam
-NON_REENTRANT += getpwuid
-NON_REENTRANT += getrpcbyname
-NON_REENTRANT += getrpcbynumber
-NON_REENTRANT += getrpcent
-NON_REENTRANT += getservbyname
-NON_REENTRANT += getservbyport
-NON_REENTRANT += getservent
-NON_REENTRANT += getsgent
-NON_REENTRANT += getsgnam
-NON_REENTRANT += getspent
-NON_REENTRANT += getspnam
-NON_REENTRANT += getutent
-NON_REENTRANT += getutid
-NON_REENTRANT += getutline
-NON_REENTRANT += gmtime
-NON_REENTRANT += hcreate
-NON_REENTRANT += hdestroy
-NON_REENTRANT += hsearch
-NON_REENTRANT += initstate
-NON_REENTRANT += jrand48
-NON_REENTRANT += lcong48
-NON_REENTRANT += localtime
-NON_REENTRANT += lrand48
-NON_REENTRANT += mrand48
-NON_REENTRANT += nrand48
-NON_REENTRANT += ptsname
-NON_REENTRANT += qecvt
-NON_REENTRANT += qfcvt
-NON_REENTRANT += random
-NON_REENTRANT += rand
-NON_REENTRANT += seed48
-NON_REENTRANT += setstate
-NON_REENTRANT += sgetsgent
-NON_REENTRANT += sgetspent
-NON_REENTRANT += srand48
-NON_REENTRANT += srandom
-NON_REENTRANT += strerror
-NON_REENTRANT += strtok
-NON_REENTRANT += tmpnam
-NON_REENTRANT += ttyname
-NON_REENTRANT += inet_addr
-NON_REENTRANT += inet_aton
-NON_REENTRANT += inet_lnaof
-NON_REENTRANT += inet_makeaddr
-NON_REENTRANT += inet_netof
-NON_REENTRANT += inet_network
-NON_REENTRANT += inet_nsap_addr
-NON_REENTRANT += inet_nsap_ntoa
-NON_REENTRANT += inet_ntoa
-NON_REENTRANT += inet_ntop
-NON_REENTRANT += inet_pton
-
-# Separate two nothings by space to get one space in a variable
-space =
-space +=
-# The space needs to be in a variable otherwise it would be ignored.
-# And there must be no spaces around the commas because they would
-# not be ignored, logically.
-NON_REENTRANT_RE=$(subst $(space),|,$(NON_REENTRANT))

README

@@ -1 +0,0 @@
-README.md

README

@@ -0,0 +1 @@
+This branch is no longer maintained upstream.

README-hacking

@@ -1,63 +0,0 @@
--*- outline -*-
-
-These notes intend to help people working on the checked-out sources.
-These requirements do not apply when building from a distribution tarball.
-See also docs/hacking.html (after building libvirt using the information
-included in this file) for more detailed contribution guidelines.
-
-* Requirements
-
-We've opted to keep only the highest-level sources in the GIT repository.
-This eases our maintenance burden, (fewer merges etc.), but imposes more
-requirements on anyone wishing to build from the just-checked-out sources.
-Note the requirements to build the released archive are much less and
-are just the requirements of the standard configure && make procedure.
-Specific development tools and versions will be checked for and listed by
-the bootstrap script.
-
-Valgrind <http://valgrind.org/> is also highly recommended, if
-Valgrind supports your architecture.
-
-While building from a just-cloned source tree may require installing a
-few prerequisites, later, a plain `git pull && make' should be sufficient.
-
-* First GIT checkout
-
-You can get a copy of the source repository like this:
-
-        $ git clone https://libvirt.org/git/libvirt.git
-        $ cd libvirt
-
-As an optional step, if you already have a copy of the gnulib git
-repository on your hard drive, then you can use it as a reference to
-reduce download time and disk space requirements:
-
-        $ export GNULIB_SRCDIR=/path/to/gnulib
-
-We require to have the build directory different than the source directory:
-
-        $ mkdir build && cd build
-
-The next step is to get all required pieces from gnulib,
-to run autoreconf, and to invoke ../autogen.sh:
-
-        $ ../autogen.sh
-
-And there you are!  Just
-
-        $ make
-        $ make check
-
-At this point, there should be no difference between your local copy,
-and the GIT master copy:
-
-        $ cd ..
-        $ git diff
-
-should output no difference.
-
-Enjoy!
-
-Local Variables:
-indent-tabs-mode: nil
-End:

README.md

@@ -1,86 +0,0 @@
-[![Build Status](https://travis-ci.org/libvirt/libvirt.svg)](https://travis-ci.org/libvirt/libvirt)
- [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/355/badge)](https://bestpractices.coreinfrastructure.org/projects/355)
-
-Libvirt API for virtualization
-==============================
-
-Libvirt provides a portable, long term stable C API for managing the
-virtualization technologies provided by many operating systems. It
-includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
-vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
-Hypervisor.
-
-For some of these hypervisors, it provides a stateful management
-daemon which runs on the virtualization host allowing access to the
-API both by non-privileged local users and remote users.
-
-Layered packages provide bindings of the libvirt C API into other
-languages including Python, Perl, PHP, Go, Java, OCaml, as well as
-mappings into object systems such as GObject, CIM and SNMP.
-
-Further information about the libvirt project can be found on the
-website:
-
-[https://libvirt.org](https://libvirt.org)
-
-
-License
--------
-
-The libvirt C API is distributed under the terms of GNU Lesser General
-Public License, version 2.1 (or later). Some parts of the code that are
-not part of the C library may have the more restrictive GNU General
-Public License, version 2.0 (or later). See the files `COPYING.LESSER`
-and `COPYING` for full license terms & conditions.
-
-
-Installation
-------------
-
-Libvirt uses the GNU Autotools build system, so in general can be built
-and installed with the usual commands, however, we mandate to have the
-build directory different than the source directory. For example, to build
-in a manner that is suitable for installing as root, use:
-
-```
-$ mkdir build && cd build
-$ ../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
-$ make
-$ sudo make install
-```
-
-While to build & install as an unprivileged user
-
-```
-$ mkdir build && cd build
-$ ../configure --prefix=$HOME/usr
-$ make
-$ make install
-```
-
-The libvirt code relies on a large number of 3rd party libraries. These will
-be detected during execution of the `configure` script and a summary printed
-which lists any missing (optional) dependencies.
-
-
-Contributing
-------------
-
-The libvirt project welcomes contributions in many ways. For most components
-the best way to contribute is to send patches to the primary development
-mailing list. Further guidance on this can be found on the website:
-
-[https://libvirt.org/contribute.html](https://libvirt.org/contribute.html)
-
-
-Contact
--------
-
-The libvirt project has two primary mailing lists:
-
-  * libvirt-users@redhat.com (**for user discussions**)
-  * libvir-list@redhat.com (**for development only**)
-
-Further details on contacting the project are available on the website:
-
-[https://libvirt.org/contact.html](https://libvirt.org/contact.html)

autogen.sh

@@ -1,208 +0,0 @@
-#!/bin/sh
-# Run this to generate all the initial makefiles, etc.
-
-die()
-{
-    echo "error: $1" >&2
-    exit 1
-}
-
-starting_point=$(pwd)
-
-srcdir=$(dirname "$0")
-test "$srcdir" || srcdir=.
-
-cd "$srcdir" || {
-    die "Failed to cd into $srcdir"
-}
-
-test -f src/libvirt.c || {
-    die "$0 must live in the top-level libvirt directory"
-}
-
-dry_run=
-no_git=
-gnulib_srcdir=
-extra_args=
-while test "$#" -gt 0; do
-    case "$1" in
-    --dry-run)
-        # This variable will serve both as an indicator of the fact that
-        # a dry run has been requested, and to store the result of the
-        # dry run. It will be ultimately used as return code for the
-        # script: 0 means no action is necessary, 2 means that autogen.sh
-        # needs to be executed, and 1 is reserved for failures
-        dry_run=0
-        shift
-        ;;
-    --no-git)
-        no_git=" $1"
-        shift
-        ;;
-    --gnulib-srcdir=*)
-        gnulib_srcdir=" $1"
-        shift
-        ;;
-    --gnulib-srcdir)
-        gnulib_srcdir=" $1=$2"
-        shift
-        shift
-        ;;
-    --system)
-        prefix=/usr
-        sysconfdir=/etc
-        localstatedir=/var
-        if test -d $prefix/lib64; then
-            libdir=$prefix/lib64
-        else
-            libdir=$prefix/lib
-        fi
-        extra_args="--prefix=$prefix --localstatedir=$localstatedir"
-        extra_args="$extra_args --sysconfdir=$sysconfdir --libdir=$libdir"
-        shift
-        ;;
-    *)
-        # All remaining arguments will be passed to configure verbatim
-        break
-        ;;
-    esac
-done
-no_git="$no_git$gnulib_srcdir"
-
-gnulib_hash()
-{
-    local no_git=$1
-
-    if test "$no_git"; then
-        echo "no-git"
-        return
-    fi
-
-    # Compute the hash we'll use to determine whether rerunning bootstrap
-    # is required. The first is just the SHA1 that selects a gnulib snapshot.
-    # The second ensures that whenever we change the set of gnulib modules used
-    # by this package, we rerun bootstrap to pull in the matching set of files.
-    # The third ensures that whenever we change the set of local gnulib diffs,
-    # we rerun bootstrap to pull in those diffs.
-    git submodule status .gnulib | awk '{ print $1 }'
-    git hash-object bootstrap.conf
-    git ls-tree -d HEAD gnulib/local | awk '{ print $3 }'
-}
-
-# Only look into git submodules if we're in a git checkout
-if test -d .git || test -f .git; then
-
-    # Check for dirty submodules
-    if test -z "$CLEAN_SUBMODULE"; then
-        for path in $(git submodule status | awk '{ print $2 }'); do
-            case "$(git diff "$path")" in
-                *-dirty*)
-                    echo "error: $path is dirty, please investigate" >&2
-                    echo "set CLEAN_SUBMODULE to discard submodule changes" >&2
-                    exit 1
-                    ;;
-            esac
-        done
-    fi
-    if test "$CLEAN_SUBMODULE" && test -z "$no_git"; then
-        if test -z "$dry_run"; then
-            echo "Cleaning up submodules..."
-            git submodule foreach 'git clean -dfqx && git reset --hard' || {
-                die "Cleaning up submodules failed"
-            }
-        fi
-    fi
-
-    # Update all submodules. If any of the submodules has not been
-    # initialized yet, it will be initialized now; moreover, any submodule
-    # with uncommitted changes will be returned to the expected state
-    echo "Updating submodules..."
-    git submodule update --init || {
-        die "Updating submodules failed"
-    }
-
-    # The expected hash, eg. the one computed after the last
-    # successful bootstrap run, is stored on disk
-    state_file=.git-module-status
-    expected_hash=$(cat "$state_file" 2>/dev/null)
-    actual_hash=$(gnulib_hash "$no_git")
-
-    if test "$actual_hash" = "$expected_hash" && test -f AUTHORS; then
-        # The gnulib hash matches our expectations, and all the files
-        # that can only be generated through bootstrap are present:
-        # we just need to run autoreconf. Unless we're performing a
-        # dry run, of course...
-        if test -z "$dry_run"; then
-            echo "Running autoreconf..."
-            autoreconf -if || {
-                die "autoreconf failed"
-            }
-        fi
-    else
-        # Whenever the gnulib submodule or any of the related bits
-        # has been changed in some way (see gnulib_hash) we need to
-        # run bootstrap again. If we're performing a dry run, we
-        # change the return code instead to signal our caller
-        if test "$dry_run"; then
-            dry_run=2
-        else
-            echo "Running bootstrap..."
-            ./bootstrap$no_git --bootstrap-sync || {
-                die "bootstrap failed"
-            }
-            gnulib_hash >"$state_file"
-        fi
-    fi
-fi
-
-# When performing a dry run, we can stop here
-test "$dry_run" && exit "$dry_run"
-
-# If asked not to run configure, we can stop here
-test "$NOCONFIGURE" && exit 0
-
-cd "$starting_point" || {
-    die "Failed to cd into $starting_point"
-}
-
-if test "$OBJ_DIR"; then
-    mkdir -p "$OBJ_DIR" || {
-        die "Failed to create $OBJ_DIR"
-    }
-    cd "$OBJ_DIR" || {
-        die "Failed to cd into $OBJ_DIR"
-    }
-fi
-
-# Make sure we can find GNU make and tell the user
-# the right command to run
-MAKE=
-for cmd in make gmake; do
-    if $cmd -v 2>&1 | grep -q "GNU Make"; then
-        MAKE=$cmd
-        break
-    fi
-done
-test "$MAKE" || {
-    die "GNU make is required to build libvirt"
-}
-
-if test -z "$*" && test -z "$extra_args" && test -f config.status; then
-    echo "Running config.status..."
-    ./config.status --recheck || {
-        die "config.status failed"
-    }
-else
-    if test -z "$*" && test -z "$extra_args"; then
-        echo "I am going to run configure with no arguments - if you wish"
-        echo "to pass any to it, please specify them on the $0 command line."
-    else
-        echo "Running configure with $extra_args $@"
-    fi
-    "$srcdir/configure" $extra_args "$@" || {
-        die "configure failed"
-    }
-fi
-
-echo
-echo "Now type '$MAKE' to compile libvirt."

bootstrap.conf

@@ -1,201 +0,0 @@
-# Bootstrap configuration.
-
-# Copyright (C) 2010-2014 Red Hat, Inc.
-
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU Lesser General Public License for more details.
-
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library.  If not, see
-# <http://www.gnu.org/licenses/>.
-
-# gnulib modules used by this package.
-
-# NB the GSocket conversion is non-trivial due to the
-# different FD vs HANDLE usage in gnulib vs glib. Need
-# to find a way to duplicate a socket HANDLE before
-# turning it into a FD, since closing an FD also closes
-# the original HANDLE.
-
-# -> GSocket
-gnulib_modules="$gnulib_modules accept"
-# -> GSocket
-gnulib_modules="$gnulib_modules bind"
-# -> conditional build to avoid Win32
-gnulib_modules="$gnulib_modules chown"
-# -> GSocket
-gnulib_modules="$gnulib_modules close"
-# -> GSocket
-gnulib_modules="$gnulib_modules connect"
-# -> Meson
-gnulib_modules="$gnulib_modules configmake"
-# -> eliminate usage in some manner
-gnulib_modules="$gnulib_modules environ"
-# -> GSocket
-gnulib_modules="$gnulib_modules fcntl"
-# -> conditional build avoid win32
-gnulib_modules="$gnulib_modules fcntl-h"
-# -> GSocket
-gnulib_modules="$gnulib_modules getaddrinfo"
-# -> copy gnuliub win32 impl
-gnulib_modules="$gnulib_modules getpass"
-# -> GSocket
-gnulib_modules="$gnulib_modules getpeername"
-# -> GSocket
-gnulib_modules="$gnulib_modules getsockname"
-# -> copy gnulib STRBUFLEN macro
-gnulib_modules="$gnulib_modules intprops"
-# -> GSocket
-gnulib_modules="$gnulib_modules ioctl"
-# -> Meson
-gnulib_modules="$gnulib_modules largefile"
-# -> GSocket
-gnulib_modules="$gnulib_modules listen"
-# -> custom configure check
-gnulib_modules="$gnulib_modules localeconv"
-# -> Meson
-gnulib_modules="$gnulib_modules manywarnings"
-# -> painful copy gnulib
-gnulib_modules="$gnulib_modules mgetgroups"
-# -> GSocket
-gnulib_modules="$gnulib_modules net_if"
-# -> GSocket
-gnulib_modules="$gnulib_modules netdb"
-# -> GSocket
-gnulib_modules="$gnulib_modules nonblocking"
-# -> Just add -lutil to cli
-gnulib_modules="$gnulib_modules openpty"
-# -> GSocket
-gnulib_modules="$gnulib_modules passfd"
-# -> open code / copy gnulib code
-gnulib_modules="$gnulib_modules physmem"
-# -> open code / conditional comp
-gnulib_modules="$gnulib_modules pipe-posix"
-# -> open code / conditional comp
-gnulib_modules="$gnulib_modules pipe2"
-# -> GMainLoop
-gnulib_modules="$gnulib_modules poll"
-# -> Meson
-gnulib_modules="$gnulib_modules posix-shell"
-# -> open code conditional logic
-gnulib_modules="$gnulib_modules pthread_sigmask"
-# -> GSocket
-gnulib_modules="$gnulib_modules recv"
-# -> GSocket
-gnulib_modules="$gnulib_modules send"
-# -> GSocket
-gnulib_modules="$gnulib_modules setsockopt"
-# -> open code conditional logic
-gnulib_modules="$gnulib_modules sigaction"
-# -> open code conditional logic
-gnulib_modules="$gnulib_modules sigpipe"
-# -> GSocket
-gnulib_modules="$gnulib_modules socket"
-# -> open code conditional or use GIO GFileInfo
-gnulib_modules="$gnulib_modules stat-time"
-# -> remove use or open-code it. possibly add to glib
-gnulib_modules="$gnulib_modules strchrnul"
-# -> g_strsplit
-gnulib_modules="$gnulib_modules strtok_r"
-# -> remove sys/stat.h include from any win32 code paths
-gnulib_modules="$gnulib_modules sys_stat"
-# -> remove sys/wait.h include from any win32 code paths
-gnulib_modules="$gnulib_modules sys_wait"
-# -> remove from any win32 code paths
-gnulib_modules="$gnulib_modules termios"
-# -> GDateTime ?
-gnulib_modules="$gnulib_modules time_r"
-# -> obsolete - exists on Linux, MacOS >= ?? & FreeBSD >= 6
-gnulib_modules="$gnulib_modules ttyname_r"
-# -> g_get_os_info in GLib 2.64 but can't use that yet
-gnulib_modules="$gnulib_modules uname"
-# -> G_STATIC_ASSERT
-gnulib_modules="$gnulib_modules verify"
-# -> remove from Win32 code paths
-gnulib_modules="$gnulib_modules waitpid"
-# -> Meson
-gnulib_modules="$gnulib_modules warnings"
-# -> open code impl
-gnulib_modules="$gnulib_modules wcwidth"
-
-SKIP_PO=true
-
-# Enable copy-mode for MSYS/MinGW. MSYS' ln doesn't work well in the way
-# bootstrap uses it with relative paths.
-if test -n "$MSYSTEM"; then
-    copy=true
-fi
-
-
-# Tell gnulib to:
-#   require LGPLv2+
-#   apply any local diffs in gnulib/local/ dir
-#   put *.m4 files in m4/ dir
-#   put *.[ch] files in new gnulib/lib/ dir
-#   import gnulib tests in new gnulib/tests/ dir
-gnulib_name=libgnu
-m4_base=m4
-source_base=gnulib/lib
-tests_base=gnulib/tests
-gnulib_tool_option_extras="\
- --lgpl=2\
- --with-tests\
- --makefile-name=gnulib.mk\
- --avoid=pt_chown\
- --avoid=lock-tests\
-"
-local_gl_dir=gnulib/local
-
-# Build prerequisites
-# Note that some of these programs are only required for 'make dist' to
-# succeed from a fresh git checkout; not all of these programs are
-# required to run 'make dist' on a tarball.
-buildreq="\
-autoconf   2.59
-automake   1.9.6
-git        1.5.5
-gzip       -
-libtool    -
-patch      -
-perl       5.5
-pkg-config -
-rpcgen     -
-tar        -
-xmllint	   -
-xsltproc   -
-"
-
-# Automake requires that AUTHORS exist.
-touch AUTHORS || exit 1
-
-# Override bootstrap's list - we don't use mdate-sh or texinfo.tex.
-gnulib_extra_files="
-        build-aux/install-sh
-        build-aux/depcomp
-        build-aux/config.guess
-        build-aux/config.sub
-        doc/INSTALL
-"
-
-
-bootstrap_post_import_hook()
-{
-  # Change paths in gnulib/tests/gnulib.mk from "../../.." to "../..",
-  # and make tests conditional by changing "TESTS" to "GNULIB_TESTS".
-  m=gnulib/tests/gnulib.mk
-  sed 's,\.\./\.\./\.\.,../..,g; s/^TESTS /GNULIB_TESTS /' $m > $m-t
-  mv -f $m-t $m
-}
-
-bootstrap_epilogue()
-{
-    echo "$0: done.  Now you can run 'mkdir build && cd build && ../configure'."
-    exit 0
-}

build-aux/check-spacing.pl

@@ -1,198 +0,0 @@
-#!/usr/bin/env perl
-#
-# check-spacing.pl: Report any usage of 'function (..args..)'
-# Also check for other syntax issues, such as correct use of ';'
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library.  If not, see
-# <http://www.gnu.org/licenses/>.
-
-use strict;
-use warnings;
-
-my $ret = 0;
-my $incomment = 0;
-
-foreach my $file (@ARGV) {
-    # Per-file variables for multiline Curly Bracket (cb_) check
-    my $cb_linenum = 0;
-    my $cb_code = "";
-    my $cb_scolon = 0;
-
-    open FILE, $file;
-
-    while (defined (my $line = <FILE>)) {
-        my $data = $line;
-        # For temporary modifications
-        my $tmpdata;
-
-        # Kill any quoted , ; = or "
-        $data =~ s/'[";,=]'/'X'/g;
-
-        # Kill any quoted strings
-        $data =~ s,"(?:[^\\\"]|\\.)*","XXX",g;
-
-        next if $data =~ /^#/;
-
-        # Kill contents of multi-line comments
-        # and detect end of multi-line comments
-        if ($incomment) {
-            if ($data =~ m,\*/,) {
-                $incomment = 0;
-                $data =~ s,^.*\*/,*/,;
-            } else {
-                $data = "";
-            }
-        }
-
-        # Kill single line comments, and detect
-        # start of multi-line comments
-        if ($data =~ m,/\*.*\*/,) {
-            $data =~ s,/\*.*\*/,/* */,;
-        } elsif ($data =~ m,/\*,) {
-            $incomment = 1;
-            $data =~ s,/\*.*,/*,;
-        }
-
-        # We need to match things like
-        #
-        #  int foo (int bar, bool wizz);
-        #  foo (bar, wizz);
-        #
-        # but not match things like:
-        #
-        #  typedef int (*foo)(bar wizz)
-        #
-        # we can't do this (efficiently) without
-        # missing things like
-        #
-        #  foo (*bar, wizz);
-        #
-        # We also don't want to spoil the $data so it can be used
-        # later on.
-        $tmpdata = $data;
-        while ($tmpdata =~ /(\w+)\s\((?!\*)/) {
-            my $kw = $1;
-
-            # Allow space after keywords only
-            if ($kw =~ /^(?:if|for|while|switch|return)$/) {
-                $tmpdata =~ s/(?:$kw\s\()/XXX(/;
-            } else {
-                print "Whitespace after non-keyword:\n";
-                print "$file:$.: $line";
-                $ret = 1;
-                last;
-            }
-        }
-
-        # Require whitespace immediately after keywords
-        if ($data =~ /\b(?:if|for|while|switch|return)\(/) {
-            print "No whitespace after keyword:\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # Forbid whitespace between )( of a function typedef
-        if ($data =~ /\(\*\w+\)\s+\(/) {
-            print "Whitespace between ')' and '(':\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # Forbid whitespace following ( or prior to )
-        # but allow whitespace before ) on a single line
-        # (optionally followed by a semicolon)
-        if (($data =~ /\s\)/ && not $data =~ /^\s+\);?$/) ||
-            $data =~ /\((?!$)\s/) {
-            print "Whitespace after '(' or before ')':\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # Forbid whitespace before ";" or ",". Things like below are allowed:
-        #
-        # 1) The expression is empty for "for" loop. E.g.
-        #   for (i = 0; ; i++)
-        #
-        # 2) An empty statement. E.g.
-        #   while (write(statuswrite, &status, 1) == -1 &&
-        #          errno == EINTR)
-        #       ;
-        #
-        if ($data =~ /\s[;,]/) {
-            unless ($data =~ /\S; ; / ||
-                    $data =~ /^\s+;/) {
-                print "Whitespace before semicolon or comma:\n";
-                print "$file:$.: $line";
-                $ret = 1;
-            }
-        }
-
-        # Require EOL, macro line continuation, or whitespace after ";".
-        # Allow "for (;;)" as an exception.
-        if ($data =~ /;[^	 \\\n;)]/) {
-            print "Invalid character after semicolon:\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # Require EOL, space, or enum/struct end after comma.
-        if ($data =~ /,[^ \\\n)}]/) {
-            print "Invalid character after comma:\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # Require spaces around assignment '=', compounds and '=='
-        if ($data =~ /[^ ]\b[!<>&|\-+*\/%\^=]?=/ ||
-            $data =~ /=[^= \\\n]/) {
-            print "Spacing around '=' or '==':\n";
-            print "$file:$.: $line";
-            $ret = 1;
-        }
-
-        # One line conditional statements with one line bodies should
-        # not use curly brackets.
-        if ($data =~ /^\s*(if|while|for)\b.*\{$/) {
-            $cb_linenum = $.;
-            $cb_code = $line;
-            $cb_scolon = 0;
-        }
-
-        # We need to check for exactly one semicolon inside the body,
-        # because empty statements (e.g. with comment only) are
-        # allowed
-        if ($cb_linenum == $. - 1 && $data =~ /^[^;]*;[^;]*$/) {
-            $cb_code .= $line;
-            $cb_scolon = 1;
-        }
-
-        if ($data =~ /^\s*}\s*$/ &&
-            $cb_linenum == $. - 2 &&
-            $cb_scolon) {
-
-            print "Curly brackets around single-line body:\n";
-            print "$file:$cb_linenum-$.:\n$cb_code$line";
-            $ret = 1;
-
-            # There _should_ be no need to reset the values; but to
-            # keep my inner peace...
-            $cb_linenum = 0;
-            $cb_scolon = 0;
-            $cb_code = "";
-        }
-    }
-    close FILE;
-}
-
-exit $ret;

build-aux/useless-if-before-free

@@ -1,226 +0,0 @@
-#!/bin/sh
-#! -*-perl-*-
-
-# Detect instances of "if (p) free (p);".
-# Likewise "if (p != 0)", "if (0 != p)", or with NULL; and with braces.
-
-# Copyright (C) 2008-2019 Free Software Foundation, Inc.
-#
-# This program is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <https://www.gnu.org/licenses/>.
-#
-# Written by Jim Meyering
-
-# This is a prologue that allows to run a perl script as an executable
-# on systems that are compliant to a POSIX version before POSIX:2017.
-# On such systems, the usual invocation of an executable through execlp()
-# or execvp() fails with ENOEXEC if it is a script that does not start
-# with a #! line.  The script interpreter mentioned in the #! line has
-# to be /bin/sh, because on GuixSD systems that is the only program that
-# has a fixed file name.  The second line is essential for perl and is
-# also useful for editing this file in Emacs.  The next two lines below
-# are valid code in both sh and perl.  When executed by sh, they re-execute
-# the script through the perl program found in $PATH.  The '-x' option
-# is essential as well; without it, perl would re-execute the script
-# through /bin/sh.  When executed by  perl, the next two lines are a no-op.
-eval 'exec perl -wSx "$0" "$@"'
-     if 0;
-
-my $VERSION = '2018-03-07 03:47'; # UTC
-# The definition above must lie within the first 8 lines in order
-# for the Emacs time-stamp write hook (at end) to update it.
-# If you change this file with Emacs, please let the write hook
-# do its job.  Otherwise, update this string manually.
-
-use strict;
-use warnings;
-use Getopt::Long;
-
-(my $ME = $0) =~ s|.*/||;
-
-# use File::Coda; # https://meyering.net/code/Coda/
-END {
-  defined fileno STDOUT or return;
-  close STDOUT and return;
-  warn "$ME: failed to close standard output: $!\n";
-  $? ||= 1;
-}
-
-sub usage ($)
-{
-  my ($exit_code) = @_;
-  my $STREAM = ($exit_code == 0 ? *STDOUT : *STDERR);
-  if ($exit_code != 0)
-    {
-      print $STREAM "Try '$ME --help' for more information.\n";
-    }
-  else
-    {
-      print $STREAM <<EOF;
-Usage: $ME [OPTIONS] FILE...
-
-Detect any instance in FILE of a useless "if" test before a free call, e.g.,
-"if (p) free (p);".  Any such test may be safely removed without affecting
-the semantics of the C code in FILE.  Use --name=FOO --name=BAR to also
-detect free-like functions named FOO and BAR.
-
-OPTIONS:
-
-   --list       print only the name of each matching FILE (\\0-terminated)
-   --name=N     add name N to the list of \'free\'-like functions to detect;
-                  may be repeated
-
-   --help       display this help and exit
-   --version    output version information and exit
-
-Exit status:
-
-  0   one or more matches
-  1   no match
-  2   an error
-
-EXAMPLE:
-
-For example, this command prints all removable "if" tests before "free"
-and "kfree" calls in the linux kernel sources:
-
-    git ls-files -z |xargs -0 $ME --name=kfree
-
-EOF
-    }
-  exit $exit_code;
-}
-
-sub is_NULL ($)
-{
-  my ($expr) = @_;
-  return ($expr eq 'NULL' || $expr eq '0');
-}
-
-{
-  sub EXIT_MATCH {0}
-  sub EXIT_NO_MATCH {1}
-  sub EXIT_ERROR {2}
-  my $err = EXIT_NO_MATCH;
-
-  my $list;
-  my @name = qw(free);
-  GetOptions
-    (
-     help => sub { usage 0 },
-     version => sub { print "$ME version $VERSION\n"; exit },
-     list => \$list,
-     'name=s@' => \@name,
-    ) or usage 1;
-
-  # Make sure we have the right number of non-option arguments.
-  # Always tell the user why we fail.
-  @ARGV < 1
-    and (warn "$ME: missing FILE argument\n"), usage EXIT_ERROR;
-
-  my $or = join '|', @name;
-  my $regexp = qr/(?:$or)/;
-
-  # Set the input record separator.
-  # Note: this makes it impractical to print line numbers.
-  $/ = '"';
-
-  my $found_match = 0;
- FILE:
-  foreach my $file (@ARGV)
-    {
-      open FH, '<', $file
-        or (warn "$ME: can't open '$file' for reading: $!\n"),
-          $err = EXIT_ERROR, next;
-      while (defined (my $line = <FH>))
-        {
-          # Skip non-matching lines early to save time
-          $line =~ /\bif\b/
-            or next;
-          while ($line =~
-              /\b(if\s*\(\s*([^)]+?)(?:\s*!=\s*([^)]+?))?\s*\)
-              #  1          2                  3
-               (?:   \s*$regexp\s*\((?:\s*\([^)]+\))?\s*([^)]+)\)\s*;|
-                \s*\{\s*$regexp\s*\((?:\s*\([^)]+\))?\s*([^)]+)\)\s*;\s*\}))/sxg)
-            {
-              my $all = $1;
-              my ($lhs, $rhs) = ($2, $3);
-              my ($free_opnd, $braced_free_opnd) = ($4, $5);
-              my $non_NULL;
-              if (!defined $rhs) { $non_NULL = $lhs }
-              elsif (is_NULL $rhs) { $non_NULL = $lhs }
-              elsif (is_NULL $lhs) { $non_NULL = $rhs }
-              else { next }
-
-              # Compare the non-NULL part of the "if" expression and the
-              # free'd expression, without regard to white space.
-              $non_NULL =~ tr/ \t//d;
-              my $e2 = defined $free_opnd ? $free_opnd : $braced_free_opnd;
-              $e2 =~ tr/ \t//d;
-              if ($non_NULL eq $e2)
-                {
-                  $found_match = 1;
-                  $list
-                    and (print "$file\0"), next FILE;
-                  print "$file: $all\n";
-                }
-            }
-        }
-    }
-  continue
-    {
-      close FH;
-    }
-
-  $found_match && $err == EXIT_NO_MATCH
-    and $err = EXIT_MATCH;
-
-  exit $err;
-}
-
-my $foo = <<'EOF';
-# The above is to *find* them.
-# This adjusts them, removing the unnecessary "if (p)" part.
-
-# FIXME: do something like this as an option (doesn't do braces):
-free=xfree
-git grep -l -z "$free *(" \
-  | xargs -0 useless-if-before-free -l --name="$free" \
-  | xargs -0 perl -0x3b -pi -e \
-   's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*(?:0|NULL))?\s*\)\s+('"$free"'\s*\((?:\s*\([^)]+\))?\s*\1\s*\)\s*;)/$2/s'
-
-# Use the following to remove redundant uses of kfree inside braces.
-# Note that -0777 puts perl in slurp-whole-file mode;
-# but we have plenty of memory, these days...
-free=kfree
-git grep -l -z "$free *(" \
-  | xargs -0 useless-if-before-free -l --name="$free" \
-  | xargs -0 perl -0777 -pi -e \
-     's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*(?:0|NULL))?\s*\)\s*\{\s*('"$free"'\s*\((?:\s*\([^)]+\))?\s*\1\s*\);)\s*\}[^\n]*$/$2/gms'
-
-Be careful that the result of the above transformation is valid.
-If the matched string is followed by "else", then obviously, it won't be.
-
-When modifying files, refuse to process anything other than a regular file.
-EOF
-
-## Local Variables:
-## mode: perl
-## indent-tabs-mode: nil
-## eval: (add-hook 'before-save-hook 'time-stamp)
-## time-stamp-line-limit: 50
-## time-stamp-start: "my $VERSION = '"
-## time-stamp-format: "%:y-%02m-%02d %02H:%02M"
-## time-stamp-time-zone: "UTC0"
-## time-stamp-end: "'; # UTC"
-## End:

build-aux/vc-list-files

@@ -1,113 +0,0 @@
-#!/bin/sh
-# List version-controlled file names.
-
-# Print a version string.
-scriptversion=2018-03-07.03; # UTC
-
-# Copyright (C) 2006-2019 Free Software Foundation, Inc.
-
-# This program is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <https://www.gnu.org/licenses/>.
-
-
-# List the specified version-controlled files.
-# With no argument, list them all.  With a single DIRECTORY argument,
-# list the version-controlled files in that directory.
-
-# If there's an argument, it must be a single, "."-relative directory name.
-# cvsu is part of the cvsutils package: http://www.red-bean.com/cvsutils/
-
-postprocess=
-case $1 in
-  --help) cat <<EOF
-Usage: $0 [-C SRCDIR] [DIR...]
-
-Output a list of version-controlled files in DIR (default .), relative to
-SRCDIR (default .).  SRCDIR must be the top directory of a checkout.
-
-Options:
-  --help     print this help, then exit
-  --version  print version number, then exit
-  -C SRCDIR  change directory to SRCDIR before generating list
-
-Report bugs and patches to <bug-gnulib@gnu.org>.
-EOF
-    exit ;;
-
-  --version)
-    year=`echo "$scriptversion" | sed 's/[^0-9].*//'`
-    cat <<EOF
-vc-list-files $scriptversion
-Copyright (C) $year Free Software Foundation, Inc,
-License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.
-EOF
-    exit ;;
-
-  -C)
-    test "$2" = . || postprocess="| sed 's|^|$2/|'"
-    cd "$2" || exit 1
-    shift; shift ;;
-esac
-
-test $# = 0 && set .
-
-for dir
-do
-  if test -d .git || test -f .git; then
-    test "x$dir" = x. \
-      && dir= sed_esc= \
-      || { dir="$dir/"; sed_esc=`echo "$dir"|env sed 's,\([\\/]\),\\\\\1,g'`; }
-    # Ignore git symlinks - either they point into the tree, in which case
-    # we don't need to visit the target twice, or they point somewhere
-    # else (often into a submodule), in which case the content does not
-    # belong to this package.
-    eval exec git ls-tree -r 'HEAD:"$dir"' \
-      \| sed -n '"s/^100[^	]*./$sed_esc/p"' $postprocess
-  elif test -d .hg; then
-    eval exec hg locate '"$dir/*"' $postprocess
-  elif test -d .bzr; then
-    test "$postprocess" = '' && postprocess="| sed 's|^\./||'"
-    eval exec bzr ls -R --versioned '"$dir"' $postprocess
-  elif test -d CVS; then
-    test "$postprocess" = '' && postprocess="| sed 's|^\./||'"
-    if test -x build-aux/cvsu; then
-      eval build-aux/cvsu --find --types=AFGM '"$dir"' $postprocess
-    elif (cvsu --help) >/dev/null 2>&1; then
-      eval cvsu --find --types=AFGM '"$dir"' $postprocess
-    else
-      eval awk -F/ \''{			\
-          if (!$1 && $3 !~ /^-/) {	\
-            f=FILENAME;			\
-            if (f ~ /CVS\/Entries$/)	\
-              f = substr(f, 1, length(f)-11); \
-            print f $2;			\
-          }}'\''				\
-        `find "$dir" -name Entries -print` /dev/null' $postprocess
-    fi
-  elif test -d .svn; then
-    eval exec svn list -R '"$dir"' $postprocess
-  else
-    echo "$0: Failed to determine type of version control used in `pwd`" 1>&2
-    exit 1
-  fi
-done
-
-# Local variables:
-# eval: (add-hook 'before-save-hook 'time-stamp)
-# time-stamp-start: "scriptversion="
-# time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC0"
-# time-stamp-end: "; # UTC"
-# End:

ci/Makefile

@@ -1,268 +0,0 @@
-# -*- makefile -*-
-# vim: filetype=make
-
-# The root directory of the libvirt.git checkout
-CI_GIT_ROOT = $(shell git rev-parse --show-toplevel)
-
-# The root directory for all CI-related contents
-CI_ROOTDIR = $(CI_GIT_ROOT)/ci
-
-# The directory holding content on the host that we will
-# expose to the container.
-CI_SCRATCHDIR = $(CI_ROOTDIR)/scratch
-
-# The directory holding the clone of the git repo that
-# we will expose to the container
-CI_HOST_SRCDIR = $(CI_SCRATCHDIR)/src
-
-# The directory holding the source inside the
-# container, i.e. where we want to expose
-# the $(CI_HOST_SRCDIR) directory from the host
-CI_CONT_SRCDIR = $(CI_USER_HOME)/libvirt
-
-# Relative directory to perform the build in. This
-# defaults to using a separate build dir, but can be
-# set to empty string for an in-source tree build.
-CI_VPATH = build
-
-# The directory holding the build output inside the
-# container.
-CI_CONT_BUILDDIR = $(CI_CONT_SRCDIR)/$(CI_VPATH)
-
-# Can be overridden with mingw{32,64}-configure if desired
-CI_CONFIGURE = $(CI_CONT_SRCDIR)/configure
-
-# Default to using all possible CPUs
-CI_SMP = $(shell getconf _NPROCESSORS_ONLN)
-
-# Any extra arguments to pass to make
-CI_MAKE_ARGS =
-
-# Any extra arguments to pass to configure
-CI_CONFIGURE_ARGS =
-
-# Script containing environment preparation steps
-CI_PREPARE_SCRIPT = $(CI_ROOTDIR)/prepare.sh
-
-# Script containing build instructions
-CI_BUILD_SCRIPT = $(CI_ROOTDIR)/build.sh
-
-# Location of the container images we're going to pull
-# Can be useful to overridde to use a locally built
-# image instead
-CI_IMAGE_PREFIX = quay.io/libvirt/buildenv-libvirt-
-
-# The default tag is ':latest' but if the container
-# repo above uses different conventions this can override it
-CI_IMAGE_TAG = :latest
-
-# We delete the virtual root after completion, set
-# to 0 if you need to keep it around for debugging
-CI_CLEAN = 1
-
-# We'll always freshly clone the virtual root each
-# time in case it was not cleaned up before. Set
-# to 1 if you want to try restarting a previously
-# preserved env
-CI_REUSE = 0
-
-# We need the container process to run with current host IDs
-# so that it can access the passed in build directory
-CI_UID = $(shell id -u)
-CI_GID = $(shell id -g)
-
-# We also need the user's login and home directory to prepare the
-# environment the way some programs expect it
-CI_USER_LOGIN = $(shell echo "$$USER")
-CI_USER_HOME = $(shell echo "$$HOME")
-
-CI_ENGINE = auto
-# Container engine we are going to use, can be overridden per make
-# invocation, if it is not we try podman and then default to docker.
-ifeq ($(CI_ENGINE),auto)
-	override CI_ENGINE = $(shell podman version >/dev/null 2>&1 && echo podman || echo docker)
-endif
-
-# IDs you run as do not need to exist in
-# the container's /etc/passwd & /etc/group files, but
-# if they do not, then libvirt's 'make check' will fail
-# many tests.
-
-# We do not directly mount /etc/{passwd,group} as Docker
-# is liable to mess with SELinux labelling which will
-# then prevent the host accessing them. And podman cannot
-# relabel the files due to it running rootless. So
-# copying them first is safer and less error-prone.
-CI_PWDB_MOUNTS = \
-	--volume $(CI_SCRATCHDIR)/group:/etc/group:ro,z \
-	--volume $(CI_SCRATCHDIR)/passwd:/etc/passwd:ro,z \
-	$(NULL)
-
-CI_HOME_MOUNTS = \
-	--volume $(CI_SCRATCHDIR)/home:$(CI_USER_HOME):z \
-	$(NULL)
-
-CI_SCRIPT_MOUNTS = \
-	--volume $(CI_SCRATCHDIR)/prepare:$(CI_USER_HOME)/prepare:z \
-	--volume $(CI_SCRATCHDIR)/build:$(CI_USER_HOME)/build:z \
-	$(NULL)
-
-# Docker containers can have very large ulimits
-# for nofiles - as much as 1048576. This makes
-# libvirt very slow at exec'ing programs.
-CI_ULIMIT_FILES = 1024
-
-ifeq ($(CI_ENGINE),podman)
-	# Podman cannot reuse host namespace when running non-root
-	# containers.  Until support for --keep-uid is added we can
-	# just create another mapping that will do that for us.
-	# Beware, that in {uid,git}map=container_id:host_id:range, the
-	# host_id does actually refer to the uid in the first mapping
-	# where 0 (root) is mapped to the current user and rest is
-	# offset.
-	#
-	# In order to set up this mapping, we need to keep all the
-	# user IDs to prevent possible errors as some images might
-	# expect UIDs up to 90000 (looking at you fedora), so we don't
-	# want the overflowuid to be used for them.  For mapping all
-	# the other users properly, some math needs to be done.
-	# Don't worry, it's just addition and subtraction.
-	#
-	# 65536 ought to be enough (tm), but for really rare cases the
-	# maximums might need to be higher, but that only happens when
-	# your /etc/sub{u,g}id allow users to have more IDs.  Unless
-	# --keep-uid is supported, let's do this in a way that should
-	# work for everyone.
-	CI_MAX_UID = $(shell sed -n "s/^$(CI_USER_LOGIN):[^:]\+://p" /etc/subuid)
-	CI_MAX_GID = $(shell sed -n "s/^$(CI_USER_LOGIN):[^:]\+://p" /etc/subgid)
-	ifeq ($(CI_MAX_UID),)
-		CI_MAX_UID = 65536
-	endif
-	ifeq ($(CI_MAX_GID),)
-		CI_MAX_GID = 65536
-	endif
-	CI_UID_OTHER = $(shell echo $$(($(CI_UID)+1)))
-	CI_GID_OTHER = $(shell echo $$(($(CI_GID)+1)))
-	CI_UID_OTHER_RANGE = $(shell echo $$(($(CI_MAX_UID)-$(CI_UID))))
-	CI_GID_OTHER_RANGE = $(shell echo $$(($(CI_MAX_GID)-$(CI_GID))))
-
-	CI_PODMAN_ARGS = \
-		--uidmap 0:1:$(CI_UID) \
-		--uidmap $(CI_UID):0:1 \
-		--uidmap $(CI_UID_OTHER):$(CI_UID_OTHER):$(CI_UID_OTHER_RANGE) \
-		--gidmap 0:1:$(CI_GID) \
-		--gidmap $(CI_GID):0:1 \
-		--gidmap $(CI_GID_OTHER):$(CI_GID_OTHER):$(CI_GID_OTHER_RANGE) \
-		$(NULL)
-endif
-
-# Args to use when cloning a git repo.
-#  -c  stop it complaining about checking out a random hash
-#  -q  stop it displaying progress info for local clone
-#  --local ensure we don't actually copy files
-CI_GIT_ARGS = \
-	-c advice.detachedHead=false \
-	-q \
-	--local  \
-	$(NULL)
-
-# Args to use when running the container
-#   --rm      stop inactive containers getting left behind
-#   --user    we execute as the same user & group account
-#             as dev so that file ownership matches host
-#             instead of root:root
-#   --volume  to pass in the cloned git repo & config
-#   --ulimit  lower files limit for performance reasons
-#   --interactive
-#   --tty     Ensure we have ability to Ctrl-C the build
-CI_ENGINE_ARGS = \
-	--rm \
-	--interactive \
-	--tty \
-	$(CI_PODMAN_ARGS) \
-	$(CI_PWDB_MOUNTS) \
-	$(CI_HOME_MOUNTS) \
-	$(CI_SCRIPT_MOUNTS) \
-	--volume $(CI_HOST_SRCDIR):$(CI_CONT_SRCDIR):z \
-	--ulimit nofile=$(CI_ULIMIT_FILES):$(CI_ULIMIT_FILES) \
-	--cap-add=SYS_PTRACE \
-	$(NULL)
-
-ci-check-engine:
-	@echo -n "Checking if $(CI_ENGINE) is available..." && \
-	$(CI_ENGINE) version 1>/dev/null && echo "yes"
-
-ci-prepare-tree: ci-check-engine
-	@test "$(CI_REUSE)" != "1" && rm -rf $(CI_SCRATCHDIR) || :
-	@if ! test -d $(CI_SCRATCHDIR) ; then \
-		mkdir -p $(CI_SCRATCHDIR); \
-		cp /etc/passwd $(CI_SCRATCHDIR); \
-		cp /etc/group $(CI_SCRATCHDIR); \
-		mkdir -p $(CI_SCRATCHDIR)/home; \
-		cp "$(CI_PREPARE_SCRIPT)" $(CI_SCRATCHDIR)/prepare; \
-		cp "$(CI_BUILD_SCRIPT)" $(CI_SCRATCHDIR)/build; \
-		chmod +x "$(CI_SCRATCHDIR)/prepare" "$(CI_SCRATCHDIR)/build"; \
-		echo "Cloning $(CI_GIT_ROOT) to $(CI_HOST_SRCDIR)"; \
-		git clone $(CI_GIT_ARGS) $(CI_GIT_ROOT) $(CI_HOST_SRCDIR) || exit 1; \
-		for mod in $$(git submodule | awk '{ print $$2 }' | sed -E 's,^../,,g') ; \
-		do \
-			test -f $(CI_GIT_ROOT)/$$mod/.git || continue ; \
-			echo "Cloning $(CI_GIT_ROOT)/$$mod to $(CI_HOST_SRCDIR)/$$mod"; \
-			git clone $(CI_GIT_ARGS) $(CI_GIT_ROOT)/$$mod $(CI_HOST_SRCDIR)/$$mod || exit 1; \
-		done ; \
-	fi
-
-ci-run-command@%: ci-prepare-tree
-	$(CI_ENGINE) run $(CI_ENGINE_ARGS) $(CI_IMAGE_PREFIX)$*$(CI_IMAGE_TAG) \
-		/bin/bash -c ' \
-		$(CI_USER_HOME)/prepare || exit 1; \
-		sudo \
-		  --login \
-		  --user="#$(CI_UID)" \
-		  --group="#$(CI_GID)" \
-		  CI_CONT_SRCDIR="$(CI_CONT_SRCDIR)" \
-		  CI_CONT_BUILDDIR="$(CI_CONT_BUILDDIR)" \
-		  CI_SMP="$(CI_SMP)" \
-		  CI_CONFIGURE="$(CI_CONFIGURE)" \
-		  CI_CONFIGURE_ARGS="$(CI_CONFIGURE_ARGS)" \
-		  CI_MAKE_ARGS="$(CI_MAKE_ARGS)" \
-		  $(CI_COMMAND) || exit 1'
-	@test "$(CI_CLEAN)" = "1" && rm -rf $(CI_SCRATCHDIR) || :
-
-ci-shell@%:
-	$(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="/bin/bash"
-
-ci-build@%:
-	$(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="$(CI_USER_HOME)/build"
-
-ci-check@%:
-	$(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="check"
-
-ci-list-images:
-	@echo
-	@echo "Available x86 container images:"
-	@echo
-	@sh list-images.sh "$(CI_ENGINE)" "$(CI_IMAGE_PREFIX)" | grep -v cross
-	@echo
-	@echo "Available cross-compiler container images:"
-	@echo
-	@sh list-images.sh "$(CI_ENGINE)" "$(CI_IMAGE_PREFIX)" | grep cross
-	@echo
-
-ci-help:
-	@echo "Build libvirt inside containers used for CI"
-	@echo
-	@echo "Available targets:"
-	@echo
-	@echo "    ci-build@\$$IMAGE - run a default 'make'"
-	@echo "    ci-check@\$$IMAGE - run a 'make check'"
-	@echo "    ci-shell@\$$IMAGE - run an interactive shell"
-	@echo "    ci-list-images  - list available images"
-	@echo "    ci-help         - show this help message"
-	@echo
-	@echo "Available make variables:"
-	@echo
-	@echo "    CI_CLEAN=0     - do not delete '$(CI_SCRATCHDIR)' after completion"
-	@echo "    CI_REUSE=1     - re-use existing '$(CI_SCRATCHDIR)' content"
-	@echo "    CI_ENGINE=auto - container engine to use (podman, docker)"
-	@echo

ci/build.sh

@@ -1,40 +0,0 @@
-# This script is used to build libvirt inside the container.
-#
-# You can customize it to your liking, or alternatively use a
-# completely different script by passing
-#
-#  CI_BUILD_SCRIPT=/path/to/your/build/script
-#
-# to make.
-
-mkdir -p "$CI_CONT_BUILDDIR" || exit 1
-cd "$CI_CONT_BUILDDIR"
-
-export VIR_TEST_DEBUG=1
-NOCONFIGURE=1 "$CI_CONT_SRCDIR/autogen.sh" || exit 1
-
-# $CONFIGURE_OPTS is a env that can optionally be set in the container,
-# populated at build time from the Dockerfile. A typical use case would
-# be to pass --host/--target args to trigger cross-compilation
-#
-# This can be augmented by make local args in $CI_CONFIGURE_ARGS
-"$CI_CONFIGURE" $CONFIGURE_OPTS $CI_CONFIGURE_ARGS
-if test $? != 0; then
-    test -f config.log && cat config.log
-    exit 1
-fi
-find -name test-suite.log -delete
-
-# gl_public_submodule_commit= to disable gnulib's submodule check
-# which breaks due to way we clone the submodules
-make -j"$CI_SMP" gl_public_submodule_commit= $CI_MAKE_ARGS
-
-if test $? != 0; then \
-    LOGS=$(find -name test-suite.log)
-    if test "$LOGS"; then
-        echo "=== LOG FILE(S) START ==="
-        cat $LOGS
-        echo "=== LOG FILE(S) END ==="
-    fi
-    exit 1
-fi

ci/list-images.sh

@@ -1,26 +0,0 @@
-#!/bin/sh
-
-engine="$1"
-prefix="$2"
-
-do_podman() {
-    # Podman freaks out if the search term ends with a dash, which ours
-    # by default does, so let's strip it. The repository name is the
-    # second field in the output, and it already starts with the registry
-    podman search --limit 100 "${prefix%-}" | while read _ repo _; do
-        echo "$repo"
-    done
-}
-
-do_docker() {
-    # Docker doesn't include the registry name in the output, so we have
-    # to add it. The repository name is the first field in the output
-    registry="${prefix%%/*}"
-    docker search --limit 100 "$prefix" | while read repo _; do
-        echo "$registry/$repo"
-    done
-}
-
-"do_$engine" | grep "^$prefix" | sed "s,^$prefix,,g" | while read repo; do
-    echo "    $repo"
-done | sort -u

ci/prepare.sh

@@ -1,13 +0,0 @@
-# This script is used to prepare the environment that will be used
-# to build libvirt inside the container.
-#
-# You can customize it to your liking, or alternatively use a
-# completely different script by passing
-#
-#  CI_PREPARE_SCRIPT=/path/to/your/prepare/script
-#
-# to make.
-#
-# Note that this script will have root privileges inside the
-# container, so it can be used for things like installing additional
-# packages.

config-post.h

@@ -1,61 +0,0 @@
-/*
- * Copyright (C) 2013 Red Hat, Inc.
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library.  If not, see
- * <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __GNUC__
-# error "Libvirt requires GCC >= 4.8, or CLang"
-#endif
-
-/*
- * Define __GNUC_PREREQ to a sane default if it isn't yet defined.
- * This is done here so that it's included as early as possible; gnulib relies
- * on this to be defined in features.h, which should be included from ctype.h.
- * This doesn't happen on many non-glibc systems.
- * When __GNUC_PREREQ is not defined, gnulib defines it to 0, which breaks things.
- */
-#ifndef __GNUC_PREREQ
-# define __GNUC_PREREQ(maj, min) \
-    ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
-#endif
-
-#if defined(__clang_major__) && defined(__clang_minor__)
-# ifdef __apple_build_version__
-#  if __clang_major__ < 5 || (__clang_major__ == 5 && __clang_minor__ < 1)
-#   error You need at least XCode Clang v5.1 to compile QEMU
-#  endif
-# else
-#  if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
-#   error You need at least Clang v3.4 to compile QEMU
-#  endif
-# endif
-#elif defined(__GNUC__) && defined(__GNUC_MINOR__)
-# if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
-#  error You need at least GCC v4.8 to compile QEMU
-# endif
-#else
-# error You either need at least GCC 4.8 or Clang 3.4 or XCode Clang 5.1 to compile libvirt
-#endif
-
-/* Ask for warnings for anything that was marked deprecated in
- * the defined version, or before. It is a candidate for rewrite.
- */
-#define GLIB_VERSION_MIN_REQUIRED GLIB_VERSION_2_48
-
-/* Ask for warnings if code tries to use function that did not
- * exist in the defined version. These risk breaking builds
- */
-#define GLIB_VERSION_MAX_ALLOWED GLIB_VERSION_2_48

docs/404.html.in

@@ -1,19 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>404 page not found</h1>
-
-    <p>
-      Someone appears to have eaten the <del>penguin</del>
-      page you were looking for. You might want to try
-    </p>
-    <ul>
-      <li>going back to the <a href="https://libvirt.org/">home page</a> to find
-        a collection of links to interesting pages on this site</li>
-      <li>using the search box at the top right corner of the screen to
-        locate the content on this site or mailing list archives</li>
-    </ul>
-
-  </body>
-</html>

docs/Makefile.am

@@ -1,521 +0,0 @@
-## Process this file with automake to produce Makefile.in
-
-## Copyright (C) 2005-2016 Red Hat, Inc.
-##
-## This library is free software; you can redistribute it and/or
-## modify it under the terms of the GNU Lesser General Public
-## License as published by the Free Software Foundation; either
-## version 2.1 of the License, or (at your option) any later version.
-##
-## This library is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-## Lesser General Public License for more details.
-##
-## You should have received a copy of the GNU Lesser General Public
-## License along with this library.  If not, see
-## <http://www.gnu.org/licenses/>.
-
-HTML_DIR = $(docdir)/html
-
-modules = \
-	libvirt-common \
-	libvirt-domain \
-	libvirt-domain-checkpoint \
-	libvirt-domain-snapshot \
-	libvirt-event \
-	libvirt-host \
-	libvirt-interface \
-	libvirt-network \
-	libvirt-nodedev \
-	libvirt-nwfilter \
-	libvirt-secret \
-	libvirt-storage \
-	libvirt-stream \
-	virterror \
-	$(NULL)
-
-modules_admin = libvirt-admin
-modules_qemu = libvirt-qemu
-modules_lxc = libvirt-lxc
-
-all: vpathhack
-
-# This hack enables us to view the web pages
-# from within the uninstalled build tree
-vpathhack:
-	@for dir in fonts js logos; \
-	do \
-	  test -e $$dir || ln -s $(srcdir)/$$dir $$dir ; \
-	done
-	@for file in $(css); \
-	do \
-	  test -e $$file || ln -s $(srcdir)/$$file $$file ; \
-	done
-
-clean-local:
-	for dir in fonts js logos; \
-	do \
-	  rm -f $$dir ; \
-	done
-	for file in $(css); \
-	do \
-	  rm -f $$file ; \
-	done
-
-apihtml = \
-  html/index.html \
-  $(apihtml_generated)
-
-apihtml_generated = \
-	$(addprefix html/libvirt-,$(addsuffix .html,$(modules))) \
-	$(NULL)
-
-apiadminhtml = \
-  html/index-admin.html \
-  $(apiadminhtml_generated)
-
-apiadminhtml_generated = \
-	$(addprefix html/libvirt-,$(addsuffix .html,$(modules_admin))) \
-	$(NULL)
-
-apiqemuhtml = \
-  html/index-qemu.html \
-  $(apiqemuhtml_generated)
-
-apiqemuhtml_generated = \
-	$(addprefix html/libvirt-,$(addsuffix .html,$(modules_qemu))) \
-	$(NULL)
-
-apilxchtml = \
-  html/index-lxc.html \
-  $(apilxchtml_generated)
-
-apilxchtml_generated = \
-	$(addprefix html/libvirt-,$(addsuffix .html,$(modules_lxc))) \
-	$(NULL)
-
-apipng = \
-  html/left.png \
-  html/up.png \
-  html/home.png \
-  html/right.png
-
-apirefdir = $(HTML_DIR)/html
-apiref_DATA = $(apihtml) $(apiadminhtml) $(apiqemuhtml) $(apilxchtml) $(apipng)
-
-css = \
-  generic.css \
-  libvirt.css \
-  mobile.css \
-  main.css
-
-javascript = \
-  js/main.js \
-  $(NULL)
-
-javascriptdir = $(HTML_DIR)/js
-javascript_DATA = $(javascript)
-
-fonts = \
-  fonts/LICENSE.md \
-  fonts/stylesheet.css \
-  fonts/overpass-bold-italic.woff \
-  fonts/overpass-bold.woff \
-  fonts/overpass-italic.woff \
-  fonts/overpass-light-italic.woff \
-  fonts/overpass-light.woff \
-  fonts/overpass-mono-bold.woff \
-  fonts/overpass-mono-light.woff \
-  fonts/overpass-mono-regular.woff \
-  fonts/overpass-mono-semibold.woff \
-  fonts/overpass-regular.woff
-
-fontsdir = $(HTML_DIR)/fonts
-fonts_DATA = $(fonts)
-
-logofiles = \
-  logos/logo-base.svg \
-  logos/logo-square.svg \
-  logos/logo-square-powered.svg \
-  logos/logo-banner-dark.svg \
-  logos/logo-banner-light.svg \
-  logos/logo-square-96.png \
-  logos/logo-square-128.png \
-  logos/logo-square-192.png \
-  logos/logo-square-256.png \
-  logos/logo-square-powered-96.png \
-  logos/logo-square-powered-128.png \
-  logos/logo-square-powered-192.png \
-  logos/logo-square-powered-256.png \
-  logos/logo-banner-dark-256.png \
-  logos/logo-banner-dark-800.png \
-  logos/logo-banner-light-256.png \
-  logos/logo-banner-light-800.png
-
-logofilesdir = $(HTML_DIR)/logos
-logofiles_DATA = $(logofiles)
-
-png = \
-  32favicon.png \
-  libvirt-daemon-arch.png \
-  libvirt-driver-arch.png \
-  libvirt-object-model.png \
-  migration-managed-direct.png \
-  migration-managed-p2p.png \
-  migration-native.png \
-  migration-tunnel.png \
-  migration-unmanaged-direct.png
-
-gif = \
-  architecture.gif \
-  node.gif
-
-internals_html_in = \
-  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.html.in))
-internals_rst = \
-  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.rst))
-internals_rst_html_in = \
-  $(internals_rst:%.rst=%.html.in)
-internals_html = \
-  $(internals_html_in:%.html.in=%.html) \
-  $(internals_rst_html_in:%.html.in=%.html)
-
-internalsdir = $(HTML_DIR)/internals
-internals_DATA = $(internals_html)
-
-kbase_html_in = \
-  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.html.in))
-kbase_rst = \
-  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.rst))
-kbase_rst_html_in = \
-  $(kbase_rst:%.rst=%.html.in)
-kbase_html = \
-  $(kbase_html_in:%.html.in=%.html) \
-  $(kbase_rst_html_in:%.html.in=%.html)
-
-kbasedir = $(HTML_DIR)/kbase
-kbase_DATA = $(kbase_html)
-
-# Sync with src/util/
-KEYCODES = linux osx atset1 atset2 atset3 xtkbd usb win32 qnum
-KEYNAMES = linux osx win32
-
-manpages_rst = \
-  manpages/index.rst \
-  $(NULL)
-manpages1_rst = \
-  manpages/virt-pki-validate.rst \
-  manpages/virt-xml-validate.rst \
-  manpages/virt-admin.rst \
-  manpages/virsh.rst \
-  $(NULL)
-manpages7_rst = \
-  $(KEYCODES:%=manpages/virkeycode-%.rst) \
-  $(KEYNAMES:%=manpages/virkeyname-%.rst) \
-  $(NULL)
-manpages8_rst = $(NULL)
-manpages_rst += \
-  $(manpages1_rst) \
-  $(manpages7_rst) \
-  $(manpages8_rst) \
-  $(NULL)
-if WITH_LIBVIRTD
-manpages8_rst += \
-  manpages/libvirtd.rst \
-  manpages/virtlockd.rst \
-  manpages/virtlogd.rst \
-  $(NULL)
-else ! WITH_LIBVIRTD
-manpages_rst += \
-  manpages/libvirtd.rst \
-  manpages/virtlockd.rst \
-  manpages/virtlogd.rst \
-  $(NULL)
-endif ! WITH_LIBVIRTD
-if WITH_HOST_VALIDATE
-  manpages1_rst += manpages/virt-host-validate.rst
-else ! WITH_HOST_VALIDATE
-  manpages_rst += manpages/virt-host-validate.rst
-endif ! WITH_HOST_VALIDATE
-if WITH_LOGIN_SHELL
-  manpages1_rst += manpages/virt-login-shell.rst
-else ! WITH_LOGIN_SHELL
-  manpages_rst += manpages/virt-login-shell.rst
-endif ! WITH_LOGIN_SHELL
-if WITH_SANLOCK
-  manpages8_rst += manpages/virt-sanlock-cleanup.rst
-else ! WITH_SANLOCK
-  manpages_rst += manpages/virt-sanlock-cleanup.rst
-endif ! WITH_SANLOCK
-manpages_rst_html_in = \
-  $(manpages_rst:%.rst=%.html.in)
-manpages_html = \
-  $(manpages_rst_html_in:%.html.in=%.html)
-
-man1_MANS = $(manpages1_rst:%.rst=%.1)
-man7_MANS = $(manpages7_rst:%.rst=%.7)
-man8_MANS = $(manpages8_rst:%.rst=%.8)
-
-%.1: %.rst
-	$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
-	   grep -v '^\.\. contents::' < $< | \
-	   sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
-	       -e 's|RUNSTATEDIR|$(runstatedir)|g' | \
-	   $(RST2MAN) > $@ || { rm $@ && exit 1; }
-
-%.7: %.rst
-	$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
-	   grep -v '^\.\. contents::' < $< | \
-	   sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
-	       -e 's|RUNSTATEDIR|$(runstatedir)|g' | \
-	   $(RST2MAN) > $@ || { rm $@ && exit 1; }
-
-%.8: %.rst
-	$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
-	   grep -v '^\.\. contents::' < $< | \
-	   sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
-	       -e 's|RUNSTATEDIR|$(runstatedir)|g' | \
-	   $(RST2MAN) > $@ || { rm $@ && exit 1; }
-
-manpages/virkeycode-%.rst: $(top_srcdir)/src/keycodemapdb/data/keymaps.csv \
-		$(top_srcdir)/src/keycodemapdb/tools/keymap-gen Makefile.am
-	$(AM_V_GEN)export NAME=`echo $@ | \
-		sed -e 's,manpages/virkeycode-,,' -e 's,\.rst,,'` && \
-		$(MKDIR_P) manpages/ && \
-		$(RUNUTF8) $(PYTHON) $(top_srcdir)/src/keycodemapdb/tools/keymap-gen \
-		code-docs \
-		--lang rst \
-		--title "virkeycode-$$NAME" \
-		--subtitle "Key code values for $$NAME" \
-		$(top_srcdir)/src/keycodemapdb/data/keymaps.csv $$NAME > $@
-
-manpages/virkeyname-%.rst: $(top_srcdir)/src/keycodemapdb/data/keymaps.csv \
-		$(top_srcdir)/src/keycodemapdb/tools/keymap-gen Makefile.am
-	$(AM_V_GEN)export NAME=`echo $@ | \
-		sed -e 's,manpages/virkeyname-,,' -e 's,\.rst,,'` && \
-		$(MKDIR_P) manpages/ && \
-		$(RUNUTF8) $(PYTHON) $(top_srcdir)/src/keycodemapdb/tools/keymap-gen \
-		name-docs \
-		--lang rst \
-		--title "virkeyname-$$NAME" \
-		--subtitle "Key name values for $$NAME" \
-		$(top_srcdir)/src/keycodemapdb/data/keymaps.csv $$NAME > $@
-
-manpagesdir = $(HTML_DIR)/manpages
-manpages_DATA = $(manpages_html)
-
-# Generate hvsupport.html and news.html first, since they take one extra step.
-dot_html_generated_in = \
-  hvsupport.html.in \
-  news.html.in
-dot_html_in = \
-  $(notdir $(wildcard $(srcdir)/*.html.in))
-dot_rst = \
-  $(notdir $(wildcard $(srcdir)/*.rst))
-dot_rst_html_in = \
-  $(dot_rst:%.rst=%.html)
-dot_html = \
-  $(dot_html_generated_in:%.html.in=%.html) \
-  $(dot_html_in:%.html.in=%.html) \
-  $(dot_rst_html_in:%.html.in=%.html)
-
-htmldir = $(HTML_DIR)
-html_DATA = $(css) $(png) $(gif) $(dot_html)
-
-apidir = $(pkgdatadir)/api
-api_DATA = \
-       libvirt-api.xml \
-       libvirt-qemu-api.xml \
-       libvirt-lxc-api.xml \
-       libvirt-admin-api.xml
-
-fig = \
-  libvirt-daemon-arch.fig \
-  libvirt-driver-arch.fig \
-  libvirt-object-model.fig \
-  migration-managed-direct.fig \
-  migration-managed-p2p.fig \
-  migration-native.fig \
-  migration-tunnel.fig \
-  migration-unmanaged-direct.fig
-
-schemadir = $(pkgdatadir)/schemas
-schema_DATA = $(wildcard $(srcdir)/schemas/*.rng)
-
-EXTRA_DIST= \
-  site.xsl subsite.xsl newapi.xsl page.xsl \
-  wrapstring.xsl \
-  $(dot_html_in) $(dot_rst) $(gif) $(apipng) \
-  $(fig) $(png) $(css) \
-  $(javascript) $(logofiles) \
-  $(internals_html_in) $(internals_rst) $(fonts) \
-  $(kbase_html_in) $(kbase_rst) \
-  $(manpages_rst) \
-  aclperms.htmlinc \
-  $(schema_DATA)
-
-acl_generated = aclperms.htmlinc
-
-aclperms.htmlinc: $(top_srcdir)/src/access/viraccessperm.h \
-        $(top_srcdir)/scripts/genaclperms.py Makefile.am
-	$(AM_V_GEN)$(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/genaclperms.py $< > $@
-
-CLEANFILES = \
-  $(dot_html) \
-  $(apihtml) \
-  $(apiadminhtml) \
-  $(apiqemuhtml) \
-  $(apilxchtml) \
-  $(internals_html) \
-  $(kbase_html) \
-  $(manpages_html) \
-  $(man1_MANS) \
-  $(man7_MANS) \
-  $(manpages7_rst) \
-  $(man8_MANS) \
-  $(api_DATA) \
-  $(dot_html_generated_in) \
-  aclperms.htmlinc
-
-timestamp="$(shell if test -n "$$SOURCE_DATE_EPOCH"; \
-		   then \
-		     date -u --date="@$$SOURCE_DATE_EPOCH"; \
-		   else \
-		     date -u; \
-		   fi)"
-
-hvsupport.html: hvsupport.html.in
-
-hvsupport.html.in: $(top_srcdir)/scripts/hvsupport.py $(api_DATA) \
-		$(top_srcdir)/src/libvirt_public.syms \
-	$(top_srcdir)/src/libvirt_qemu.syms $(top_srcdir)/src/libvirt_lxc.syms \
-	$(top_srcdir)/src/driver.h
-	$(AM_V_GEN)$(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/hvsupport.py \
-		$(top_srcdir) $(top_builddir) > $@ || { rm $@ && exit 1; }
-
-news.html.in: \
-	  $(srcdir)/news.xml \
-	  $(srcdir)/news-html.xsl
-	$(AM_V_GEN)$(XSLTPROC) --nonet \
-	    $(srcdir)/news-html.xsl \
-	    $(srcdir)/news.xml \
-	  >$@ \
-	    || { rm -f $@; exit 1; };
-EXTRA_DIST += \
-	$(srcdir)/news.xml \
-	$(srcdir)/news.rng \
-	$(srcdir)/news-html.xsl
-
-%.png: %.fig
-	convert -rotate 90 $< $@
-
-manpages/%.html.in: manpages/%.rst
-	$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
-	 grep -v '^:Manual ' < $< | \
-	  sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
-	     -e 's|RUNSTATEDIR|$(runstatedir)|g' | \
-	  $(RST2HTML) > $@ || { rm $@ && exit 1; }
-
-%.html.in: %.rst
-	$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
-	  $(RST2HTML) $< > $@ || { rm $@ && exit 1; }
-
-%.html.tmp: %.html.in site.xsl subsite.xsl page.xsl \
-		$(acl_generated)
-	$(AM_V_GEN)name=`echo $@ | sed -e 's/.tmp//'`; \
-	  dir=`dirname $@` ; \
-	  if test "$$dir" = "."; \
-	  then \
-	    style=site.xsl; \
-	  else \
-	    $(MKDIR_P) $$dir; \
-	    style=subsite.xsl; \
-	  fi; \
-	  $(XSLTPROC) --stringparam pagename $$name \
-	    --stringparam builddir '$(abs_top_builddir)' \
-	    --stringparam timestamp $(timestamp) --nonet \
-	    $(top_srcdir)/docs/$$style $< > $@ \
-	    || { rm $@ && exit 1; }
-
-%.html: %.html.tmp
-	$(AM_V_GEN)$(XMLLINT) --nonet --format $< > $@ \
-	  || { rm $@ && exit 1; }
-
-$(apihtml_generated): html/index.html
-$(apiadminhtml_generated): html/index-admin.html
-$(apiqemuhtml_generated): html/index-qemu.html
-$(apilxchtml_generated): html/index-lxc.html
-
-html/index.html: libvirt-api.xml newapi.xsl page.xsl $(APIBUILD_STAMP)
-	$(AM_V_GEN)$(XSLTPROC) --nonet -o ./ \
-	  --stringparam builddir '$(abs_top_builddir)' \
-	  --stringparam timestamp $(timestamp) \
-	  $(srcdir)/newapi.xsl libvirt-api.xml
-
-html/index-%.html: libvirt-%-api.xml newapi.xsl page.xsl $(APIBUILD_STAMP)
-	$(AM_V_GEN)$(XSLTPROC) --nonet -o ./ \
-	  --stringparam builddir '$(abs_top_builddir)' \
-	  --stringparam timestamp $(timestamp) \
-	  --stringparam indexfile $(@:html/%=%) \
-	  $(srcdir)/newapi.xsl $<
-
-check-html:
-	$(XMLLINT) --nonet --noout html/*.html
-
-check-local: check-html
-
-python_generated_files = \
-		html/libvirt-libvirt-lxc.html \
-		html/libvirt-libvirt-qemu.html \
-		html/libvirt-libvirt-admin.html \
-		html/libvirt-virterror.html \
-		$(api_DATA) \
-		$(NULL)
-
-APIBUILD=$(top_srcdir)/scripts/apibuild.py
-APIBUILD_STAMP=apibuild.py.stamp
-CLEANFILES += $(APIBUILD_STAMP)
-
-$(python_generated_files): $(APIBUILD_STAMP)
-
-$(APIBUILD_STAMP): $(top_srcdir)/scripts/apibuild.py \
-		$(top_srcdir)/include/libvirt/libvirt.h \
-		$(top_srcdir)/include/libvirt/libvirt-common.h.in \
-		$(top_srcdir)/include/libvirt/libvirt-domain-checkpoint.h \
-		$(top_srcdir)/include/libvirt/libvirt-domain-snapshot.h \
-		$(top_srcdir)/include/libvirt/libvirt-domain.h \
-		$(top_srcdir)/include/libvirt/libvirt-event.h \
-		$(top_srcdir)/include/libvirt/libvirt-host.h \
-		$(top_srcdir)/include/libvirt/libvirt-interface.h \
-		$(top_srcdir)/include/libvirt/libvirt-network.h \
-		$(top_srcdir)/include/libvirt/libvirt-nodedev.h \
-		$(top_srcdir)/include/libvirt/libvirt-nwfilter.h \
-		$(top_srcdir)/include/libvirt/libvirt-secret.h \
-		$(top_srcdir)/include/libvirt/libvirt-storage.h \
-		$(top_srcdir)/include/libvirt/libvirt-stream.h \
-		$(top_srcdir)/include/libvirt/libvirt-lxc.h \
-		$(top_srcdir)/include/libvirt/libvirt-qemu.h \
-		$(top_srcdir)/include/libvirt/libvirt-admin.h \
-		$(top_srcdir)/include/libvirt/virterror.h \
-		$(top_srcdir)/src/libvirt.c \
-		$(top_srcdir)/src/libvirt-domain-checkpoint.c \
-		$(top_srcdir)/src/libvirt-domain-snapshot.c \
-		$(top_srcdir)/src/libvirt-domain.c \
-		$(top_srcdir)/src/libvirt-host.c \
-		$(top_srcdir)/src/libvirt-interface.c \
-		$(top_srcdir)/src/libvirt-network.c \
-		$(top_srcdir)/src/libvirt-nodedev.c \
-		$(top_srcdir)/src/libvirt-nwfilter.c \
-		$(top_srcdir)/src/libvirt-secret.c \
-		$(top_srcdir)/src/libvirt-storage.c \
-		$(top_srcdir)/src/libvirt-stream.c \
-		$(top_srcdir)/src/libvirt-lxc.c \
-		$(top_srcdir)/src/libvirt-qemu.c \
-		$(top_srcdir)/src/admin/libvirt-admin.c \
-		$(top_srcdir)/src/util/virerror.c \
-		$(top_srcdir)/src/util/virevent.c \
-		$(top_srcdir)/src/util/virtypedparam-public.c
-	$(AM_V_GEN)srcdir=$(srcdir) builddir=$(builddir) \
-		$(RUNUTF8) $(PYTHON) $(APIBUILD)
-	touch $@

docs/acl.html.in

@@ -1,100 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Client access control</h1>
-    <p>
-      Libvirt's client access control framework allows administrators
-      to setup fine grained permission rules across client users,
-      managed objects and API operations. This allows client connections
-      to be locked down to a minimal set of privileges.
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="intro">Access control introduction</a></h2>
-
-    <p>
-      In a default configuration, the libvirtd daemon has three levels
-      of access control. All connections start off in an unauthenticated
-      state, where the only API operations allowed are those required
-      to complete authentication. After successful authentication, a
-      connection either has full, unrestricted access to all libvirt
-      API calls, or is locked down to only "read only" operations,
-      according to what socket a client connection originated on.
-    </p>
-
-    <p>
-      The access control framework allows authenticated connections to
-      have fine grained permission rules to be defined by the administrator.
-      Every API call in libvirt has a set of permissions that will
-      be validated against the object being used. For example, the
-      <code>virDomainSetSchedulerParametersFlags</code> method will
-      check whether the client user has the <code>write</code>
-      permission on the <code>domain</code> object instance passed
-      in as a parameter. Further permissions will also be checked
-      if certain flags are set in the API call. In addition to
-      checks on the object passed in to an API call, some methods
-      will filter their results. For example the <code>virConnectListAllDomains</code>
-      method will check the <code>search_domains</code> on the <code>connect</code>
-      object, but will also filter the returned <code>domain</code>
-      objects to only those on which the client user has the
-      <code>getattr</code> permission.
-    </p>
-
-    <h2><a id="drivers">Access control drivers</a></h2>
-
-    <p>
-      The access control framework is designed as a pluggable
-      system to enable future integration with arbitrary access
-      control technologies. By default, the <code>none</code>
-      driver is used, which does no access control checks at
-      all. At this time, libvirt ships with support for using
-      <a href="http://www.freedesktop.org/wiki/Software/polkit/">polkit</a> as a real access
-      control driver. To learn how to use the polkit access
-      driver consult <a href="aclpolkit.html">the configuration
-      docs</a>.
-    </p>
-
-    <p>
-      The access driver is configured in the <code>libvirtd.conf</code>
-      configuration file, using the <code>access_drivers</code>
-      parameter. This parameter accepts an array of access control
-      driver names. If more than one access driver is requested,
-      then all must succeed in order for access to be granted.
-      To enable 'polkit' as the driver:
-    </p>
-
-    <pre>
-# augtool -s set '/files/etc/libvirt/libvirtd.conf/access_drivers[1]' polkit
-    </pre>
-
-    <p>
-      And to reset back to the default (no-op) driver
-    </p>
-
-
-    <pre>
-# augtool -s rm /files/etc/libvirt/libvirtd.conf/access_drivers
-    </pre>
-
-    <p>
-      <strong>Note:</strong> changes to libvirtd.conf require that
-      the libvirtd daemon be restarted.
-    </p>
-
-    <h2><a id="perms">Objects and permissions</a></h2>
-
-    <p>
-      Libvirt applies access control to all the main object
-      types in its API. Each object type, in turn, has a set
-      of permissions defined. To determine what permissions
-      are checked for specific API call, consult the
-      <a href="html/index.html">API reference manual</a>
-      documentation for the API in question.
-    </p>
-
-    <div id="include" filename="aclperms.htmlinc"/>
-
-  </body>
-</html>

docs/aclpolkit.html.in

@@ -1,523 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Polkit access control</h1>
-
-    <p>
-      Libvirt's client <a href="acl.html">access control framework</a> allows
-      administrators to setup fine grained permission rules across client users,
-      managed objects and API operations. This allows client connections
-      to be locked down to a minimal set of privileges. The polkit driver
-      provides a simple implementation of the access control framework.
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="intro">Introduction</a></h2>
-
-    <p>
-      A default install of libvirt will typically use
-      <a href="http://www.freedesktop.org/wiki/Software/polkit/">polkit</a>
-      to authenticate the initial user connection to libvirtd. This is a
-      very coarse grained check though, either allowing full read-write
-      access to all APIs, or just read-only access. The polkit access
-      control driver in libvirt builds on this capability to allow for
-      fine grained control over the operations a user may perform on an
-      object.
-    </p>
-
-    <h2><a id="perms">Permission names</a></h2>
-
-    <p>
-      The libvirt <a href="acl.html#perms">object names and permission names</a>
-      are mapped onto polkit action names using the simple pattern:
-    </p>
-
-    <pre>org.libvirt.api.$object.$permission
-</pre>
-
-    <p>
-      The only caveat is that any underscore characters in the
-      object or permission names are converted to hyphens. So,
-      for example, the <code>search_storage_vols</code> permission
-      on the <code>storage_pool</code> object maps to the polkit
-      action:
-    </p>
-    <pre>org.libvirt.api.storage-pool.search-storage-vols
-</pre>
-
-    <p>
-      The default policy for any permission which corresponds to
-      a "read only" operation, is to allow access. All other
-      permissions default to deny access.
-    </p>
-
-    <h2><a id="attrs">Object identity attributes</a></h2>
-
-    <p>
-      To allow polkit authorization rules to be written to match
-      against individual object instances, libvirt provides a number
-      of authorization detail attributes when performing a permission
-      check. The set of attributes varies according to the type
-      of object being checked
-    </p>
-
-    <h3><a id="object_connect">virConnectPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_domain">virDomainPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>domain_name</td>
-          <td>Name of the domain, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>domain_uuid</td>
-          <td>UUID of the domain, globally unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_interface">virInterfacePtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>interface_name</td>
-          <td>Name of the network interface, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>interface_macaddr</td>
-          <td>MAC address of the network interface, not unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_network">virNetworkPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>network_name</td>
-          <td>Name of the network, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>network_uuid</td>
-          <td>UUID of the network, globally unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_node_device">virNodeDevicePtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>node_device_name</td>
-          <td>Name of the node device, unique to the local host</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_nwfilter">virNWFilterPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>nwfilter_name</td>
-          <td>Name of the network filter, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>nwfilter_uuid</td>
-          <td>UUID of the network filter, globally unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_secret">virSecretPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>secret_uuid</td>
-          <td>UUID of the secret, globally unique</td>
-        </tr>
-        <tr>
-          <td>secret_usage_volume</td>
-          <td>Name of the associated volume, if any</td>
-        </tr>
-        <tr>
-          <td>secret_usage_ceph</td>
-          <td>Name of the associated Ceph server, if any</td>
-        </tr>
-        <tr>
-          <td>secret_usage_target</td>
-          <td>Name of the associated iSCSI target, if any</td>
-        </tr>
-        <tr>
-          <td>secret_usage_name</td>
-          <td>Name of the associated TLS secret, if any</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_storage_pool">virStoragePoolPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>pool_name</td>
-          <td>Name of the storage pool, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>pool_uuid</td>
-          <td>UUID of the storage pool, globally unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h3><a id="object_storage_vol">virStorageVolPtr</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Attribute</th>
-          <th>Description</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>connect_driver</td>
-          <td>Name of the libvirt connection driver</td>
-        </tr>
-        <tr>
-          <td>pool_name</td>
-          <td>Name of the storage pool, unique to the local host</td>
-        </tr>
-        <tr>
-          <td>pool_uuid</td>
-          <td>UUID of the storage pool, globally unique</td>
-        </tr>
-        <tr>
-          <td>vol_name</td>
-          <td>Name of the storage volume, unique to the pool</td>
-        </tr>
-        <tr>
-          <td>vol_key</td>
-          <td>Key of the storage volume, globally unique</td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h2><a id="connect_driver">Hypervisor Driver connect_driver</a></h2>
-    <p>
-      The <code>connect_driver</code> parameter describes the
-      client's <a href="remote.html">remote Connection Driver</a>
-      name based on the <a href="uri.html">URI</a> used for the
-      connection.
-    </p>
-    <p>
-      <span class="since">Since 4.1.0</span>, when calling an API
-      outside the scope of the primary connection driver, the
-      primary driver will attempt to open a secondary connection
-      to the specific API driver in order to process the API. For
-      example, when hypervisor domain processing needs to make an
-      API call within the storage driver or the network filter driver
-      an attempt to open a connection to the "storage" or "nwfilter"
-      driver will be made. Similarly, a "storage" primary connection
-      may need to create a connection to the "secret" driver in order
-      to process secrets for the API. If successful, then calls to
-      those API's will occur in the <code>connect_driver</code> context
-      of the secondary connection driver rather than in the context of
-      the primary driver. This affects the <code>connect_driver</code>
-      returned from rule generation from the <code>action.loookup</code>
-      function. The following table provides a list of the various
-      connection drivers and the <code>connect_driver</code> name
-      used by each regardless of primary or secondary connection.
-      The access denied error message from libvirt will list the
-      connection driver by name that denied the access.
-    </p>
-
-    <h3><a id="object_connect_driver">Connection Driver Name</a></h3>
-    <table>
-      <thead>
-        <tr>
-          <th>Connection Driver</th>
-          <th><code>connect_driver</code> name</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>bhyve</td>
-          <td>bhyve</td>
-        </tr>
-        <tr>
-          <td>esx</td>
-          <td>ESX</td>
-        </tr>
-        <tr>
-          <td>hyperv</td>
-          <td>Hyper-V</td>
-        </tr>
-        <tr>
-          <td>interface</td>
-          <td>interface</td>
-        </tr>
-        <tr>
-          <td>libxl</td>
-          <td>xenlight</td>
-        </tr>
-        <tr>
-          <td>lxc</td>
-          <td>LXC</td>
-        </tr>
-        <tr>
-          <td>network</td>
-          <td>network</td>
-        </tr>
-        <tr>
-          <td>nodedev</td>
-          <td>nodedev</td>
-        </tr>
-        <tr>
-          <td>nwfilter</td>
-          <td>NWFilter</td>
-        </tr>
-        <tr>
-          <td>openvz</td>
-          <td>OPENVZ</td>
-        </tr>
-        <tr>
-          <td>qemu</td>
-          <td>QEMU</td>
-        </tr>
-        <tr>
-          <td>secret</td>
-          <td>secret</td>
-        </tr>
-        <tr>
-          <td>storage</td>
-          <td>storage</td>
-        </tr>
-        <tr>
-          <td>vbox</td>
-          <td>VBOX</td>
-        </tr>
-        <tr>
-          <td>vmware</td>
-          <td>VMWARE</td>
-        </tr>
-        <tr>
-          <td>vz</td>
-          <td>vz</td>
-        </tr>
-      </tbody>
-    </table>
-
-
-    <h2><a id="user">User identity attributes</a></h2>
-
-    <p>
-      At this point in time, the only attribute provided by
-      libvirt to identify the user invoking the operation
-      is the PID of the client program. This means that the
-      polkit access control driver is only useful if connections
-      to libvirt are restricted to its UNIX domain socket. If
-      connections are being made to a TCP socket, no identifying
-      information is available and access will be denied.
-      Also note that if the client is connecting via an SSH
-      tunnel, it is the local SSH user that will be identified.
-      In future versions, it is expected that more information
-      about the client user will be provided, including the
-      SASL / Kerberos username and/or x509 distinguished
-      name obtained from the authentication provider in use.
-    </p>
-
-
-    <h2><a id="checks">Writing access control policies</a></h2>
-
-    <p>
-      If using versions of polkit prior to 0.106 then it is only
-      possible to validate (user, permission) pairs via the <code>.pkla</code>
-      files. Fully validation of the (user, permission, object) triple
-      requires the new JavaScript <code>.rules</code> support that
-      was introduced in version 0.106. The latter is what will be
-      described here.
-    </p>
-
-    <p>
-      Libvirt does not ship any rules files by default. It merely
-      provides a definition of the default behaviour for each
-      action (permission). As noted earlier, permissions which
-      correspond to read-only operations in libvirt will be allowed
-      to all users by default; everything else is denied by default.
-      Defining custom rules requires creation of a file in the
-      <code>/etc/polkit-1/rules.d</code> directory with a name
-      chosen by the administrator (<code>100-libvirt-acl.rules</code>
-      would be a reasonable choice). See the <code>polkit(8)</code>
-      manual page for a description of how to write these files
-      in general. The key idea is to create a file containing
-      something like
-    </p>
-
-    <pre>
-polkit.addRule(function(action, subject) {
-  ....logic to check 'action' and 'subject'...
-});
-    </pre>
-
-    <p>
-      In this code snippet above, the <code>action</code> object
-      instance will represent the libvirt permission being checked
-      along with identifying attributes for the object it is being
-      applied to. The <code>subject</code> meanwhile will identify
-      the libvirt client app (with the caveat above about it only
-      dealing with local clients connected via the UNIX socket).
-      On the <code>action</code> object, the permission name is
-      accessible via the <code>id</code> attribute, while the
-      object identifying attributes are exposed via the
-      <code>lookup</code> method.
-    </p>
-
-    <p>
-    See
-    <a href="https://libvirt.org/git/?p=libvirt.git;a=tree;f=examples/polkit;hb=HEAD">source code</a>
-    for a more complex example.
-    </p>
-
-    <h3><a id="exconnect">Example: restricting ability to connect to drivers</a></h3>
-
-    <p>
-      Consider a local user <code>berrange</code>
-      who has been granted permission to connect to libvirt in
-      full read-write mode. The goal is to only allow them to
-      use the <code>QEMU</code> driver and not the Xen or LXC
-      drivers which are also available in libvirtd.
-      To achieve this we need to write a rule which checks
-      whether the <code>connect_driver</code> attribute
-      is <code>QEMU</code>, and match on an action
-      name of <code>org.libvirt.api.connect.getattr</code>. Using
-      the javascript rules format, this ends up written as
-    </p>
-
-    <pre>
-polkit.addRule(function(action, subject) {
-    if (action.id == "org.libvirt.api.connect.getattr" &amp;&amp;
-        subject.user == "berrange") {
-          if (action.lookup("connect_driver") == 'QEMU') {
-            return polkit.Result.YES;
-          } else {
-            return polkit.Result.NO;
-          }
-    }
-});
-    </pre>
-
-    <h3><a id="exdomain">Example: restricting access to a single domain</a></h3>
-
-    <p>
-      Consider a local user <code>berrange</code>
-      who has been granted permission to connect to libvirt in
-      full read-write mode. The goal is to only allow them to
-      see the domain called <code>demo</code> on the LXC driver.
-      To achieve this we need to write a rule which checks
-      whether the <code>connect_driver</code> attribute
-      is <code>LXC</code> and the <code>domain_name</code>
-      attribute is <code>demo</code>, and match on an action
-      name of <code>org.libvirt.api.domain.getattr</code>. Using
-      the javascript rules format, this ends up written as
-    </p>
-
-    <pre>
-polkit.addRule(function(action, subject) {
-    if (action.id == "org.libvirt.api.domain.getattr" &amp;&amp;
-        subject.user == "berrange") {
-          if (action.lookup("connect_driver") == 'LXC' &amp;&amp;
-              action.lookup("domain_name") == 'demo') {
-            return polkit.Result.YES;
-          } else {
-            return polkit.Result.NO;
-          }
-    }
-});
-    </pre>
-  </body>
-</html>

docs/api.html.in

@@ -1,380 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>The libvirt API concepts</h1>
-
-    <p> This page describes the main principles and architecture choices
-    behind the definition of the libvirt API:</p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="Objects">Objects Exposed</a></h2>
-    <p> As defined in the <a href="goals.html">goals section</a>, the libvirt
-    API is designed to expose all the resources needed to manage the
-    virtualization support of recent operating systems. The first object
-    manipulated through the API is the <code>virConnectPtr</code>, which
-    represents the connection to a hypervisor. Any application using libvirt
-    is likely to start using the
-    API by calling one of <a href="html/libvirt-libvirt-host.html#virConnectOpen"
-    >the virConnectOpen functions</a>. You will note that those functions take
-    a name argument which is actually a <a href="uri.html">connection URI</a>
-    to select the right hypervisor to open.
-    A URI is needed to allow remote connections and also select between
-    different possible hypervisors. For example, on a Linux system it may be
-    possible to use both KVM and LinuxContainers on the same node. A NULL
-    name will default to a preselected hypervisor, but it's probably not a
-    wise thing to do in most cases. See the <a href="uri.html">connection
-    URI</a> page for a full descriptions of the values allowed.</p>
-    <p> OnDevice the application obtains a
-      <a href="/html/libvirt-libvirt-host.html#virConnectPtr">
-        <code>virConnectPtr</code>
-      </a>
-    connection to the hypervisor it can then use it to manage the hypervisor's
-    available domains and related virtualization
-    resources, such as storage and networking. All those are
-    exposed as first class objects and connected to the hypervisor connection
-    (and the node or cluster where it is available).</p>
-    <p class="image">
-      <img alt="first class objects exposed by the API"
-           src="libvirt-object-model.png"/>
-    </p>
-    <p> The figure above shows the five main objects exported by the API:</p>
-    <ul>
-      <li>
-        <a href="html/libvirt-libvirt-host.html#virConnectPtr">
-          <code>virConnectPtr</code>
-        </a>
-      <p>Represents the connection to a hypervisor. Use one of the
-      <a href="html/libvirt-libvirt-host.html#virConnectOpen">virConnectOpen</a>
-      functions to obtain connection to the hypervisor which is then used
-      as a parameter to other connection API's.</p></li>
-      <li>
-        <a href="html/libvirt-libvirt-domain.html#virDomainPtr">
-          <code>virDomainPtr</code>
-        </a>
-      <p>Represents one domain either active or defined (i.e. existing as
-      permanent config file and storage but not currently running on that
-      node). The function
-        <a href="html/libvirt-libvirt-domain.html#virConnectListAllDomains">
-          <code>virConnectListAllDomains</code>
-        </a>
-      lists all the domains for the hypervisor.</p></li>
-      <li>
-        <a href="html/libvirt-libvirt-network.html#virNetworkPtr">
-          <code>virNetworkPtr</code>
-        </a>
-      <p>Represents one network either active or defined (i.e. existing
-      as permanent config file and storage but not currently activated).
-      The function
-        <a href="html/libvirt-libvirt-network.html#virConnectListAllNetworks">
-          <code>virConnectListAllNetworks</code>
-        </a>
-      lists all the virtualization networks for the hypervisor.</p></li>
-      <li>
-        <a href="html/libvirt-libvirt-storage.html#virStorageVolPtr">
-          <code>virStorageVolPtr</code>
-        </a>
-      <p>Represents one storage volume generally used
-      as a block device available to one of the domains. The function
-        <a href="html/libvirt-libvirt-storage.html#virStorageVolLookupByPath">
-          <code>virStorageVolLookupByPath</code>
-        </a>
-      finds the storage volume object based on its path on the node.</p></li>
-      <li>
-        <a href="html/libvirt-libvirt-storage.html#virStoragePoolPtr">
-          <code>virStoragePoolPtr</code>
-        </a>
-      <p>Represents a storage pool, which is a logical area
-      used to allocate and store storage volumes. The function
-        <a href="html/libvirt-libvirt-storage.html#virConnectListAllStoragePools">
-          <code>virConnectListAllStoragePools</code>
-        </a>
-      lists all of the virtualization storage pools on the hypervisor.
-      The function
-        <a href="html/libvirt-libvirt-storage.html#virStoragePoolLookupByVolume">
-          <code>virStoragePoolLookupByVolume</code>
-        </a>
-      finds the storage pool containing a given storage volume.</p></li>
-    </ul>
-    <p> Most objects manipulated by the library can also be represented using
-      XML descriptions. This is used primarily to create those object, but is
-      also helpful to modify or save their description back.</p>
-    <p> Domains, networks, and storage pools can be either <code>active</code>
-      i.e. either running or available for immediate use, or
-      <code>defined</code> in which case they are inactive but there is
-      a permanent definition available in the system for them. Based on this
-      they can be activated dynamically in order to be used.</p>
-    <p> Most objects can also be named in various ways:</p>
-    <ul>
-      <li><code>name</code>
-      <p>A user friendly identifier but whose uniqueness
-      cannot be guaranteed between two nodes.</p></li>
-      <li><code>ID</code>
-      <p>A runtime unique identifier
-      provided by the hypervisor for one given activation of the object;
-      however, it becomes invalid once the resource is deactivated.</p></li >
-      <li><code>UUID</code>
-      <p> A 16 byte unique identifier
-      as defined in <a href="http://www.ietf.org/rfc/rfc4122.txt">RFC 4122</a>,
-      which is guaranteed to be unique for long term usage and across a
-      set of nodes.</p></li>
-    </ul>
-
-    <h2><a id="Functions">Functions and Naming Conventions</a></h2>
-    <p> The naming of the functions present in the library is usually
-      composed by a prefix describing the object associated to the function
-      and a verb describing the action on that object.</p>
-    <p> For each first class object you will find APIs
-      for the following actions:</p>
-    <ul>
-      <li><b>Lookup</b> [...LookupBy...]
-      <p>Used to perform lookups on objects by some type of identifier,
-      such as:</p>
-          <ul>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virDomainLookupByID">
-                <code>virDomainLookupByID</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virDomainLookupByName">
-                <code>virDomainLookupByName</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virDomainLookupByUUID">
-                <code>virDomainLookupByUUID</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virDomainLookupByUUIDString">
-                <code>virDomainLookupByUUIDString</code>
-              </a>
-            </li>
-          </ul>
-      </li>
-      <li><b>Enumeration</b> [virConnectList..., virConnectNumOf...]
-      <p>Used to enumerate a set of object available to a given
-      hypervisor connection such as:</p>
-          <ul>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virConnectListDomains">
-                <code>virConnectListDomains</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-domain.html#virConnectNumOfDomains">
-                <code>virConnectNumOfDomains</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-network.html#virConnectListNetworks">
-                <code>virConnectListNetworks</code>
-              </a>
-            </li>
-            <li>
-              <a href="html/libvirt-libvirt-storage.html#virConnectListStoragePools">
-                <code>virConnectListStoragePools</code>
-              </a>
-            </li>
-          </ul>
-      </li>
-      <li><b>Description</b> [...GetInfo]
-      <p>Generic accessor providing a set of generic information about an
-      object, such as: </p>
-        <ul>
-          <li>
-            <a href="html/libvirt-libvirt-host.html#virNodeGetInfo">
-              <code>virNodeGetInfo</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainGetInfo">
-              <code>virDomainGetInfo</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-storage.html#virStoragePoolGetInfo">
-              <code>virStoragePoolGetInfo</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-storage.html#virStorageVolGetInfo">
-              <code>virStorageVolGetInfo</code>
-            </a>
-          </li>
-        </ul>
-      </li>
-      <li><b>Accessors</b> [...Get..., ...Set...]
-      <p>Specific accessors used to query or modify data for the given object,
-      such as: </p>
-        <ul>
-          <li>
-            <a href="html/libvirt-libvirt-host.html#virConnectGetType">
-              <code>virConnectGetType</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainGetMaxMemory">
-              <code>virDomainGetMaxMemory</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainSetMemory">
-              <code>virDomainSetMemory</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainGetVcpus">
-              <code>virDomainGetVcpus</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-storage.html#virStoragePoolSetAutostart">
-              <code>virStoragePoolSetAutostart</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-network.html#virNetworkGetBridgeName">
-              <code>virNetworkGetBridgeName</code>
-            </a>
-          </li>
-        </ul>
-      </li>
-      <li><b>Creation</b> [...Create, ...CreateXML]
-      <p>Used to create and start objects.  The ...CreateXML APIs will create
-      the object based on an XML description, while the ...Create APIs will
-      create the object based on existing object pointer, such as: </p>
-        <ul>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainCreate">
-              <code>virDomainCreate</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainCreateXML">
-              <code>virDomainCreateXML</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-network.html#virNetworkCreate">
-              <code>virNetworkCreate</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-network.html#virNetworkCreateXML">
-              <code>virNetworkCreateXML</code>
-            </a>
-          </li>
-        </ul>
-      </li>
-      <li><b>Destruction</b> [...Destroy]
-      <p>Used to shutdown or deactivate and destroy objects, such as: </p>
-        <ul>
-          <li>
-            <a href="html/libvirt-libvirt-domain.html#virDomainDestroy">
-              <code>virDomainDestroy</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-network.html#virNetworkDestroy">
-              <code>virNetworkDestroy</code>
-            </a>
-          </li>
-          <li>
-            <a href="html/libvirt-libvirt-storage.html#virStoragePoolDestroy">
-              <code>virStoragePoolDestroy</code>
-            </a>
-          </li>
-        </ul>
-      </li>
-    </ul>
-    <p>Note: functions returning vir*Ptr (like the virDomainLookup functions)
-    allocate memory which needs to be freed by the caller by the corresponding
-    vir*Free function (e.g. virDomainFree for a virDomainPtr object).
-    </p>
-    <p> For more in-depth details of the storage related APIs see
-      <a href="storage.html">the storage management page</a>.
-    </p>
-    <h2><a id="Drivers">The libvirt Drivers</a></h2>
-    <p>Drivers are the basic building block for libvirt functionality
-    to support the capability to handle specific hypervisor driver calls.
-    Drivers are discovered and registered during connection processing as
-    part of the
-      <a href="html/libvirt-libvirt-host.html#virInitialize">
-        <code>virInitialize</code>
-      </a>
-    API. Each driver
-    has a registration API which loads up the driver specific function
-    references for the libvirt APIs to call. The following is a simplistic
-    view of the hypervisor driver mechanism. Consider the stacked list of
-    drivers as a series of modules that can be plugged into the architecture
-    depending on how libvirt is configured to be built.</p>
-    <p class="image">
-      <img alt="The libvirt driver architecture"
-           src="libvirt-driver-arch.png"/>
-    </p>
-    <p>The driver architecture is also used to support other virtualization
-    components such as storage, storage pools, host device, networking,
-    network interfaces, and network filters.</p>
-    <p>See the <a href="drivers.html">libvirt drivers</a> page for more
-    information on hypervisor and storage specific drivers.</p>
-    <p>Not all drivers support every virtualization function possible.
-    The <a href="hvsupport.html">libvirt API support matrix</a> lists
-    the various functions and support found in each driver by the version
-    support was added into libvirt.
-    </p>
-    <h2><a id="Remote">Daemon and Remote Access</a></h2>
-    <p>Access to libvirt drivers is primarily handled by the libvirtd
-    daemon through the <a href="remote.html">remote</a> driver via an
-    <a href="internals/rpc.html">RPC</a>. Some hypervisors do support
-    client-side connections and responses, such as Test, OpenVZ, VMware,
-    VirtualBox (vbox), ESX, Hyper-V, Xen, and Virtuozzo.
-    The libvirtd daemon service is started on the host at system boot
-    time and can also be restarted at any time by a properly privileged
-    user, such as root. The libvirtd daemon uses the same libvirt API
-    <a href="html/libvirt-libvirt-host.html#virInitialize">
-      <code>virInitialize</code>
-    </a>
-    sequence as applications
-    for client-side driver registrations, but then extends the registered
-    driver list to encompass all known drivers supported for all driver
-    types supported on the host. </p>
-    <p>The libvirt client <a href="apps.html">applications</a> use a
-    <a href="uri.html">URI</a> to obtain the <code>virConnectPtr</code>.
-    The <code>virConnectPtr</code> keeps track of the driver connection
-    plus a variety of other connections (network, interface, storage, etc.).
-    The <code>virConnectPtr</code> is then used as a parameter to other
-    virtualization <a href="#Functions">functions</a>. Depending upon the
-    driver being used, calls will be routed through the remote driver to
-    the libvirtd daemon. The daemon will reference the connection specific
-    driver in order to retrieve the requested information and then pass
-    back status and/or data through the connection back to the application.
-    The application can then decide what to do with that data, such as
-    display, write log data, etc. <a href="migration.html">Migration</a>
-    is an example of many facets of the architecture in use.</p>
-
-    <p class="image">
-      <img alt="The libvirt daemon and remote architecture"
-           src="libvirt-daemon-arch.png"/>
-    </p>
-    <p>
-    The key takeaway from the above diagram is that there is a remote driver
-    which handles transactions for a majority of the drivers. The libvirtd
-    daemon running on the host will receive transaction requests from the
-    remote driver and will then query the hypervisor driver as specified in
-    the <code>virConnectPtr</code> in order to fetch the data. The data will
-    then be returned through the remote driver to the client application
-    for processing.
-    </p>
-    <p>If you are interested in contributing to libvirt, read the
-    <a href="http://wiki.libvirt.org/page/FAQ">FAQ</a> and
-    <a href="hacking.html">hacking</a> guidelines to gain an understanding
-    of basic rules and guidelines.  In order to add new API functionality
-    follow the instructions regarding
-    <a href="api_extension.html">implementing a new API in libvirt</a>.
-    </p>
-
-  </body>
-</html>

docs/api_extension.html.in

@@ -1,371 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Implementing a new API in Libvirt</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      This document walks you through the process of implementing a new
-      API in libvirt.  Remember that new API consists of any new public
-      functions, as well as the addition of flags or extensions of XML used by
-      existing functions.
-    </p>
-
-    <p>
-      Before you begin coding, it is critical that you propose your
-      changes on the libvirt mailing list and get feedback on your ideas to
-      make sure what you're proposing fits with the general direction of the
-      project.  Even before doing a proof of concept implementation, send an
-      email giving an overview of the functionality you think should be
-      added to libvirt.  Someone may already be working on the feature you
-      want.  Also, recognize that everything you write is likely to undergo
-      significant rework as you discuss it with the other developers, so
-      don't wait too long before getting feedback.
-    </p>
-
-    <p>
-      Adding a new API to libvirt is not difficult, but there are quite a
-      few steps.  This document assumes that you are familiar with C
-      programming and have checked out the libvirt code from the source code
-      repository and successfully built the existing tree.  Instructions on
-      how to check out and build the code can be found at:
-    </p>
-
-    <p>
-      <a href="https://libvirt.org/downloads.html">https://libvirt.org/downloads.html</a>
-    </p>
-
-    <p>
-      Once you have a working development environment, the steps to create a
-      new API are:
-    </p>
-    <ol>
-      <li>define the public API</li>
-      <li>define the internal driver API</li>
-      <li>implement the public API</li>
-      <li>implement the remote protocol:
-        <ol>
-          <li>define the wire protocol format</li>
-          <li>implement the RPC client</li>
-          <li>implement the server side dispatcher</li>
-        </ol>
-      </li>
-      <li>use new API where appropriate in drivers</li>
-      <li>add virsh support</li>
-      <li>add common handling for new API</li>
-      <li>for each driver that can support the new API:
-        <ol>
-          <li>add prerequisite support</li>
-          <li>fully implement new API</li>
-        </ol>
-      </li>
-    </ol>
-
-    <p>
-      It is, of course, possible to implement the pieces in any order, but
-      if the development tasks are completed in the order listed, the code
-      will compile after each step.  Given the number of changes required,
-      verification after each step is highly recommended.
-    </p>
-
-    <p>
-      Submit new code in the form of one patch per step.  That's not to say
-      submit patches before you have working functionality--get the whole thing
-      working and make sure you're happy with it.  Then use git to break the
-      changes into pieces so you don't drop a big blob of code on the
-      mailing list in one go.  Also, you should follow the upstream tree, and
-      rebase your series to adapt your patches to work with any other changes
-      that were accepted upstream during your development.
-    </p>
-
-    <p>
-      Don't mix anything else into the patches you submit.  The patches
-      should be the minimal changes required to implement the functionality
-      you're adding.  If you notice a bug in unrelated code (i.e., code you
-      don't have to touch to implement your API change) during development,
-      create a patch that just addresses that bug and submit it
-      separately.
-    </p>
-
-    <h2><a id='publicapi'>Defining the public API</a></h2>
-
-    <p>The first task is to define the public API.  If the new API
-      involves an XML extension, you have to enhance the RelaxNG
-      schema and document the new elements or attributes:</p>
-
-    <p><code>
-        docs/schemas/domaincommon.rng<br/>
-        docs/formatdomain.html.in
-    </code></p>
-
-    <p>If the API extension involves a new function, you have to add a
-      declaration in the public header, and arrange to export the
-      function name (symbol) so other programs can link against the
-      libvirt library and call the new function:</p>
-
-    <p><code>
-        include/libvirt/libvirt-$MODULE.h.in
-        src/libvirt_public.syms
-    </code></p>
-
-    <p>
-      This task is in many ways the most important to get right, since once
-      the API has been committed to the repository, it's libvirt's policy
-      never to change it.  Mistakes in the implementation are bugs that you
-      can fix.  Make a mistake in the API definition and you're stuck with
-      it, so think carefully about the interface and don't be afraid to
-      rework it as you go through the process of implementing it.
-    </p>
-
-    <h2><a id='internalapi'>Defining the internal API</a></h2>
-
-    <p>
-      Each public API call is associated with a driver, such as a host
-      virtualization driver, a network virtualization driver, a storage
-      virtualization driver, a state driver, or a device monitor.  Adding
-      the internal API is ordinarily a matter of adding a new member to the
-      struct representing one of these drivers.
-    </p>
-
-    <p>
-      Of course, it's possible that the new API will involve the creation of
-      an entirely new driver type, in which case the changes will include the
-      creation of a new struct type to represent the new driver type.
-    </p>
-
-    <p>The driver structs are defined in:</p>
-
-    <p><code>src/driver-$MODULE.h</code></p>
-
-    <p>
-      To define the internal API, first typedef the driver function
-      prototype and then add a new field for it to the relevant driver
-      struct.  Then, update all existing instances of the driver to
-      provide a <code>NULL</code> stub for the new function.
-    </p>
-
-    <h2><a id='implpublic'>Implementing the public API</a></h2>
-
-    <p>
-      Implementing the public API is largely a formality in which we wire up
-      public API to the internal driver API.  The public API implementation
-      takes care of some basic validity checks before passing control to the
-      driver implementation.  In RFC 2119 vocabulary, this function:
-    </p>
-
-    <ol class="ordinarylist">
-      <li>SHOULD log a message with VIR_DEBUG() indicating that it is
-        being called and its parameters;</li>
-      <li>MUST call virResetLastError();</li>
-      <li>SHOULD confirm that the connection is valid with
-        virCheckConnectReturn() or virCheckConnectGoto();</li>
-      <li><strong>SECURITY: If the API requires a connection with write
-          privileges, MUST confirm that the connection flags do not
-          indicate that the connection is read-only with
-          virCheckReadOnlyGoto();</strong></li>
-      <li>SHOULD do basic validation of the parameters that are being
-        passed in, using helpers like virCheckNonNullArgGoto();</li>
-      <li>MUST confirm that the driver for this connection exists and that
-        it implements this function;</li>
-      <li>MUST call the internal API;</li>
-      <li>SHOULD log a message with VIR_DEBUG() indicating that it is
-        returning, its return value, and status.</li>
-      <li>MUST return status to the caller.</li>
-    </ol>
-
-    <p>The public API calls are implemented in:</p>
-
-    <p><code>src/libvirt-$MODULE.c</code></p>
-
-    <h2><a id='remoteproto'>Implementing the remote protocol</a></h2>
-
-    <p>
-      Implementing the remote protocol is essentially a
-      straightforward exercise which is probably most easily
-      understood by referring to the existing code.
-    </p>
-
-    <h3><a id='wireproto'>Defining the wire protocol format</a></h3>
-
-    <p>
-      Defining the wire protocol involves making additions to:
-    </p>
-
-    <p><code>src/remote/remote_protocol.x</code></p>
-
-    <p>
-      First, create two new structs for each new function that you're adding
-      to the API.  One struct describes the parameters to be passed to the
-      remote function, and a second struct describes the value returned by
-      the remote function.  The one exception to this rule is that functions
-      that return only 0 or -1 for status do not require a struct for returned
-      data.
-    </p>
-
-    <p>
-      Second, add values to the remote_procedure enum for each new function
-      added to the API.
-    </p>
-
-    <p>
-      Once these changes are in place, it's necessary to run 'make rpcgen'
-      in the src directory to create the .c and .h files required by the
-      remote protocol code. This must be done on a Linux host using the
-      GLibC rpcgen program. Other rpcgen versions may generate code which
-      results in bogus compile time warnings.  This regenerates the
-      following files:
-    </p>
-
-    <p><code>
-        src/remote/remote_daemon_dispatch_stubs.h
-        src/remote/remote_daemon_dispatch.h
-        src/remote/remote_daemon_dispatch.c
-        src/remote/remote_protocol.c
-        src/remote/remote_protocol.h
-    </code></p>
-
-    <h3><a id='rpcclient'>Implement the RPC client</a></h3>
-
-    <p>
-      Implementing the RPC client uses the rpcgen generated .h files.
-      The remote method calls go in:
-    </p>
-
-    <p><code>src/remote/remote_driver.c</code></p>
-
-    <p>Each remote method invocation does the following:</p>
-
-    <ol class="ordinarylist">
-      <li>locks the remote driver;</li>
-      <li>sets up the method arguments;</li>
-      <li>invokes the remote function;</li>
-      <li>checks the return value, if necessary;</li>
-      <li>extracts any returned data;</li>
-      <li>frees any returned data;</li>
-      <li>unlocks the remote driver.</li>
-    </ol>
-
-    <h3><a id="serverdispatch">Implement the server side dispatcher</a></h3>
-
-    <p>
-      Implementing the server side of the remote function call is simply a
-      matter of deserializing the parameters passed in from the remote
-      caller and passing them to the corresponding internal API function.
-      The server side dispatchers are implemented in:
-    </p>
-
-    <p><code>src/remote/remote_daemon_dispatch.c</code></p>
-
-    <p>Again, this step uses the .h files generated by make rpcgen.</p>
-
-    <p>
-      After all three pieces of the remote protocol are complete, and
-      the generated files have been updated, it will be necessary to
-      update the file:</p>
-
-    <p><code>src/remote_protocol-structs</code></p>
-
-    <p>
-      This file should only have new lines added; modifications to
-      existing lines probably imply a backwards-incompatible API change.
-    </p>
-
-    <h2><a id="internaluseapi">Use the new API internally</a></h2>
-
-    <p>
-      Sometimes, a new API serves as a superset of existing API, by
-      adding more granularity in what can be managed.  When this is
-      the case, it makes sense to share a common implementation by
-      making the older API become a trivial wrapper around the new
-      API, rather than duplicating the common code.  This step should
-      not introduce any semantic differences for the old API, and is
-      not necessary if the new API has no relation to existing API.
-    </p>
-
-    <h2><a id="virshuseapi">Expose the new API in virsh</a></h2>
-
-    <p>
-      All new API should be manageable from the virsh command line
-      shell.  This proves that the API is sufficient for the intended
-      purpose, and helps to identify whether the proposed API needs
-      slight changes for easier usage.  However, remember that virsh
-      is used to connect to hosts running older versions of libvirtd,
-      so new commands should have fallbacks to an older API if
-      possible; implementing the virsh hooks at this point makes it
-      very easy to test these fallbacks.  Also remember to document
-      virsh additions.
-    </p>
-
-    <p>
-      A virsh command is composed of a few pieces of code.  You need to
-      define an array of vshCmdInfo structs for each new command that
-      contain the help text and the command description text.  You also need
-      an array of vshCmdOptDef structs to describe the command options.
-      Once you have those pieces in place you can write the function
-      implementing the virsh command.  Finally, you need to add the new
-      command to the commands[] array.  The following files need changes:
-    </p>
-
-    <p><code>
-        tools/virsh-$MODULE.c<br/>
-        tools/virsh.pod
-    </code></p>
-
-    <h2><a id="driverimpl">Implement the driver methods</a></h2>
-
-    <p>
-      So, after all that, we get to the fun part.  All functionality in
-      libvirt is implemented inside a driver.  Thus, here is where you
-      implement whatever functionality you're adding to libvirt.  You'll
-      either need to add additional files to the src directory or extend
-      files that are already there, depending on what functionality you're
-      adding.
-    </p>
-
-    <h3><a id="commonimpl">Implement common handling</a></h3>
-
-    <p>
-      If the new API is applicable to more than one driver, it may
-      make sense to provide some utility routines, or to factor some
-      of the work into the dispatcher, to avoid reimplementing the
-      same code in every driver.  In the example code, this involved
-      adding a member to the virDomainDefPtr struct for mapping
-      between the XML API addition and the in-memory representation of
-      a domain, along with updating all clients to use the new member.
-      Up to this point, there have been no changes to existing
-      semantics, and the new APIs will fail unless they are used in
-      the same way as the older API wrappers.
-    </p>
-
-    <h3><a id="drivercode">Implement driver handling</a></h3>
-
-    <p>
-      The remaining patches should only touch one driver at a time.
-      It is possible to implement all changes for a driver in one
-      patch, but for review purposes it may still make sense to break
-      things into simpler steps.  Here is where the new APIs finally
-      start working.
-    </p>
-
-    <p>
-      It is always a good idea to patch the test driver in addition to the
-      target driver, to prove that the API can be used for more than one
-      driver.
-    </p>
-
-    <p>
-      Any cleanups resulting from the changes should be added as separate
-      patches at the end of the series.
-    </p>
-
-    <p>
-      Once you have working functionality, run make check and make
-      syntax-check on each patch of the series before submitting
-      patches.  It may also be worth writing tests for the libvirt-TCK
-      testsuite to exercise your new API, although those patches are
-      not kept in the libvirt repository.
-    </p>
-  </body>
-</html>

docs/apps.html.in

@@ -1,481 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Applications using libvirt</h1>
-
-    <p>
-      This page provides an illustration of the wide variety of
-      applications using the libvirt management API.
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="add">Add an application</a></h2>
-
-    <p>
-      To add an application not listed on this page, send a message
-      to the <a href="contact.html">mailing list</a>, requesting it
-      be added here, or simply send a patch against the documentation
-      in the libvirt.git docs subdirectory.
-      If your application uses libvirt as its API,
-      the following graphics are available for your website to advertise
-      support for libvirt:
-    </p>
-
-    <p class="image">
-      <img src="logos/logo-square-powered-96.png" alt="libvirt powered"/>
-      <img src="logos/logo-square-powered-128.png" alt="libvirt powered"/>
-      <img src="logos/logo-square-powered-192.png" alt="libvirt powered"/>
-      <img src="logos/logo-square-powered-256.png" alt="libvirt powered"/>
-    </p>
-
-    <h2><a id="command">Command line tools</a></h2>
-
-    <dl>
-      <dt><a href="http://libguestfs.org">guestfish</a></dt>
-      <dd>
-        Guestfish is an interactive shell and command-line tool for examining
-        and modifying virtual machine filesystems.  It uses libvirt to find
-        guests and their associated disks.
-      </dd>
-      <dt>virsh</dt>
-      <dd>
-        An interactive shell, and batch scriptable tool for performing
-        management tasks on all libvirt managed domains, networks and
-        storage. This is part of the libvirt core distribution.
-      </dd>
-      <dt><a href="https://virt-manager.org/">virt-clone</a></dt>
-      <dd>
-        Allows the disk image(s) and configuration for an existing
-        virtual machine to be cloned to form a new virtual machine.
-        It automates copying of data across to new disk images, and
-        updates the UUID, MAC address, and name in the configuration.
-      </dd>
-      <dt><a href="https://people.redhat.com/rjones/virt-df/">virt-df</a></dt>
-      <dd>
-        Examine the utilization of each filesystem in a virtual machine
-        from the comfort of the host machine. This tool peeks into the
-        guest disks and determines how much space is used. It can cope
-        with common Linux filesystems and LVM volumes.
-      </dd>
-      <dt><a href="https://virt-manager.org/">virt-image</a></dt>
-      <dd>
-        Provides a way to deploy virtual appliances. It defines a
-        simplified portable XML format describing the pre-requisites
-        of a virtual machine. At time of deployment this is translated
-        into the domain XML format for execution under any libvirt
-        hypervisor meeting the pre-requisites.
-      </dd>
-      <dt><a href="https://virt-manager.org/">virt-install</a></dt>
-      <dd>
-        Provides a way to provision new virtual machines from a
-        OS distribution install tree. It supports provisioning from
-        local CD images, and the network over NFS, HTTP and FTP.
-      </dd>
-      <dt><a href="https://people.redhat.com/rjones/virt-top/">virt-top</a></dt>
-      <dd>
-        Watch the CPU, memory, network and disk utilization of all
-        virtual machines running on a host.
-      </dd>
-      <dt>
-        <a href="https://people.redhat.com/~rjones/virt-what/">virt-what</a>
-      </dt>
-      <dd>
-        virt-what is a shell script for detecting if the program is running
-        in a virtual machine.  It prints out a list of facts about the
-        virtual machine, derived from heuristics.
-      </dd>
-      <dt><a href="https://sourceware.org/systemtap/">stap</a></dt>
-      <dd>
-        SystemTap is a tool used to gather rich information about a running
-        system through the use of scripts. Starting from v2.4, the front-end
-        application stap can use libvirt to gather data within virtual
-        machines.
-      </dd>
-      <dt><a href="https://github.com/pradels/vagrant-libvirt/">vagrant-libvirt</a></dt>
-      <dd>
-        Vagrant-Libvirt is a Vagrant plugin that uses libvirt to manage virtual
-        machines. It is a command line tool for developers that makes it very
-        fast and easy to deploy and re-deploy an environment of vm's.
-      </dd>
-      <dt><a href="https://github.com/virt-lightning/virt-lightning">virt-lightning</a></dt>
-      <dd>
-        Virt-Lightning uses libvirt, cloud-init and libguestfs to allow anyone
-        to quickly start a new VM. Very much like a container CLI, but with a
-        virtual machine.
-      </dd>
-    </dl>
-
-    <h2><a id="configmgmt">Configuration Management</a></h2>
-
-    <dl>
-      <dt><a href="https://wiki.lcfg.org/bin/view/LCFG/LcfgLibvirt">LCFG</a></dt>
-      <dd>
-        LCFG is a system for automatically installing and managing the
-        configuration of large numbers of Unix systems.  It is particularly
-        suitable for sites with very diverse and rapidly changing
-        configurations.
-      </dd>
-      <dd>
-        The lcfg-libvirt package adds support for virtualized systems to
-        LCFG, with both Xen and KVM known to work.  Cloning guests is
-        supported, as are the bridged, routed, and isolated modes for
-        Virtual Networking.
-      </dd>
-    </dl>
-
-    <h2><a id="continuousintegration">Continuous Integration</a></h2>
-
-    <dl>
-      <dt><a href="http://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html">BuildBot</a></dt>
-      <dd>
-        BuildBot is a system to automate the compile/test cycle required
-        by most software projects.  CVS commits trigger new builds, run on
-        a variety of client machines.  Build status (pass/fail/etc) are
-        displayed on a web page or through other protocols.
-      </dd>
-    </dl>
-
-    <dl>
-      <dt><a href="https://wiki.jenkins-ci.org/display/JENKINS/Libvirt+Slaves+Plugin">Jenkins</a></dt>
-      <dd>
-        This plugin for Jenkins adds a way to control guest domains hosted
-        on Xen or QEMU/KVM.  You configure a Jenkins Slave,
-        selecting the guest domain and hypervisor.  When you need to build a
-        job on a specific Slave, its guest domain is started, then the job is
-        run.  When the build process is finished, the guest domain is shut
-        down, ready to be used again as required.
-      </dd>
-    </dl>
-
-    <h2><a id="conversion">Conversion</a></h2>
-
-    <dl>
-      <dt><a href="http://libguestfs.org/virt-p2v.1.html">virt-p2v</a></dt>
-      <dd>
-        Convert a physical machine to run on KVM.  It is a LiveCD
-        which is booted on the machine to be converted.  It collects a
-        little information from the user, then copies the disks over
-        to a remote machine and defines the XML for a domain to run
-        the guest.  (Note this tool is included with libguestfs)
-      </dd>
-      <dt><a href="http://libguestfs.org/virt-v2v.1.html">virt-v2v</a></dt>
-      <dd>
-        virt-v2v converts guests from a foreign hypervisor to run on
-        KVM, managed by libvirt.  It can convert guests from VMware or
-        Xen to run on OpenStack, oVirt (RHEV-M), or local libvirt.  It
-        will enable VirtIO drivers in the converted guest if possible.
-        (Note this tool is included with libguestfs)
-      </dd>
-      <dd>
-        For RHEL customers of Red Hat, conversion of Windows guests is also
-        possible.  This conversion requires some Microsoft signed pieces,
-        that Red Hat can provide.
-      </dd>
-      <dt><a href="https://launchpad.net/virt-goodies">vmware2libvirt</a></dt>
-      <dd>
-        Part of the <i>virt-goodies</i> package, vmware2libvirt is a python
-        script for migrating a vmware image to libvirt.
-      </dd>
-    </dl>
-
-    <h2><a id="desktop">Desktop applications</a></h2>
-
-    <dl>
-      <dt><a href="https://virt-manager.org/">virt-manager</a></dt>
-      <dd>
-        A general purpose desktop management tool, able to manage
-        virtual machines across both local and remotely accessed
-        hypervisors. It is targeted at home and small office usage
-        up to managing 10-20 hosts and their VMs.
-      </dd>
-      <dt><a href="https://virt-manager.org/">virt-viewer</a></dt>
-      <dd>
-        A lightweight tool for accessing the graphical console
-        associated with a virtual machine. It can securely connect
-        to remote consoles supporting the VNC protocol. Also provides
-        an optional mozilla browser plugin.
-      </dd>
-      <dt><a href="https://f1ash.github.io/qt-virt-manager">qt-virt-manager</a></dt>
-      <dd>
-        The Qt GUI for create and control VMs and another virtual entities
-        (aka networks, storages, interfaces, secrets, network filters).
-        Contains integrated LXC/SPICE/VNC viewer for accessing the graphical or
-        text console associated with a virtual machine or container.
-      </dd>
-      <dt><a href="https://f1ash.github.io/qt-virt-manager/#virtual-machines-viewer">qt-remote-viewer</a></dt>
-      <dd>
-        The Qt VNC/SPICE viewer for access to remote desktops or VMs.
-      </dd>
-    </dl>
-
-    <h2><a id="iaas">Infrastructure as a Service (IaaS)</a></h2>
-
-    <dl>
-      <dt><a href="http://cc1.ifj.edu.pl">Cracow Cloud One</a></dt>
-      <dd>The CC1 system provides a complete solution for Private
-        Cloud Computing. An intuitive web access interface with an
-        administration module and simple installation procedure make
-        it easy to benefit from private Cloud Computing technology.
-      </dd>
-
-      <dt><a href="https://github.com/eucalyptus/eucalyptus">Eucalyptus</a></dt>
-      <dd>
-        Eucalyptus is an on-premise Infrastructure as a Service cloud
-        software platform that is open source and
-        AWS-compatible. Eucalyptus uses libivrt virtualization API to
-        directly interact with Xen and KVM hypervisors.
-      </dd>
-
-      <dt><a href="http://www.nimbusproject.org">Nimbus</a></dt>
-      <dd>
-        Nimbus is an open-source toolkit focused on providing
-        Infrastructure-as-a-Service (IaaS) capabilities to the scientific
-        community.  It uses libvirt for communication with all KVM and Xen
-        virtual machines.
-      </dd>
-
-      <dt><a href="http://snooze.inria.fr">Snooze</a></dt>
-      <dd>
-        Snooze is an open-source scalable, autonomic, and energy-efficient
-        virtual machine (VM) management framework for private clouds. It
-        integrates libvirt for VM monitoring, live migration, and life-cycle
-        management.
-      </dd>
-
-      <dt><a href="https://www.openstack.org">OpenStack</a></dt>
-      <dd>
-        OpenStack is a "cloud operating system" usable for both public
-        and private clouds.  Its various parts take care of compute,
-        storage and networking resources and interface with the user
-        using a dashboard.  Compute part uses libvirt to manage VM
-        life-cycle, monitoring and so on.
-      </dd>
-
-      <dt><a href="https://github.com/gustavfranssonnyvell/cherrypop">Cherrypop</a></dt>
-      <dd>
-        A cloud software with no masters or central points. Nodes
-        autodetect other nodes and autodistribute virtual
-        machines and autodivide up the workload. Also there is no
-        minimum limit for hosts, well, one might be nice. It's
-        perfect for setting up low-end servers in a cloud or a
-        cloud where you want the most bang for the bucks.
-      </dd>
-
-      <dt><a href="http://en.zstack.io/">ZStack</a></dt>
-      <dd>
-        ZStack is an open source IaaS software that aims to automate the
-        management of all resources (compute, storage, networking, etc.) in a
-        datacenter by using APIs, thus conforming to the principles of a
-        software-defined datacenter. The key strengths of ZStack in terms of
-        management are scalability, performance, and a fast, user-friendly
-        deployment.
-      </dd>
-    </dl>
-
-    <h2><a id="libraries">Libraries</a></h2>
-
-    <dl>
-      <dt><a href="http://libguestfs.org">libguestfs</a></dt>
-      <dd>
-        A library and set of tools for accessing and modifying virtual
-        machine disk images.  It can be linked with C and C++ management
-        programs, and has bindings for Perl, Python, Ruby, Java, OCaml,
-        PHP, Haskell, and C#.
-      </dd>
-      <dd>
-        Using its FUSE module, you can also mount guest filesystems on the
-        host, and there is a subproject to allow merging changes into the
-        Windows Registry in Windows guests.
-      </dd>
-
-      <dt><a href="https://sandbox.libvirt.org">libvirt-sandbox</a></dt>
-      <dd>
-        A library and command line tools for simplifying the creation of
-        application sandboxes using virtualization technology. It currently
-        supports either KVM, QEMU or LXC as backends. Integration with
-        systemd facilitates sandboxing of system services like apache.
-      </dd>
-      <dt><a href="https://github.com/ohadlevy/virt#readme">Ruby
-          Libvirt Object bindings</a></dt>
-      <dd>
-        Allows using simple ruby objects to manipulate
-        hypervisors, guests, storage, network etc.  It is
-        based on top of
-        the <a href="https://libvirt.org/ruby">native ruby bindings</a>.
-      </dd>
-    </dl>
-
-    <h2><a id="livecd">LiveCD / Appliances</a></h2>
-
-    <dl>
-      <dt><a href="http://libguestfs.org/virt-v2v/">virt-p2v</a></dt>
-      <dd>
-        An older tool for converting a physical machine into a virtual
-        machine.  It is a LiveCD which is booted on the machine to be
-        converted.  It collects a little information from the user, then
-        copies the disks over to a remote machine and defines the XML for a
-        domain to run the guest.
-      </dd>
-    </dl>
-
-    <h2><a id="monitoring">Monitoring</a></h2>
-    <dl>
-      <dt><a href="https://collectd.org/plugins/libvirt.shtml">collectd</a></dt>
-      <dd>
-        The libvirt-plugin is part of <a href="http://collectd.org/">collectd</a>
-        and gathers statistics about virtualized guests on a system. This
-        way, you can collect CPU, network interface and block device usage
-        for each guest without installing collectd on the guest systems.
-        For a full description, please refer to the libvirt section in the
-        collectd.conf(5) manual page.
-      </dd>
-      <dt><a href="http://www.sflow.net/">Host sFlow</a></dt>
-      <dd>
-        Host sFlow is a lightweight agent running on KVM hypervisors that
-        links to libvirt library and exports standardized cpu, memory, network
-        and disk metrics for all virtual machines.
-      </dd>
-      <dt><a href="https://honk.sigxcpu.org/projects/libvirt/#munin">Munin</a></dt>
-      <dd>
-        The plugins provided by Guido Günther allow to monitor various things
-        like network and block I/O with
-        <a href="http://munin.projects.linpro.no/">Munin</a>.
-      </dd>
-      <dt><a href="http://people.redhat.com/rjones/nagios-virt/">Nagios-virt</a></dt>
-      <dd>
-        Nagios-virt is a configuration tool to add monitoring of your
-        virtualised domains to <a href="http://www.nagios.org/">Nagios</a>.
-        You can use this tool to either set up a new Nagios installation for
-        your Xen or QEMU/KVM guests, or to integrate with your existing Nagios
-        installation.
-      </dd>
-      <dt><a href="http://www.pcp.io/man/man1/pmdalibvirt.1.html">PCP</a></dt>
-      <dd>
-        The PCP libvirt PMDA (plugin) is part of the
-        <a href="http://pcp.io/">PCP</a> toolkit and provides
-        hypervisor and guest information and complete set of guest performance
-        metrics. It supports pCPU, vCPU, memory, block device, network interface,
-        and performance event metrics for each virtual guest.
-      </dd>
-    </dl>
-
-    <h2><a id="provisioning">Provisioning</a></h2>
-
-    <dl>
-      <dt><a href="https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli+Provisioning+Manager">Tivoli Provisioning Manager</a></dt>
-      <dd>
-        Part of the IBM Tivoli family, Tivoli Provisioning Manager (TPM) is
-        an IT lifecycle automation product.  It
-        <a href="http://publib.boulder.ibm.com/infocenter/tivihelp/v38r1/index.jsp?topic=/com.ibm.tivoli.tpm.apk.doc/libvirt_package.html">uses libvirt</a>
-        for communication with virtualization hosts and guest domains.
-      </dd>
-    </dl>
-
-    <dl>
-      <dt><a href="https://theforeman.org">Foreman</a></dt>
-      <dd>
-      Foreman is an open source web based application aimed to be a
-      Single Address For All Machines Life Cycle Management. Foreman:
-
-      <ul>
-          <li>Creates everything you need when adding a new machine to
-          your network, its goal being automatically managing
-          everything you would normally manage manually (DNS, DHCP,
-          TFTP, Virtual Machines,CA, CMDB...)</li>
-          <li>Integrates with Puppet (and acts as web front end to it).</li>
-          <li>Takes care of provisioning until the point puppet is
-          running, allowing Puppet to do what it does best.</li>
-          <li>Shows you Systems Inventory (based on Facter) and
-          provides real time information about hosts status based on
-          Puppet reports.</li>
-      </ul>
-      </dd>
-    </dl>
-
-
-    <h2><a id="web">Web applications</a></h2>
-
-    <dl>
-      <dt><a href="http://www.abiquo.com/">AbiCloud</a></dt>
-      <dd>
-        AbiCloud is an open source cloud platform manager which allows to
-        easily deploy a private cloud in your datacenter. One of the key
-        differences of AbiCloud is the web rich interface for managing the
-        infrastructure. You can deploy a new service just dragging and
-        dropping a VM.
-      </dd>
-      <dt><a href="https://kimchi-project.github.io/kimchi/">Kimchi</a></dt>
-      <dd>
-        Kimchi is an HTML5 based management tool for KVM. It is designed to
-        make it as easy as possible to get started with KVM and create your first guest.
-
-        Kimchi manages KVM guests through libvirt. The management interface is accessed
-        over the web using a browser that supports HTML5.
-      </dd>
-      <dt><a href="https://ovirt.org/">oVirt</a></dt>
-      <dd>
-        oVirt provides the ability to manage large numbers of virtual
-        machines across an entire data center of hosts. It integrates
-        with FreeIPA for Kerberos authentication, and in the future,
-        certificate management.
-      </dd>
-      <dt><a href="https://ispsystem.com/en/software/vmmanager">VMmanager</a></dt>
-      <dd>
-        VMmanager is a software solution for virtualization management
-        that can be used both for hosting virtual machines and
-        building a cloud.  VMmanager can manage not only one server,
-        but a large cluster of hypervisors.  It delivers a number of
-        functions, such as live migration that allows for load
-        balancing between cluster nodes, monitoring CPU, memory.
-      </dd>
-      <dt><a href="https://mist.io/">mist.io</a></dt>
-      <dd>
-        Mist.io is an open source project and a service that can assist you in
-        managing your virtual machines on a unified way, providing a simple
-        interface for all of your infrastructure (multiple public cloud
-        providers, OpenStack based public/private clouds, Docker servers, bare
-        metal servers and now KVM hypervisors).
-      </dd>
-      <dt><a href="https://ravada.upc.edu/">Ravada</a></dt>
-      <dd>
-        Ravada is an open source tool for managing Virtual Desktop
-        Infrastructure (VDI). It is very easy to install and use. Following
-        the documentation, you'll be ready to deploy virtual machines in
-        minutes. The only requirements for the users are a Web browser and
-        a lightweight remote viewer.
-      </dd>
-      <dt><a href="https://github.com/cutelyst/Virtlyst">Virtlyst</a></dt>
-      <dd>
-        Virtlyst is an open source web application built with C++11, Cutelyst and Qt.
-        It features:
-        <ul>
-          <li>Low memory usage (around 5 MiB of RAM)</li>
-          <li>Look and feel easily customized with HTML templates that use the Django syntax</li>
-          <li>VNC/Spice console directly in the browser using websockets on the same HTTP port</li>
-          <li>Host and Domain statistics graphs (CPU, Memory, IO, Network)</li>
-          <li>Connect to multiple libvirtd instances (over local Unix domain socket, SSH, TCP and TLS)</li>
-          <li>Manage Storage Pools, Storage Volumes, Networks, Interfaces, and Secrets</li>
-          <li>Create and launch VMs</li>
-          <li>Configure VMs with easy panels or go pro and edit the VM's XML</li>
-        </ul>
-      </dd>
-    </dl>
-
-    <h2><a id="other">Other</a></h2>
-
-    <dl>
-      <dt><a href="https://cuckoosandbox.org/">Cuckoo Sandbox</a></dt>
-      <dd>
-        Cuckoo Sandbox is a malware analysis system.  You can throw
-        any suspicious file at it and in a matter of seconds Cuckoo
-        will provide you back some detailed results outlining what
-        such file did when executed inside an isolated environment.
-        And libvirt is one of the backends that can be used for the
-        isolated environment.
-      </dd>
-    </dl>
-
-  </body>
-</html>

docs/architecture.fig

@@ -1,87 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter
-100.00
-Single
--2
-1200 2
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 1050 7500 9375 7500 9375 8700 1050 8700 1050 7500
-2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
-	 3525 7275 3525 4125 1050 4125 1050 7275 3525 7275
-2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
-	 1050 6540 3540 6525
-2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
-	 1590 6900 1590 6645 1140 6645 1140 6900 1590 6900
-2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
-	 1590 7185 1590 6930 1140 6930 1140 7185 1590 7185
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
-	1 1 2.00 120.00 240.00
-	1 1 2.00 120.00 240.00
-	 1875 7725 8625 7725
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 1650 5625 3000 5625 3000 6375 1650 6375 1650 5625
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 2850 7725 2850 6375
-2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
-	 6450 7275 6450 4125 3975 4125 3975 7275 6450 7275
-2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
-	 9300 7275 9300 4125 6825 4125 6825 7275 9300 7275
-2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
-	 3975 6540 6465 6525
-2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
-	 6825 6540 9315 6525
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 5400 7725 5400 7050
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 8025 7725 8025 7050
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 1050 8925 9375 8925 9375 9900 1050 9900 1050 8925
-2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
-	 2100 4575 3450 4575 3450 5325 2100 5325 2100 4575
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 3225 5325 3225 8325
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 6225 6900 6225 8250
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 8925 6900 8925 8250
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 1725 7125 1725 8325
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
-	1 1 2.00 120.00 240.00
-	1 1 2.00 120.00 240.00
-	 2850 5850 2850 5025
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 5175 8475 5175 9375
-2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 1350 7125 1350 9450
-2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
-	1 1 2.00 120.00 240.00
-	 2325 7725 2325 7200
-2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 1
-	 900 3975
-2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 1
-	 9525 9975
-4 0 0 50 -1 0 18 0.0000 4 195 870 4350 7980 XenBus\001
-4 0 0 50 -1 0 18 0.0000 4 195 780 1680 6870 drivers\001
-4 0 0 50 -1 0 18 0.0000 4 195 1050 1800 6075 XenStore\001
-4 0 0 50 -1 0 18 0.0000 4 195 900 1875 7125 Kernel0\001
-4 0 0 50 -1 0 18 0.0000 4 195 960 4875 6975 KernelU\001
-4 0 0 50 -1 0 18 0.0000 4 195 960 7650 6975 KernelU\001
-4 0 0 50 -1 0 18 0.0000 4 255 1740 4050 8400 Xen Hypervisor\001
-4 0 0 50 -1 0 18 0.0000 4 195 585 2325 4950 Xend\001
-4 0 0 50 -1 0 18 0.0000 4 195 690 1200 4725 Dom0\001
-4 0 0 50 -1 0 18 0.0000 4 195 750 4875 5325 DomU\001
-4 0 0 50 -1 0 18 0.0000 4 195 750 7650 5325 DomU\001
-4 0 0 50 -1 0 18 0.0000 4 195 1080 3750 9450 Hardware\001

docs/architecture.html.in

@@ -1,82 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1 >libvirt architecture</h1>
-
-    <p>
-      Currently libvirt supports 2 kind of virtualization, and its
-      internal structure is based on a driver model which simplifies
-      adding new
-      engines:
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="Xen">Xen support</a></h2>
-
-    <p>When running in a Xen environment, programs using libvirt have to execute
-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 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 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>
-
-    <p>The model for QEMU and KVM is completely similar, basically KVM is based
-on QEMU for the process controlling a new domain, only small details differs
-between the two. In both case the libvirt API is provided by a controlling
-process forked by libvirt in the background and which launch and control the
-QEMU or KVM process. That program called libvirt_qemud talks though a specific
-protocol to the library, and connects to the console of the QEMU process in
-order to control and report on its status. Libvirt tries to expose all the
-emulations models of QEMU, the selection is done when creating the new
-domain, by specifying the architecture and machine type targeted.</p>
-    <p>The code controlling the QEMU process is available in the
-<code>qemud/</code> directory.</p>
-
-    <h2><a id="drivers">Driver based architecture</a></h2>
-
-    <p>As the previous section explains, libvirt can communicate using different
-channels with the current hypervisor, and should also be able to use
-different kind of hypervisor. To simplify the internal design, code, ease
-maintenance and simplify the support of other virtualization engine the
-internals have been structured as one core component, the libvirt.c module
-acting as a front-end for the library API and a set of hypervisor drivers
-defining a common set of routines. That way the Xen Daemon access, the Xen
-Store one, the Hypervisor hypercall are all isolated in separate C modules
-implementing at least a subset of the common operations defined by the
-drivers present in driver.h:</p>
-    <ul>
-      <li>xend_internal: implements the driver functions though the Xen
-  Daemon</li>
-      <li>xs_internal: implements the subset of the driver available though the
-    Xen Store</li>
-      <li>xen_internal: provide the implementation of the functions possible via
-    direct hypervisor access</li>
-      <li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
-    is in the <code>proxy/</code> directory.</li>
-      <li>xm_internal: provide support for Xen defined but not running
-    domains.</li>
-      <li>qemu_internal: implement the driver functions for QEMU and
-    KVM virtualization engines. It also uses a qemud/ specific daemon
-    which interacts with the QEMU process to implement libvirt API.</li>
-      <li>test: this is a test driver useful for regression tests of the
-    front-end part of libvirt.</li>
-    </ul>
-    <p>Note that a given driver may only implement a subset of those functions,
-(for example saving a Xen domain state to disk and restoring it is only
-possible though the Xen Daemon), in that case the driver entry points for
-unsupported functions are initialized to NULL.</p>
-    <p></p>
-  </body>
-</html>

docs/auditlog.html.in

@@ -1,375 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Audit log</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="intro">Introduction</a></h2>
-
-    <p>
-      A number of the libvirt virtualization drivers (QEMU/KVM and LXC) include
-      support for logging details of important operations to the host's audit
-      subsystem. This provides administrators / auditors with a canonical historical
-      record of changes to virtual machines' / containers' lifecycle states and
-      their configuration. On hosts which are running the Linux audit daemon,
-      the logs will usually end up in <code>/var/log/audit/audit.log</code>
-    </p>
-
-    <h2><a id="config">Configuration</a></h2>
-
-    <p>
-      The libvirt audit integration is enabled by default on any host which has
-      the Linux audit subsystem active, and disabled otherwise. It is possible
-      to alter this behaviour in the <code>/etc/libvirt/libvirtd.conf</code>
-      configuration file, via the <code>audit_level</code> parameter
-    </p>
-
-    <ul>
-      <li><code>audit_level=0</code> - libvirt auditing is disabled regardless
-        of host audit subsystem enablement.</li>
-      <li><code>audit_level=1</code> - libvirt auditing is enabled if the host
-        audit subsystem is enabled, otherwise it is disabled. This is the
-        default behaviour.</li>
-      <li><code>audit_level=2</code> - libvirt auditing is enabled regardless
-        of host audit subsystem enablement. If the host audit subsystem is
-        disabled, then libvirtd will refuse to complete startup and exit with
-        an error.</li>
-    </ul>
-
-    <p>
-      In addition to have formal messages sent to the audit subsystem it is
-      possible to tell libvirt to inject messages into its own logging
-      layer. This will result in messages ending up in the systemd journal
-      or <code>/var/log/libvirt/libivrtd.log</code> on non-systemd hosts.
-      This is disabled by default, but can be requested by setting the
-      <code>audit_logging=1</code> configuration parameter in the same file
-      mentioned above.
-    </p>
-
-    <h2><a id="types">Message types</a></h2>
-
-    <p>
-      Libvirt defines three core audit message types each of which will
-      be described below. There are a number of common fields that will
-      be reported for all message types.
-    </p>
-
-    <dl>
-      <dt><code>pid</code></dt>
-      <dd>Process ID of the libvirtd daemon generating the audit record.</dd>
-      <dt><code>uid</code></dt>
-      <dd>User ID of the libvirtd daemon process generating the audit record.</dd>
-      <dt><code>subj</code></dt>
-      <dd>Security context of the libvirtd daemon process generating the audit record.</dd>
-      <dt><code>msg</code></dt>
-      <dd>String containing a list of key=value pairs specific to the type of audit record being reported.</dd>
-    </dl>
-
-    <p>
-      Some fields in the <code>msg</code> string are common to audit records
-    </p>
-
-    <dl>
-      <dt><code>virt</code></dt>
-      <dd>Type of virtualization driver used. One of <code>qemu</code> or <code>lxc</code></dd>
-      <dt><code>vm</code></dt>
-      <dd>Host driver unique name of the guest</dd>
-      <dt><code>uuid</code></dt>
-      <dd>Globally unique identifier for the guest</dd>
-      <dt><code>exe</code></dt>
-      <dd>Path of the libvirtd daemon</dd>
-      <dt><code>hostname</code></dt>
-      <dd>Currently unused</dd>
-      <dt><code>addr</code></dt>
-      <dd>Currently unused</dd>
-      <dt><code>terminal</code></dt>
-      <dd>Currently unused</dd>
-      <dt><code>res</code></dt>
-      <dd>Result of the action, either <code>success</code> or <code>failed</code></dd>
-    </dl>
-
-    <h3><a id="typecontrol">VIRT_CONTROL</a></h3>
-
-    <p>
-      Reports change in the lifecycle state of a virtual machine. The <code>msg</code>
-      field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>op</code></dt>
-      <dd>Type of operation performed. One of <code>start</code>, <code>stop</code> or <code>init</code></dd>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the operation to happen</dd>
-      <dt><code>vm-pid</code></dt>
-      <dd>ID of the primary/leading process associated with the guest</dd>
-      <dt><code>init-pid</code></dt>
-      <dd>ID of the <code>init</code> process in a container. Only if <code>op=init</code> and <code>virt=lxc</code></dd>
-      <dt><code>pid-ns</code></dt>
-      <dd>Namespace ID of the <code>init</code> process in a container. Only if <code>op=init</code> and <code>virt=lxc</code></dd>
-    </dl>
-
-    <h3><a id="typemachine">VIRT_MACHINE_ID</a></h3>
-
-    <p>
-      Reports the association of a security context with a guest. The <code>msg</code>
-      field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>model</code></dt>
-      <dd>The security driver type. One of <code>selinux</code> or <code>apparmor</code></dd>
-      <dt><code>vm-ctx</code></dt>
-      <dd>Security context for the guest process</dd>
-      <dt><code>img-ctx</code></dt>
-      <dd>Security context for the guest disk images and other assigned host resources</dd>
-    </dl>
-
-    <h3><a id="typeresource">VIRT_RESOURCE</a></h3>
-
-    <p>
-      Reports the usage of a host resource by a guest. The fields include will
-      vary according to the type of device being reported. When the guest is
-      initially booted records will be generated for all assigned resources.
-      If any changes are made to the running guest configuration, for example
-      hotplug devices, or adjust resources allocation, further records will
-      be generated.
-    </p>
-
-    <h4><a id="typeresourcevcpu">Virtual CPU</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>vcpu</code></dd>
-      <dt><code>old-vcpu</code></dt>
-      <dd>Original vCPU count, or 0</dd>
-      <dt><code>new-vcpu</code></dt>
-      <dd>Updated vCPU count</dd>
-    </dl>
-
-
-    <h4><a id="typeresourcemem">Memory</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>mem</code></dd>
-      <dt><code>old-mem</code></dt>
-      <dd>Original memory size in bytes, or 0</dd>
-      <dt><code>new-mem</code></dt>
-      <dd>Updated memory size in bytes</dd>
-    </dl>
-
-    <h4><a id="typeresourcedisk">Disk</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>disk</code></dd>
-      <dt><code>old-disk</code></dt>
-      <dd>Original host file or device path acting as the disk backing file</dd>
-      <dt><code>new-disk</code></dt>
-      <dd>Updated host file or device path acting as the disk backing file</dd>
-    </dl>
-
-    <h4><a id="typeresourcenic">Network interface</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>net</code></dd>
-      <dt><code>old-net</code></dt>
-      <dd>Original MAC address of the guest network interface</dd>
-      <dt><code>new-net</code></dt>
-      <dd>Updated MAC address of the guest network interface</dd>
-    </dl>
-
-    <p>
-      If there is a host network interface associated with the guest NIC then
-      further records may be generated
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>net</code></dd>
-      <dt><code>net</code></dt>
-      <dd>MAC address of the host network interface</dd>
-      <dt><code>rdev</code></dt>
-      <dd>Name of the host network interface</dd>
-    </dl>
-
-    <h4><a id="typeresourcefs">Filesystem</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>fs</code></dd>
-      <dt><code>old-fs</code></dt>
-      <dd>Original host directory, file or device path backing the filesystem </dd>
-      <dt><code>new-fs</code></dt>
-      <dd>Updated host directory, file or device path backing the filesystem</dd>
-    </dl>
-
-    <h4><a id="typeresourcehost">Host device</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>hostdev</code> or <code>dev</code></dd>
-      <dt><code>dev</code></dt>
-      <dd>The unique bus identifier of the USB, PCI or SCSI device, if <code>resrc=dev</code></dd>
-      <dt><code>disk</code></dt>
-      <dd>The path of the block device assigned to the guest, if <code>resrc=hostdev</code></dd>
-      <dt><code>chardev</code></dt>
-      <dd>The path of the character device assigned to the guest, if <code>resrc=hostdev</code></dd>
-    </dl>
-
-    <h4><a id="typeresourcetpm">TPM</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>tpm</code> or <code>tpm-emulator</code></dd>
-      <dt><code>device</code></dt>
-      <dd>The path of the host TPM device assigned to the guest</dd>
-    </dl>
-
-    <h4><a id="typeresourcerng">RNG</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>rng</code></dd>
-      <dt><code>old-rng</code></dt>
-      <dd>Original path of the host entropy source for the RNG</dd>
-      <dt><code>new-rng</code></dt>
-      <dd>Updated path of the host entropy source for the RNG</dd>
-    </dl>
-
-    <h4><a id="typeresourcechardev">console/serial/parallel/channel</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>chardev</code></dd>
-      <dt><code>old-chardev</code></dt>
-      <dd>Original path of the backing character device for given emulated device</dd>
-      <dt><code>new-chardev</code></dt>
-      <dd>Updated path of the backing character device for given emulated device</dd>
-    </dl>
-
-    <h4><a id="typeresourcesmartcard">smartcard</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>smartcard</code></dd>
-      <dt><code>old-smartcard</code></dt>
-      <dd>Original path of the backing character device, certificate store or
-          "nss-smartcard-device" for host smartcard passthrough.
-      </dd>
-      <dt><code>new-smartcard</code></dt>
-      <dd>Updated path of the backing character device, certificate store or
-          "nss-smartcard-device" for host smartcard passthrough.
-      </dd>
-    </dl>
-
-    <h4><a id="typeresourceredir">Redirected device</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>redir</code></dd>
-      <dt><code>bus</code></dt>
-      <dd>The bus type, only <code>usb</code> allowed</dd>
-      <dt><code>device</code></dt>
-      <dd>The device type, only <code>USB redir</code> allowed</dd>
-    </dl>
-
-    <h4><a id="typeresourcecgroup">Control group</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>cgroup</code></dd>
-      <dt><code>cgroup</code></dt>
-      <dd>The name of the cgroup controller</dd>
-    </dl>
-
-
-    <h4><a id="typeresourceshmem">Shared memory</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt><code>resrc</code></dt>
-      <dd>The type of resource assigned. Set to <code>shmem</code></dd>
-      <dt><code>reason</code></dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt><code>size</code></dt>
-      <dd>The size of the shared memory region</dd>
-      <dt><code>shmem</code></dt>
-      <dd>Name of the shared memory region</dd>
-      <dt><code>source</code></dt>
-      <dd>Path of the backing character device for given emulated device</dd>
-    </dl>
-
-  </body>
-</html>

docs/auth.html.in

@@ -1,366 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Connection authentication</h1>
-    <p>
-      When connecting to libvirt, some connections may require client
-      authentication before allowing use of the APIs. The set of possible
-      authentication mechanisms is administrator controlled, independent
-      of applications using libvirt. Once authenticated, libvirt can apply
-      fine grained <a href="acl.html">access control</a> to the operations
-      performed by a client.
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="Auth_client_config">Client configuration</a></h2>
-
-    <p>
-      When connecting to a remote hypervisor which requires authentication,
-most libvirt applications will prompt the user for the credentials. It is
-also possible to provide a client configuration file containing all the
-authentication credentials, avoiding any interaction. Libvirt will look
-for the authentication file using the following sequence:
-    </p>
-    <ol>
-      <li>The file path specified by the $LIBVIRT_AUTH_FILE environment
-        variable.</li>
-      <li>The file path specified by the "authfile=/some/file" URI
-        query parameter</li>
-      <li>The file $XDG_CONFIG_HOME/libvirt/auth.conf</li>
-      <li>The file /etc/libvirt/auth.conf</li>
-    </ol>
-
-    <p>
-      The auth configuration file uses the traditional <code>".ini"</code>
-      style syntax. There are two types of groups that can be present in
-      the config. First there are one or more <strong>credential</strong>
-      sets, which provide the actual authentication credentials. The keys
-      within the group may be:
-    </p>
-
-    <ul>
-      <li><code>username</code>: the user login name to act as. This
-        is relevant for ESX, Xen, HyperV and SSH, but probably not
-        the one you want to libvirtd with SASL.</li>
-      <li><code>authname</code>: the name to authorize as. This is
-        what is commonly required for libvirtd with SASL.</li>
-      <li><code>password</code>: the secret password</li>
-      <li><code>realm</code>: the domain realm for SASL, mostly
-        unused</li>
-    </ul>
-
-    <p>
-      Each set of credentials has a name, which is part of the group
-      entry name. Overall the syntax is
-    </p>
-
-    <pre>
-[credentials-$NAME]
-credname1=value1
-credname2=value2</pre>
-
-    <p>
-      For example, to define two sets of credentials used for production
-      and test machines, using libvirtd, and a further ESX server for dev:
-    </p>
-<pre>
-[credentials-test]
-authname=fred
-password=123456
-
-[credentials-prod]
-authname=bar
-password=letmein
-
-[credentials-dev]
-username=joe
-password=hello
-
-[credentials-defgrp]
-username=defuser
-password=defpw</pre>
-
-    <p>
-      The second set of groups provide mappings of credentials to
-      specific machine services. The config file group names compromise
-      the service type and host:
-    </p>
-
-    <pre>
-[auth-$SERVICE-$HOSTNAME]
-credentials=$CREDENTIALS</pre>
-
-    <p>
-      For example, following the previous example, here is how to
-      map some machines. For convenience libvirt supports a default
-      mapping of credentials to machines:
-    </p>
-
-    <pre>
-[auth-libvirt-test1.example.com]
-credentials=test
-
-[auth-libvirt-test2.example.com]
-credentials=test
-
-[auth-libvirt-demo3.example.com]
-credentials=test
-
-[auth-libvirt-prod1.example.com]
-credentials=prod
-
-[auth-libvirt-default]
-credentials=defgrp
-
-[auth-esx-dev1.example.com]
-credentials=dev
-
-[auth-esx-default]
-credentials=defgrp</pre>
-
-
-    <p>
-      The following service types are known to libvirt
-    </p>
-
-    <ol>
-      <li><code>libvirt</code> - used for connections to a libvirtd
-        server, which is configured with SASL auth</li>
-      <li><code>ssh</code> - used for connections to a Phyp server
-        over SSH, but the Phyp driver has been removed</li>
-      <li><code>esx</code> - used for connections to an ESX or
-        VirtualCenter server</li>
-    </ol>
-
-    <p>
-      Applications using libvirt are free to use this same configuration
-      file for storing other credentials. For example, it can be used
-      to storage VNC or SPICE login credentials
-    </p>
-
-    <h2><a id="ACL_server_config">Server configuration</a></h2>
-    <p>
-The libvirt daemon allows the administrator to choose the authentication
-mechanisms used for client connections on each network socket independently.
-This is primarily controlled via the libvirt daemon master config file in
-<code>/etc/libvirt/libvirtd.conf</code>. Each of the libvirt sockets can
-have its authentication mechanism configured independently. There is
-currently a choice of <code>none</code>, <code>polkit</code>, and <code>sasl</code>.
-The SASL scheme can be further configured to choose between a large
-number of different mechanisms.
-</p>
-    <h2><a id="ACL_server_unix_perms">UNIX socket permissions/group</a></h2>
-    <p>
-If libvirt does not contain support for PolicyKit, then access control for
-the UNIX domain socket is done using traditional file user/group ownership
-and permissions. There are 2 sockets, one for full read-write access, the
-other for read-only access. The RW socket will be restricted (mode 0700) to
-only allow the <code>root</code> user to connect. The read-only socket will
-be open access (mode 0777) to allow any user to connect.
-</p>
-    <p>
-To allow non-root users greater access, the <code>libvirtd.conf</code> file
-can be edited to change the permissions via the <code>unix_sock_rw_perms</code>,
-config parameter and to set a user group via the <code>unix_sock_group</code>
-parameter. For example, setting the former to mode <code>0770</code> and the
-latter <code>wheel</code> would let any user in the wheel group connect to
-the libvirt daemon.
-</p>
-    <h2><a id="ACL_server_polkit">UNIX socket PolicyKit auth</a></h2>
-    <p>
-If libvirt contains support for PolicyKit, then access control options are
-more advanced. The <code>auth_unix_rw</code> parameter will default to
-<code>polkit</code>, and the file permissions will default to <code>0777</code>
-even on the RW socket. Upon connecting to the socket, the client application
-will be required to identify itself with PolicyKit. The default policy for the
-RW daemon socket will require any application running in the current desktop
-session to authenticate using the user's password. This is akin to <code>sudo</code>
-auth, but does not require that the client application ultimately run as root.
-Default policy will still allow any application to connect to the RO socket.
-</p>
-    <p>
-The default policy can be overridden by creating a new policy file in the
-<code>/etc/polkit-1/rules.d</code> directory. Information on the options
-available can be found by reading the <code>polkit(8)</code> man page. The
-two libvirt actions are named <code>org.libvirt.unix.manage</code> for full
-management access, and <code>org.libvirt.unix.monitor</code> for read-only
-access.
-</p>
-    <p>
-As an example, creating <code>/etc/polkit-1/rules.d/80-libvirt-manage.rules</code>
-with the following gives the user <code>fred</code> full management access
-when accessing from an active local session:
-    </p>
-<pre>polkit.addRule(function(action, subject) {
-  if (action.id == "org.libvirt.unix.manage" &amp;&amp;
-      subject.local &amp;&amp; subject.active &amp;&amp; subject.user == "fred") {
-      return polkit.Result.YES;
-  }
-});</pre>
-    <p>
-Older versions of PolicyKit used policy files ending with .pkla in the
-local override directory <code>/etc/polkit-1/localauthority/50-local.d/</code>.
-Compatibility with this older format is provided by <a
-href="https://pagure.io/polkit-pkla-compat">polkit-pkla-compat</a>. As an
-example, this gives the user <code>fred</code> full management access:
-    </p>
-<pre>[Allow fred libvirt management permissions]
-Identity=unix-user:fred
-Action=org.libvirt.unix.manage
-ResultAny=yes
-ResultInactive=yes
-ResultActive=yes</pre>
-    <h2><a id="ACL_server_sasl">SASL pluggable authentication</a></h2>
-
-    <p>
-Libvirt integrates with the cyrus-sasl library to provide a pluggable authentication
-system using the SASL protocol. SASL can be used in combination with libvirtd's TLS
-or TCP socket listeners. When used with the TCP listener, the SASL mechanism is
-rqeuired to provide session encryption in addition to authentication. Only a very
-few SASL mechanisms are able to do this, and of those that can do it, only the
-GSSAPI plugin is considered acceptably secure by modern standards:
-    </p>
-
-    <dl>
-      <dt>GSSAPI</dt>
-      <dd><strong>This is the current default mechanism to use with libvirtd</strong>.
-        It uses the Kerberos v5 authentication protocol underneath, and assuming
-        the Kerberos client/server are configured with modern ciphers (AES),
-        it provides strong session encryption capabilities.</dd>
-
-      <dt>DIGEST-MD5</dt>
-      <dd>This was previously set as the default mechanism to use with libvirtd.
-        It provides a simple username/password based authentication mechanism
-        that includes session encryption.
-        <a href="https://tools.ietf.org/html/rfc6331">RFC 6331</a>, however,
-        documents a number of serious security flaws with DIGEST-MD5 and as a
-        result marks it as <code>OBSOLETE</code>. Specific concerns are that
-        it is vulnerable to MITM attacks and the MD5 hash can be brute-forced
-        to reveal the password. A replacement is provided via the SCRAM mechanism,
-        however, note that this does not provide encryption, so the SCRAM
-        mechanism can only be used on the libvirtd TLS listener.
-      </dd>
-
-      <dt>PASSDSS-3DES-1</dt>
-      <dd>This provides a simple username/password based authentication
-        mechanism that includes session encryption. The current cyrus-sasl
-        implementation does not provide a way to validate the server's
-        public key identity, thus it is susceptible to a MITM attacker
-        impersonating the server. It is also not enabled in many OS
-        distros when building SASL libraries.</dd>
-
-      <dt>KERBEROS_V4</dt>
-      <dd>This uses the obsolete Kerberos v4 protocol to provide both authentication
-        and session encryption. Kerberos v4 protocol has been obsolete since the
-        early 1990's and has known security vulnerabilities so this will never be
-        used in practice.</dd>
-    </dl>
-
-    <p>
-      Other SASL mechanisms, not listed above, can only be used when the libvirtd
-      TLS or UNIX socket listeners.
-    </p>
-
-    <h3><a id="ACL_server_username">Username/password auth</a></h3>
-    <p>
-As noted above, the DIGEST-MD5 mechanism is considered obsolete and should
-not be used anymore. To provide a simple username/password auth scheme on
-the libvirt UNIX socket or TLS listeners, however, it is possible to use
-the SCRAM mechanism. The <code>auth_unix_ro</code>, <code>auth_unix_rw</code>,
-<code>auth_tls</code> config params in <code>libvirt.conf</code> can be used
-to turn on SASL auth in these listeners.
-    </p>
-    <p>
-Since the libvirt SASL config file defaults to using GSSAPI (Kerberos), a
-config change is required to enable plain password auth. This is done by
-editting <code>/etc/sasl2/libvirt.conf</code> to set the <code>mech_list</code>
-parameter to <code>scram-sha-1</code>.
-    </p>
-    <p>
-Out of the box, no user accounts are defined, so no clients will be able to authenticate
-on the TCP socket. Adding users and setting their passwords is done with the <code>saslpasswd2</code>
-command. When running this command it is important to tell it that the appname is <code>libvirt</code>.
-As an example, to add a user <code>fred</code>, run
-</p>
-    <pre>
-# saslpasswd2 -a libvirt fred
-Password: xxxxxx
-Again (for verification): xxxxxx
-</pre>
-    <p>
-To see a list of all accounts the <code>sasldblistusers2</code> command can be used.
-This command expects to be given the path to the libvirt user database, which is kept
-in <code>/etc/libvirt/passwd.db</code>
-</p>
-    <pre>
-# sasldblistusers2 -f /etc/libvirt/passwd.db
-fred@t60wlan.home.berrange.com: userPassword
-</pre>
-    <p>
-Finally, to disable a user's access, the <code>saslpasswd2</code> command can be used
-again:
-</p>
-    <pre>
-# saslpasswd2 -a libvirt -d fred
-</pre>
-    <h3><a id="ACL_server_kerberos">GSSAPI/Kerberos auth</a></h3>
-    <p>
-The plain TCP listener of the libvirt daemon defaults to using SASL for authentication.
-The libvirt SASL config also defaults to GSSAPI, so there is no need to edit the
-SASL config when using GSSAPI. If the libvirtd TLS or UNIX listeners are used,
-then the Kerberos session encryption will be disabled since it is not required
-in these scenarios - only the plain TCP listener needs encryption
-</p>
-    <p>
-Some operating systems do not install the SASL kerberos plugin by default. It
-may be necessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>.
-To check whether the Kerberos plugin is installed run the <code>pluginviewer</code>
-program and verify that <code>gssapi</code> is listed, e.g.:
-</p>
-    <pre>
-# pluginviewer
-...snip...
-Plugin "gssapiv2" [loaded],     API version: 4
-        SASL mechanism: GSSAPI, best SSF: 56
-        security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
-        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN
-</pre>
-    <p>
-Next it is necessary for the administrator of the Kerberos realm to
-issue a principal for the libvirt server. There needs to be one
-principal per host running the libvirt daemon. The principal should be
-named <code>libvirt/full.hostname@KERBEROS.REALM</code>.  This is
-typically done by running the <code>kadmin.local</code> command on the
-Kerberos server, though some Kerberos servers have alternate ways of
-setting up service principals.  Once created, the principal should be
-exported to a keytab, copied to the host running the libvirt daemon
-and placed in <code>/etc/libvirt/krb5.tab</code>
-</p>
-    <pre>
-# kadmin.local
-kadmin.local: add_principal libvirt/foo.example.com
-Enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
-Re-enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
-Principal "libvirt/foo.example.com@EXAMPLE.COM" created.
-
-kadmin.local:  ktadd -k /root/libvirt-foo-example.tab libvirt/foo.example.com@EXAMPLE.COM
-Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/root/libvirt-foo-example.tab.
-Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
-Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES with HMAC/sha1 added to keytab WRFILE:/root/libvirt-foo-example.tab.
-Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
-
-kadmin.local: quit
-
-# scp /root/libvirt-foo-example.tab root@foo.example.com:/etc/libvirt/krb5.tab
-# rm /root/libvirt-foo-example.tab
-</pre>
-    <p>
-Any client application wishing to connect to a Kerberos enabled libvirt server
-merely needs to run <code>kinit</code> to gain a user principal. This may well
-be done automatically when a user logs into a desktop session, if PAM is set up
-to authenticate against Kerberos.
-</p>
-  </body>
-</html>

docs/bindings.html.in

@@ -1,101 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1 >Bindings for other languages and integration API modules</h1>
-
-    <p>
-      Libvirt supports C and C++ directly, and has bindings available
-      for other languages:
-    </p>
-
-    <ul>
-      <li>
-        <strong>C#</strong>: Arnaud Champion develops
-        <a href="csharp.html">C# bindings</a>.
-      </li>
-     <li>
-        <strong>Go</strong>: Daniel Berrange develops
-        <a href="https://godoc.org/github.com/libvirt/libvirt-go">Go bindings</a>.
-      </li>
-      <li>
-        <strong>Java</strong>: Daniel Veillard develops
-        <a href="java.html">Java bindings</a>.
-      </li>
-      <li>
-        <strong>OCaml</strong>: Richard Jones develops
-        <a href="https://libvirt.org/ocaml/">OCaml bindings</a>.
-      </li>
-      <li>
-        <strong>Perl</strong>: Daniel Berrange develops
-        <a href="http://search.cpan.org/dist/Sys-Virt/">Perl bindings</a>.
-      </li>
-      <li>
-        <p>
-          <strong>PHP</strong>: Radek Hladik started developing
-          <a href="https://libvirt.org/php">PHP bindings</a> in 2010.
-        </p>
-        <p>
-          In February 2011 the binding development has been moved to the libvirt.org website as
-          libvirt-php project.
-        </p>
-        <p>
-          The project is now maintained by Michal Novotny and it's heavily based
-          on Radek's version. For more information, including
-          information on posting patches to libvirt-php, please refer
-          to the <a href="https://libvirt.org/php">PHP bindings</a> site.
-        </p>
-      </li>
-      <li>
-        <p>
-          <strong>Python</strong>: Libvirt's python bindings are split to a
-          separate <a href="https://libvirt.org/git/?p=libvirt-python.git">package</a>
-          since version 1.2.0, older versions came with direct support for the
-          Python language.
-        </p>
-        <p>
-          If your libvirt is installed as packages, rather than compiled
-          by you from source code, ensure you have the appropriate
-          package installed.
-        </p>
-        <p>
-          This is named <b>libvirt-python</b> on RHEL/Fedora,
-          <a href="http://packages.ubuntu.com/search?keywords=python-libvirt"><b>python-libvirt</b></a>
-          on Ubuntu, and may be named differently on others.
-        </p>
-        <p>
-          For usage information, see the
-          <a href="python.html">Python API bindings</a> page.
-        </p>
-      </li>
-      <li>
-        <strong>Ruby</strong>: Chris Lalancette develops
-        <a href="https://libvirt.org/ruby/">Ruby bindings</a>.
-      </li>
-    </ul>
-
-    <p>
-      Integration API modules:
-    </p>
-
-    <ul>
-      <li>
-        <strong>D-Bus</strong>: Pavel Hrdina develops
-        <a href="dbus.html">D-Bus API</a>.
-      </li>
-    </ul>
-
-    <p>
-      For information on using libvirt on <strong>Windows</strong>
-      <a href="windows.html">please see the Windows support page</a>.
-    </p>
-
-    <p>
-      Support, requests or help for libvirt bindings are welcome on the
-      <a href="https://www.redhat.com/mailman/listinfo/libvir-list/">mailing list</a>,
-      as usual try to provide enough background information and make sure
-      you use recent version, see the <a href="bugs.html">help page</a>.
-    </p>
-
-  </body>
-</html>

docs/browserconfig.xml

@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<browserconfig>
-    <msapplication>
-        <tile>
-            <square150x150logo src="/mstile-150x150.png"/>
-            <TileColor>#b91d47</TileColor>
-        </tile>
-    </msapplication>
-</browserconfig>

docs/bugs.html.in

@@ -1,160 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-
-    <h1>Bug reporting</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="security">Security Issues</a></h2>
-
-    <p>
-      If you think that an issue with libvirt may have security
-      implications, <strong>please do not</strong> publicly
-      report it in the bug tracker, mailing lists, or irc. Libvirt
-      has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
-      that should be used instead. So if your issue has security
-      implications, ignore the rest of this page and follow the
-      <a href="securityprocess.html">security process</a> instead.
-    </p>
-
-    <h2><a id="bugzilla">Bug Tracking</a></h2>
-
-    <p>
-      If you are using libvirt binaries from a Linux distribution
-      check below for distribution specific bug reporting policies
-      first.
-    </p>
-
-    <h2><a id="general">General libvirt bug reports</a></h2>
-
-    <p>
-      The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
-      should be used to report bugs and request features in libvirt.
-      Before submitting a ticket, check the existing tickets to see if
-      the bug/feature is already tracked.
-
-      For general libvirt bug reports, from self-built releases, GIT snapshots
-      and any other non-distribution supported builds, enter tickets under
-      the <code>Virtualization Tools</code> product and the <code>libvirt</code>
-      component.
-    </p>
-    <p>
-      It's always a good idea to file bug reports, as the process of
-      filing the report always makes it easier to describe the
-      problem, and the bug number provides a quick way of referring to
-      the problem.  However, not everybody in the community pays
-      attention to bugzilla, so after you file a bug, asking questions
-      and submitting patches on <a href="contact.html">the libvirt
-      mailing lists</a> will increase your bug's visibility and
-      encourage people to think about your problem.  Don't hesitate to
-      ask questions on the list, as others may know of existing
-      solutions or be interested in collaborating with you on finding
-      a solution.  Patches are always appreciated, and it's likely
-      that someone else has the same problem you do!
-    </p>
-    <p>
-      If you decide to write code, though, before you begin please
-      read the <a href="hacking.html">contributor guidelines</a>,
-      especially the first point: "Discuss any large changes on the
-      mailing list first. Post patches early and listen to feedback."
-      Few development experiences are more discouraging than spending
-      a bunch of time writing a patch only to have someone point out a
-      better approach on list.
-    </p>
-
-    <ul>
-      <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Virtualization%20Tools">View libvirt tickets</a></li>
-      <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&amp;component=libvirt">New libvirt ticket</a></li>
-    </ul>
-
-    <h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
-    <ul>
-      <li>
-        If you are using binaries from <strong>Fedora</strong>, enter
-        tickets against the <code>Fedora</code> product and
-        the <code>libvirt</code> component.
-        <ul>
-          <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Fedora">View Fedora libvirt tickets</a></li>
-          <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&amp;component=libvirt">New Fedora libvirt ticket</a></li>
-        </ul>
-      </li>
-      <li>
-        <p>
-          If you are using binaries from <strong>Red Hat Enterprise
-          Linux</strong>, enter tickets against the Red Hat Enterprise
-          Linux product that you're using (e.g., Red Hat Enterprise
-          Linux 6) and the <code>libvirt</code> component.  Red Hat
-          bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
-          you are a Red Hat customer.
-        </p>
-      </li>
-      <li>
-        <p>
-          If you are using binaries from another Linux distribution
-          first follow their own bug reporting guidelines.
-        </p>
-      </li>
-      <li>
-        <p>
-          Finally, if you are a contributor to another Linux
-          distribution and would like to have your procedure for
-          filing bugs mentioned here, please mail the libvirt
-          development list.
-        </p>
-      </li>
-    </ul>
-
-
-    <h2><a id="quality">How to file high quality bug reports</a></h2>
-
-    <p>
-      To increase the likelihood of your bug report being addressed it is
-      important to provide as much information as possible. When filing
-      libvirt bugs use this checklist to see if you are providing enough
-      information:
-    </p>
-
-    <ul>
-      <li>The version number of the libvirt build, or SHA1 of the GIT
-        commit</li>
-      <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 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>
-
-    <p>
-      If the bug leads to a tool linked to libvirt crash, then the best
-      is to provide a backtrace along with the scenario used to get the
-      crash, the simplest is to run the program under gdb, reproduce the
-      steps leading to the crash and then issue a gdb "bt -a" command to
-      get the stack trace, attach it to the bug. Note that for the
-      data to be really useful libvirt debug information must be present
-      for example by installing libvirt debuginfo package on Fedora or
-      Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
-      to running gdb.</p>
-    <p>
-      It may also happen that the libvirt daemon itself crashes or gets stuck,
-      in the first case run it (as root) under gdb, and reproduce the sequence
-      leading to the crash, similarly to a normal program provide the
-      "bt" backtrace information to where gdb will have stopped.<br/>
-      But if libvirtd gets stuck, for example seems to stop processing
-      commands, try to attach to the faulty daemon and issue a gdb command
-      "thread apply all bt" to show all the threads backtraces, as in:</p>
-      <pre> #  ps -o etime,pid `pgrep libvirt`
-... note the process id from the output
-# gdb /usr/sbin/libvirtd
-.... some information about gdb and loading debug data
-(gdb) attach $the_daemon_process_id
-....
-(gdb) thread apply all bt
-.... information to attach to the bug
-(gdb)
-</pre>
-
-  </body>
-</html>

docs/cgroups.html.in

@@ -1,413 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Control Groups Resource Management</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      The QEMU and LXC drivers make use of the Linux "Control Groups" facility
-      for applying resource management to their virtual machines and containers.
-    </p>
-
-    <h2><a id="requiredControllers">Required controllers</a></h2>
-
-    <p>
-      The control groups filesystem supports multiple "controllers". By default
-      the init system (such as systemd) should mount all controllers compiled
-      into the kernel at <code>/sys/fs/cgroup/$CONTROLLER-NAME</code>. Libvirt
-      will never attempt to mount any controllers itself, merely detect where
-      they are mounted.
-    </p>
-
-    <p>
-      The QEMU driver is capable of using the <code>cpuset</code>,
-      <code>cpu</code>, <code>cpuacct</code>, <code>memory</code>,
-      <code>blkio</code> and <code>devices</code> controllers.
-      None of them are compulsory. If any controller is not mounted,
-      the resource management APIs which use it will cease to operate.
-      It is possible to explicitly turn off use of a controller,
-      even when mounted, via the <code>/etc/libvirt/qemu.conf</code>
-      configuration file.
-    </p>
-
-    <p>
-      The LXC driver is capable of using the <code>cpuset</code>,
-      <code>cpu</code>, <code>cpuacct</code>, <code>freezer</code>,
-      <code>memory</code>, <code>blkio</code> and <code>devices</code>
-      controllers. The <code>cpuacct</code>, <code>devices</code>
-      and <code>memory</code> controllers are compulsory. Without
-      them mounted, no containers can be started. If any of the
-      other controllers are not mounted, the resource management APIs
-      which use them will cease to operate.
-    </p>
-
-    <h2><a id="currentLayout">Current cgroups layout</a></h2>
-
-    <p>
-      As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been
-      simplified, in order to facilitate the setup of resource control policies by
-      administrators / management applications. The new layout is based on the concepts
-      of "partitions" and "consumers". A "consumer" is a cgroup which holds the
-      processes for a single virtual machine or container. A "partition" is a cgroup
-      which does not contain any processes, but can have resource controls applied.
-      A "partition" will have zero or more child directories which may be either
-      "consumer" or "partition".
-    </p>
-
-    <p>
-      As of libvirt 1.1.1 or later, the cgroups layout will have some slight
-      differences when running on a host with systemd 205 or later. The overall
-      tree structure is the same, but there are some differences in the naming
-      conventions for the cgroup directories. Thus the following docs split
-      in two, one describing systemd hosts and the other non-systemd hosts.
-    </p>
-
-    <h3><a id="currentLayoutSystemd">Systemd cgroups integration</a></h3>
-
-    <p>
-      On hosts which use systemd, each consumer maps to a systemd scope unit,
-      while partitions map to a system slice unit.
-    </p>
-
-    <h4><a id="systemdScope">Systemd scope naming</a></h4>
-
-    <p>
-      The systemd convention is for the scope name of virtual machines / containers
-      to be of the general format <code>machine-$NAME.scope</code>. Libvirt forms the
-      <code>$NAME</code> part of this by concatenating the driver type with the id
-      and truncated name of the guest, and then escaping any systemd reserved
-      characters.
-      So for a guest <code>demo</code> running under the <code>lxc</code> driver,
-      we get a <code>$NAME</code> of <code>lxc-12345-demo</code> which when escaped
-      is <code>lxc\x2d12345\x2ddemo</code>. So the complete scope name is
-      <code>machine-lxc\x2d12345\x2ddemo.scope</code>.
-      The scope names map directly to the cgroup directory names.
-    </p>
-
-    <h4><a id="systemdSlice">Systemd slice naming</a></h4>
-
-    <p>
-      The systemd convention for slice naming is that a slice should include the
-      name of all of its parents prepended on its own name. So for a libvirt
-      partition <code>/machine/engineering/testing</code>, the slice name will
-      be <code>machine-engineering-testing.slice</code>. Again the slice names
-      map directly to the cgroup directory names. Systemd creates three top level
-      slices by default, <code>system.slice</code> <code>user.slice</code> and
-      <code>machine.slice</code>. All virtual machines or containers created
-      by libvirt will be associated with <code>machine.slice</code> by default.
-    </p>
-
-    <h4><a id="systemdLayout">Systemd cgroup layout</a></h4>
-
-    <p>
-      Given this, a possible systemd cgroups layout involving 3 qemu guests,
-      3 lxc containers and 3 custom child slices, would be:
-    </p>
-
-    <pre>
-$ROOT
-  |
-  +- system.slice
-  |   |
-  |   +- libvirtd.service
-  |
-  +- machine.slice
-      |
-      +- machine-qemu\x2d1\x2dvm1.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-qemu\x2d2\x2dvm2.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-qemu\x2d3\x2dvm3.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-engineering.slice
-      |   |
-      |   +- machine-engineering-testing.slice
-      |   |   |
-      |   |   +- machine-lxc\x2d11111\x2dcontainer1.scope
-      |   |
-      |   +- machine-engineering-production.slice
-      |       |
-      |       +- machine-lxc\x2d22222\x2dcontainer2.scope
-      |
-      +- machine-marketing.slice
-          |
-          +- machine-lxc\x2d33333\x2dcontainer3.scope
-    </pre>
-
-    <h3><a id="currentLayoutGeneric">Non-systemd cgroups layout</a></h3>
-
-    <p>
-      On hosts which do not use systemd, each consumer has a corresponding cgroup
-      named <code>$VMNAME.libvirt-{qemu,lxc}</code>. Each consumer is associated
-      with exactly one partition, which also have a corresponding cgroup usually
-      named <code>$PARTNAME.partition</code>. The exceptions to this naming rule
-      is the top level default partition for virtual machines and containers
-      <code>/machine</code>.
-    </p>
-
-    <p>
-      Given this, a possible non-systemd cgroups layout involving 3 qemu guests,
-      3 lxc containers and 2 custom child slices, would be:
-    </p>
-
-    <pre>
-$ROOT
-  |
-  +- machine
-      |
-      +- qemu-1-vm1.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- qeme-2-vm2.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- qemu-3-vm3.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- engineering.partition
-      |   |
-      |   +- testing.partition
-      |   |   |
-      |   |   +- lxc-11111-container1.libvirt-lxc
-      |   |
-      |   +- production.partition
-      |       |
-      |       +- lxc-22222-container2.libvirt-lxc
-      |
-      +- marketing.partition
-          |
-          +- lxc-33333-container3.libvirt-lxc
-    </pre>
-
-    <h2><a id="customPartiton">Using custom partitions</a></h2>
-
-    <p>
-      If there is a need to apply resource constraints to groups of
-      virtual machines or containers, then the single default
-      partition <code>/machine</code> may not be sufficiently
-      flexible. The administrator may wish to sub-divide the
-      default partition, for example into "testing" and "production"
-      partitions, and then assign each guest to a specific
-      sub-partition. This is achieved via a small element addition
-      to the guest domain XML config, just below the main <code>domain</code>
-      element
-    </p>
-
-    <pre>
-...
-&lt;resource&gt;
-  &lt;partition&gt;/machine/production&lt;/partition&gt;
-&lt;/resource&gt;
-...
-    </pre>
-
-    <p>
-      Note that the partition names in the guest XML are using a
-      generic naming format, not the low level naming convention
-      required by the underlying host OS. That is, you should not include
-      any of the <code>.partition</code> or <code>.slice</code>
-      suffixes in the XML config. Given a partition name
-      <code>/machine/production</code>, libvirt will automatically
-      apply the platform specific translation required to get
-      <code>/machine/production.partition</code> (non-systemd)
-      or <code>/machine.slice/machine-production.slice</code>
-      (systemd) as the underlying cgroup name
-    </p>
-
-    <p>
-      Libvirt will not auto-create the cgroups directory to back
-      this partition. In the future, libvirt / virsh will provide
-      APIs / commands to create custom partitions, but currently
-      this is left as an exercise for the administrator.
-    </p>
-
-    <p>
-      <strong>Note:</strong> the ability to place guests in custom
-      partitions is only available with libvirt &gt;= 1.0.5, using
-      the new cgroup layout. The legacy cgroups layout described
-      later in this document did not support customization per guest.
-    </p>
-
-    <h3><a id="createSystemd">Creating custom partitions (systemd)</a></h3>
-
-    <p>
-      Given the XML config above, the admin on a systemd based host would
-      need to create a unit file <code>/etc/systemd/system/machine-production.slice</code>
-    </p>
-
-    <pre>
-# cat &gt; /etc/systemd/system/machine-testing.slice &lt;&lt;EOF
-[Unit]
-Description=VM testing slice
-Before=slices.target
-Wants=machine.slice
-EOF
-# systemctl start machine-testing.slice
-    </pre>
-
-    <h3><a id="createNonSystemd">Creating custom partitions (non-systemd)</a></h3>
-
-    <p>
-      Given the XML config above, the admin on a non-systemd based host
-      would need to create a cgroup named '/machine/production.partition'
-    </p>
-
-    <pre>
-# cd /sys/fs/cgroup
-# for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
-  do
-    mkdir $i/machine/production.partition
-  done
-# for i in cpuset.cpus  cpuset.mems
-  do
-    cat cpuset/machine/$i > cpuset/machine/production.partition/$i
-  done
-</pre>
-
-    <h2><a id="resourceAPIs">Resource management APIs/commands</a></h2>
-
-    <p>
-      Since libvirt aims to provide an API which is portable across
-      hypervisors, the concept of cgroups is not exposed directly
-      in the API or XML configuration. It is considered to be an
-      internal implementation detail. Instead libvirt provides a
-      set of APIs for applying resource controls, which are then
-      mapped to corresponding cgroup tunables
-    </p>
-
-    <h3>Scheduler tuning</h3>
-
-    <p>
-     Parameters from the "cpu" controller are exposed via the
-     <code>schedinfo</code> command in virsh.
-    </p>
-
-    <pre>
-# virsh schedinfo demo
-Scheduler      : posix
-cpu_shares     : 1024
-vcpu_period    : 100000
-vcpu_quota     : -1
-emulator_period: 100000
-emulator_quota : -1</pre>
-
-
-    <h3>Block I/O tuning</h3>
-
-    <p>
-     Parameters from the "blkio" controller are exposed via the
-     <code>bkliotune</code> command in virsh.
-    </p>
-
-
-    <pre>
-# virsh blkiotune demo
-weight         : 500
-device_weight  : </pre>
-
-    <h3>Memory tuning</h3>
-
-    <p>
-     Parameters from the "memory" controller are exposed via the
-     <code>memtune</code> command in virsh.
-    </p>
-
-    <pre>
-# virsh memtune demo
-hard_limit     : 580192
-soft_limit     : unlimited
-swap_hard_limit: unlimited
-    </pre>
-
-    <h3>Network tuning</h3>
-
-    <p>
-      The <code>net_cls</code> is not currently used. Instead traffic
-      filter policies are set directly against individual virtual
-      network interfaces.
-    </p>
-
-    <h2><a id="legacyLayout">Legacy cgroups layout</a></h2>
-
-    <p>
-      Prior to libvirt 1.0.5, the cgroups layout created by libvirt was different
-      from that described above, and did not allow for administrator customization.
-      Libvirt used a fixed, 3-level hierarchy <code>libvirt/{qemu,lxc}/$VMNAME</code>
-      which was rooted at the point in the hierarchy where libvirtd itself was
-      located. So if libvirtd was placed at <code>/system/libvirtd.service</code>
-      by systemd, the groups for each virtual machine / container would be located
-      at <code>/system/libvirtd.service/libvirt/{qemu,lxc}/$VMNAME</code>. In addition
-      to this, the QEMU drivers further child groups for each vCPU thread and the
-      emulator thread(s). This leads to a hierarchy that looked like
-    </p>
-
-
-    <pre>
-$ROOT
-  |
-  +- system
-      |
-      +- libvirtd.service
-           |
-           +- libvirt
-               |
-               +- qemu
-               |   |
-               |   +- vm1
-               |   |   |
-               |   |   +- emulator
-               |   |   +- vcpu0
-               |   |   +- vcpu1
-               |   |
-               |   +- vm2
-               |   |   |
-               |   |   +- emulator
-               |   |   +- vcpu0
-               |   |   +- vcpu1
-               |   |
-               |   +- vm3
-               |       |
-               |       +- emulator
-               |       +- vcpu0
-               |       +- vcpu1
-               |
-               +- lxc
-                   |
-                   +- container1
-                   |
-                   +- container2
-                   |
-                   +- container3
-    </pre>
-
-    <p>
-      Although current releases are much improved, historically the use of deep
-      hierarchies has had a significant negative impact on the kernel scalability.
-      The legacy libvirt cgroups layout highlighted these problems, to the detriment
-      of the performance of virtual machines and containers.
-    </p>
-  </body>
-</html>

docs/compiling.html.in

@@ -1,142 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1><a id="installation">libvirt Installation</a></h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="compiling">Compiling a release tarball</a></h2>
-
-    <p>
-      libvirt uses the standard configure/make/install steps and mandates
-      that the build directory is different that the source directory:
-    </p>
-
-    <pre>
-$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
-$ cd libvirt-x.x.x
-$ mkdir build &amp;&amp; cd build
-$ ../configure</pre>
-
-    <p>
-      The <i>configure</i> script can be given options to change its default
-      behaviour.
-    </p>
-
-    <p>
-      To get the complete list of the options it can take, pass it the
-      <i>--help</i> option like this:
-    </p>
-
-    <pre>
-$ ../configure <i>--help</i></pre>
-
-    <p>
-      When you have determined which options you want to use (if any),
-      continue the process.
-    </p>
-
-    <p>
-      Note the use of <b>sudo</b> with the <i>make install</i> command
-      below.  Using sudo is only required when installing to a location your
-      user does not have write access to.  Installing to a system location
-      is a good example of this.
-    </p>
-
-    <p>
-      If you are installing to a location that your user <i>does</i> have write
-      access to, then you can instead run the <i>make install</i> command
-      without putting <b>sudo</b> before it.
-    </p>
-
-    <pre>
-$ ../configure <i>[possible options]</i>
-$ make
-$ <b>sudo</b> <i>make install</i></pre>
-
-    <p>
-      At this point you <b>may</b> have to run ldconfig or a similar utility
-      to update your list of installed shared libs.
-    </p>
-
-    <h2><a id="building">Building from a GIT checkout</a></h2>
-
-    <p>
-      The libvirt build process uses GNU autotools, so after obtaining a
-      checkout it is necessary to generate the configure script and Makefile.in
-      templates using the <code>autogen.sh</code> command. By default when
-      the <code>configure</code> script is run from within a GIT checkout, it
-      will turn on -Werror for builds. This can be disabled with
-      --disable-werror, but this is not recommended.
-    </p>
-    <p>
-      Libvirt takes advantage of
-      the <a href="http://www.gnu.org/software/gnulib/">gnulib</a>
-      project to provide portability to a number of platforms.  This
-      is normally done dynamically via a git submodule in
-      the <code>.gnulib</code> subdirectory, which is auto-updated as
-      needed when you do incremental builds.  Setting the environment
-      variable <code>GNULIB_SRCDIR</code> to a local directory
-      containing a git checkout of gnulib will let you reduce local
-      disk space requirements and network download time, regardless of
-      which actual commit you have in that reference directory.
-    </p>
-    <p>
-      However, if you are developing on a platform where git is not
-      available, or are behind a firewall that does not allow for git
-      to easily obtain the gnulib submodule, it is possible to instead
-      use a static mode of operation where you are then responsible
-      for updating the git submodule yourself.  In this mode, you must
-      track the exact gnulib commit needed by libvirt (usually not the
-      latest gnulib.git) via alternative means, such as a shared NFS
-      drive or manual download, and run this any time libvirt.git
-      updates the commit stored in the .gnulib submodule:</p>
-    <pre>
-$ GNULIB_SRCDIR=/path/to/gnulib ./autogen.sh --no-git
-    </pre>
-
-    <p>To build &amp; install libvirt to your home
-      directory the following commands can be run:
-    </p>
-
-    <pre>
-$ ./autogen.sh --prefix=$HOME/usr
-$ make
-$ <b>sudo</b> make install</pre>
-
-    <p>
-      Be aware though, that binaries built with a custom prefix will not
-      interoperate with OS vendor provided binaries, since the UNIX socket
-      paths will all be different. To produce a build that is compatible
-      with normal OS vendor prefixes, use
-    </p>
-
-    <pre>
-$ ./autogen.sh --system
-$ make
-    </pre>
-
-    <p>
-      When doing this for day-to-day development purposes, it is recommended
-      not to install over the OS vendor provided binaries. Instead simply
-      run libvirt directly from the source tree. For example to run
-      a privileged libvirtd instance
-    </p>
-
-    <pre>
-$ su -
-# service libvirtd stop  (or systemctl stop libvirtd.service)
-# /home/to/your/checkout/src/libvirtd
-    </pre>
-
-    <p>
-      It is also possible to run virsh directly from the source tree
-      using the ./run script (which sets some environment variables):
-    </p>
-
-    <pre>
-$ ./run ./tools/virsh ....
-    </pre>
-  </body>
-</html>

docs/contact.html.in

@@ -1,116 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Contacting the project contributors</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="security">Security Issues</a></h2>
-
-    <p>
-      If you think that an issue with libvirt may have security
-      implications, <strong>please do not</strong> publicly
-      report it in the bug tracker, mailing lists, or irc. Libvirt
-      has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
-      that should be used instead. So if your issue has security
-      implications, ignore the rest of this page and follow the
-      <a href="securityprocess.html">security process</a> instead.
-    </p>
-
-    <h2><a id="email">Mailing lists</a></h2>
-
-    <p>
-      There are three mailing-lists:
-    </p>
-
-    <dl class="mail">
-      <dt><a href="https://www.redhat.com/mailman/listinfo/libvir-list">libvir-list@redhat.com</a> (for development)</dt>
-      <dd>
-        Archives at <a href="https://www.redhat.com/archives/libvir-list">https://www.redhat.com/archives/libvir-list</a>
-      </dd>
-      <dd>
-        This is a high volume mailing list.  It is a place for discussions
-        about the <strong>development</strong> of libvirt.
-      </dd>
-      <dd>
-        Topics for discussion include:
-        <ul>
-          <li>New features for libvirt</li>
-          <li>Bug fixing of libvirt</li>
-          <li>New hypervisor drivers</li>
-          <li>Development of language bindings for libvirt API</li>
-          <li>Testing and documentation of libvirt</li>
-        </ul>
-      </dd>
-
-      <dt><a href="https://www.redhat.com/mailman/listinfo/libvirt-users">libvirt-users@redhat.com</a> (for users)</dt>
-      <dd>
-        Archives at <a href="https://www.redhat.com/archives/libvirt-users">https://www.redhat.com/archives/libvirt-users</a>
-      </dd>
-      <dd>
-        This is a moderate volume mailing list.  It is a place for discussions
-        involving libvirt <strong>users</strong>.
-      </dd>
-      <dd>
-        Topics for discussion include:
-        <ul>
-          <li>Usage of libvirt / virsh</li>
-          <li>Administration of libvirt</li>
-          <li>Deployment of libvirt with hypervisors</li>
-          <li>Development of applications on top of / using the libvirt API(s)</li>
-          <li>Any other topics along these lines</li>
-        </ul>
-      </dd>
-
-      <dt><a href="https://www.redhat.com/mailman/listinfo/libvirt-announce">libvirt-announce@redhat.com</a> (for release notices)</dt>
-      <dd>
-        Archives at <a href="https://www.redhat.com/archives/libvirt-announce">https://www.redhat.com/archives/libvirt-announce</a>
-      </dd>
-      <dd>
-        This is a low volume mailing list, with restricted posting, for
-        announcements of new libvirt releases.
-      </dd>
-      <dd>
-        Subscribe to just this if you want to be notified of new releases,
-        without subscribing to either of the other mailing lists.
-      </dd>
-
-    </dl>
-
-    <p>
-      It is recommended but not required that you subscribe before posting
-      to the user and development lists.  Posts from non-subscribers will be
-      subject to manual moderation delays.  You can subscribe at the linked
-      web pages above.
-    </p>
-    <p>
-      Patches with explanations and provided as attachments are really
-      appreciated, and should be directed to the development mailing list
-      for review and discussion.
-      Wherever possible, please generate the patches by using
-      <code>git format-patch</code> in a git repository clone.  Further
-      useful information regarding developing libvirt and/or contributing is
-      available on our <a href="hacking.html">Contributor Guidelines</a>
-      page.
-    </p>
-
-    <h2><a id="irc">IRC discussion</a></h2>
-
-    <p>
-      Some of the libvirt developers may be found on IRC on the <a href="http://oftc.net">OFTC IRC</a>
-      network. Use the settings:
-    </p>
-    <ul>
-      <li>server: irc.oftc.net</li>
-      <li>port: 6667 (the usual IRC port)</li>
-      <li>channel: #virt</li>
-    </ul>
-    <p>
-      NB There is no guarantee that someone will be watching or able to reply
-      promptly, so use the mailing-list if you don't get an answer on the IRC
-      channel.
-    </p>
-
-  </body>
-</html>

docs/contribute.html.in

@@ -1,142 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Contributing to libvirt</h1>
-
-    <p>
-      This page provides guidance on how to contribute to the
-      libvirt project
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="skills">Contributions required</a></h2>
-
-    <p>
-      The libvirt project is always looking for new contributors to
-      participate in ongoing activities. While code development is a
-      major part of the project, assistance is needed in many other
-      areas including documentation writing, bug triage, testing,
-      application integration, website / wiki content management,
-      translation, branding, social media and more. The only
-      requirement is an interest in virtualization and desire to
-      help.
-    </p>
-
-    <p>
-      The following is a non-exhaustive list of areas in which
-      people can contribute to libvirt. If you have ideas for
-      other contributions feel free to follow them.
-    </p>
-
-    <ul>
-      <li><strong>Software development</strong>. The core library / daemon (and
-        thus the bulk of coding) is written in C, but there are
-        language bindings written in Python, Perl, Java, Ruby,
-        Php, OCaml and Go. There are also higher level wrappers
-        mapping libvirt into other object frameworks, such GLib,
-        CIM and SNMP. For those interested in working on the core parts of
-        libvirt, the <a href="hacking.html">contributor guidelines</a> are
-        mandatory reading</li>
-      <li><strong>Translation</strong>. All the libvirt modules aim to support
-        translations where appropriate. All translation is
-        handling outside of the normal libvirt review process,
-        using the <a href="http://fedora.zanata.org">Fedora
-        instance</a> of the Zanata tool. Thus people wishing
-        to contribute to translation should join the Fedora
-        translation team</li>
-      <li><strong>Documentation</strong>. There are docbook guides on various
-        aspects of libvirt, particularly application development
-        guides for the C library and Python, and a virsh command
-        reference. There is thus scope for work by people who are
-        familiar with using or developing against libvirt, to
-        write further content for these guides. There is also a
-        need for people to review existing content for copy editing
-        and identifying gaps in the docs</li>
-      <li><strong>Website / wiki curation</strong>. The bulk of the website is
-        maintained in the primary GIT repository, while the wiki
-        site uses mediawiki. In both cases there is a need for
-        people to both write new content and curate existing
-        content to identify outdated information, improve its
-        organization and target gaps.</li>
-      <li><strong>Testing</strong>. There are a number of tests suites that can run
-        automated tests against libvirt. The coverage of the tests
-        is never complete, so there is a need for people to create
-        new test suites and / or provide environments to actually
-        run the tests in a variety of deployment scenarios.</li>
-      <li><strong>Code analysis</strong>. The libvirt project has access to the coverity
-        tool to run static analysis against the codebase, however,
-        there are other types of code analysis that can be useful.
-        In particular fuzzing of the inputs can be very effective
-        at identifying problematic edge cases.</li>
-      <li><strong>Security handling</strong>. Downstream (operating system) vendors
-        who distribute libvirt may wish to propose a person to
-        be part of the security handling team, to get early access
-        to information about forthcoming vulnerability fixes.</li>
-      <li><strong>Evangalism</strong>. Work done by the project is of no benefit
-        unless the (potential) user community knows that it
-        exists. Thus it is critically important to the health
-        and future growth of the project, that there are a people
-        who evangalise the work created by the project. This can
-        take many forms, writing blog posts (about usage of features,
-        personal user experiences, areas for future work, and more),
-        syndicating docs and blogs via social media, giving user
-        group and/or conference talks about libvirt.</li>
-      <li><strong>User assistance</strong>. Since documentation
-        is never perfect, there are inevitably cases where users
-        will struggle to attain a deployment goal they have, or
-        run into trouble with managing an existing deployment.
-        While some users may be able to contact a software vendor
-        to obtain support, it is common to rely on community help
-        forums such as <a href="contact.html#email">libvirt users
-          mailing list</a>, or sites such as
-        <a href="http://stackoverflow.com/questions/tagged/libvirt">stackoverflow.</a>
-        People who are familiar with libvirt and have ability &amp;
-        desire to help other users are encouraged to participate in
-        these help forums.</li>
-    </ul>
-
-    <h2><a id="comms">Communication</a></h2>
-
-    <p>
-      For full details on contacting other project contributors
-      read the <a href="contact.html">contact</a> page. There
-      are two main channels that libvirt uses for communication
-      between contributors:
-    </p>
-
-    <h3><a id="email">Mailing lists</a></h3>
-
-    <p>
-      The project has a number of
-      <a href="contact.html#email">mailing lists</a> for
-      general communication between contributors.
-      In general any design discussions and review
-      of contributions will take place on the mailing
-      lists, so it is important for all contributors
-      to follow the traffic.
-    </p>
-
-    <h3><a id="irc">Instant messaging / chat</a></h3>
-
-    <p>
-      Contributors to libvirt are encouraged to join the
-      <a href="contact.html#irc">IRC channel</a> used by
-      the project, where they can have live conversations
-      with others members.
-    </p>
-
-    <h2><a id="outreach">Student / outreach coding programs</a></h2>
-
-    <p>
-      Since 2016, the libvirt project directly participates as an
-      organization in the <a href="http://wiki.libvirt.org/page/Google_Summer_of_Code_Ideas">Google Summer of Code program</a>. Prior to
-      this the project had a number of students in the program
-      via a joint application with the QEMU project. People are
-      encouraged to look at both the libvirt and QEMU programs
-      to identify potentially interesting projects to work on.
-    </p>
-
-  </body>
-</html>

docs/csharp.html.in

@@ -1,491 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>C# API bindings</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="description">Description</a></h2>
-
-    <p>
-      The C# libvirt bindings are a class library.  They use a Microsoft
-      Visual Studio project architecture, and have been tested with Windows
-      .NET, and Mono, on both Linux and Windows.
-    </p>
-    <p>
-      Compiling them produces <b>LibvirtBindings.dll</b>, which can
-      be added as a .NET reference to any .NET project needing access
-      to libvirt.
-    </p>
-
-    <h2><a id="requirements">Requirements</a></h2>
-
-    <p>
-      These bindings depend upon the libvirt libraries being installed.
-    </p>
-    <p>
-      In the .NET case, this is <b>libvirt-0.dll</b>, produced from
-      compiling libvirt for windows.
-    </p>
-
-<!-- 2010-10-19 JC: Commented out until we have C# tarballs to download
-    <h2><a id="getting">Getting them</a></h2>
-
-    <p>
-      The latest versions of the libvirt C# bindings can be downloaded from:
-    </p>
-
-    <ul>
-      <li><a href="ftp://libvirt.org/libvirt/csharp/">libvirt.org FTP server</a></li>
-      <li><a href="https://libvirt.org/sources/csharp/">libvirt.org HTTP server</a></li>
-    </ul>
--->
-
-    <h2><a id="git">GIT source repository</a></h2>
-    <p>
-      The C# bindings source code is maintained in a <a
-      href="http://git-scm.com/">git</a> repository available on
-      <a href="https://libvirt.org/git/">libvirt.org</a>:
-    </p>
-
-<pre>
-git clone https://libvirt.org/git/libvirt-csharp.git
-</pre>
-
-    <p>
-      They can also be browsed online:
-    </p>
-
-<pre>
-<a href="https://libvirt.org/git/?p=libvirt-csharp.git;a=summary">https://libvirt.org/git/?p=libvirt-csharp.git;a=summary</a>
-</pre>
-
-    <h2><a id="usage">Usage</a></h2>
-
-    <p>
-      The libvirt C# bindings class library exposes the <b>Libvirt</b>
-      namespace.  This namespace exposes all of the needed types (enum,
-      struct), plus many classes exposing the libvirt API methods.
-    </p>
-    <p>
-      These classes are grouped into functional areas, with each class
-      exposing libvirt methods related to that area.
-    </p>
-    <p>
-      For example, the libvirt methods related to connections, such as
-      <b>virConnectOpenAuth</b> and <b>virConnectNumOfDomains</b>, are in
-      the <b>Connect</b> class.
-      <br />
-      They are accessed as <b>Connect.OpenAuth</b>, and
-      <b>Connect.NumOfDomains</b> respectively.
-    </p>
-    <p>
-      In the same manner, the other class name mappings are:
-    </p>
-    <table class="top_table">
-      <tr><th>Name of libvirt function</th><th>C# class name</th></tr>
-      <tr><td>virDomain...</td><td>Domain</td></tr>
-      <tr><td>virEvent...</td><td>Event</td></tr>
-      <tr><td>virInterface...</td><td>Interface</td></tr>
-      <tr><td>virNetwork...</td><td>Network</td></tr>
-      <tr><td>virNode...</td><td>Node</td></tr>
-      <tr><td>virSecret...</td><td>Secret</td></tr>
-      <tr><td>virStoragePool...</td><td>StoragePool</td></tr>
-      <tr><td>virStorageVolume...</td><td>StorageVolume</td></tr>
-      <tr><td>virStream...</td><td>Stream</td></tr>
-    </table>
-    <p>
-      There are some additions as well:
-    </p>
-    <ul>
-      <li>
-        There is a class named <b>Library</b>, exposing the
-        <b>virGetVersion</b> and <b>virInitialize</b> methods
-      </li>
-      <li>
-        There is a class named <b>Errors</b>, exposing the error
-        related methods.  For example, <b>virSetErrorFunc</b> and
-        <b>virConnResetLastError</b>.
-      </li>
-    </ul>
-
-    <h2><a id="authors">Authors</a></h2>
-
-    <p>
-      The C# bindings are the work of Arnaud Champion
-      &lt;<a href="mailto:arnaud.champion AT devatom.fr">arnaud.champion AT devatom.fr</a>&gt;,
-      based upon the previous work of Jaromír Červenka.
-    </p>
-
-    <h2><a id="notes">Test Configuration</a></h2>
-
-    <p>
-      Testing is performed using the following configurations:
-    </p>
-    <ul>
-      <li>Windows 7 (64 bits) / .Net 4</li>
-      <li>Windows 7 (64 bits) / Mono 2.6.7 (compiled in 32 bits)</li>
-      <li>Ubuntu 10.10 amd64 / Mono 2.6.7 (compiled in 64 bits)</li>
-    </ul>
-
-    <h2><a id="type">Type Coverage</a></h2>
-
-    <p>
-      Coverage of the libvirt types is:
-    </p>
-    <table class="top_table">
-      <tr><th>Type</th><th>Name</th><th>Binding?</th><th>Tested?</th><th>Sample Code?</th><th>Works?</th><th>Tested .Net/Windows Works?</th><th>Tested Mono (32-bit)/Windows Works?</th><th>Tested Mono (64-bit)/Linux Works?</th></tr>
-      <tr><td>enum</td><td>virCPUCompareResult</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virConnect</td><td>Yes, an IntPtr as the struct is not public</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virConnectAuth</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>struct</td><td>virConnectCredential</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virConnectCredentialType</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virConnectFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomain</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainBlockInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainBlockStatsInfo</td><td>Yes</td><td>Yes</td><td>virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainCoreDumpFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainCreateFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainDeviceModifyFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventDefinedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>struct</td><td>virDomainEventGraphicsAddress</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventGraphicsAddressType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventGraphicsPhase</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainEventGraphicsSubject</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainEventGraphicsSubjectIdentity</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventID</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventIOErrorAction</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainEventResumedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventStartedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventStoppedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventSuspendedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventUndefinedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>enum</td><td>virDomainEventWatchdogAction</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainInfo</td><td>Yes</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>struct</td><td>virDomainInterfaceStatsStruct</td><td>Yes</td><td>Yes</td><td>virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>struct</td><td>virDomainJobInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainJobType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainMemoryFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainMemoryStatStruct</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainMemoryStatTags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainMigrateFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virDomainSnapshot</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainSnapshotDeleteFlags</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainState</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virDomainXMLFlags</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virEventHandleType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>struct</td><td>virInterface</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virInterfaceXMLFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virNWFilter</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virNetwork</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virNodeDevice</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virNodeInfo</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virSchedParameter</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virSchedParameterType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virSecret</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virSecretUsageType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virSecurityLabel</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virSecurityModel</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStoragePoolBuildFlags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStoragePoolDeleteFlags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virStoragePoolInfo</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virStoragePool</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStoragePoolState</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virStorageVol</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStorageVolDeleteFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virStorageVolInfo</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStorageVolType</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virStream</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStreamEventType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virStreamFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virVcpuInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>enum</td><td>virVcpuState</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>struct</td><td>virError</td><td>Yes</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-    </table>
-
-    <p></p>
-
-    <h2><a id="funccover">Function Coverage</a></h2>
-
-    <p>
-      Coverage of the libvirt functions is:
-    </p>
-    <table class="top_table">
-      <tr><th>Name</th><th>Binding?</th><th>Type?</th><th>Tested?</th><th>Sample Code?</th><th>Working?</th><th>Tested .Net/Windows Works?</th><th>Tested Mono (32-bit)/Windows Works?</th><th>Tested Mono (64-bit)/Linux Works?</th></tr>
-      <tr><td>virConnectAuthCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectBaselineCPU</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectClose</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectCompareCPU</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventDeregister</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventDeregisterAny</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventGenericCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventGraphicsCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventIOErrorCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventIOErrorReasonCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventRTCChangeCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventRegister</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectDomainEventRegisterAny</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainEventWatchdogCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainXMLFromNative</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectDomainXMLToNative</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectFindStoragePoolSources</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetCapabilities</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetHostname</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetLibVersion</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetMaxVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetType</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetURI</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectGetVersion</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectIsEncrypted</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectIsSecure</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListDefinedDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectListDefinedInterfaces </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListDefinedNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListDefinedStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectListInterfaces</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes, if the host handle the method</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListNWFilters </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListSecrets</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectListStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectNumOfDefinedDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectNumOfDefinedInterfaces</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfDefinedNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfDefinedStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectNumOfInterfaces</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfNWFilters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfNetworks </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfSecrets</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectNumOfStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectOpen</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen, virEventRegisterImpl, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectOpenAuth</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnectOpenReadOnly</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virConnectRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainAbortJob</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainAttachDevice</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainAttachDeviceFlags</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainBlockPeek</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainBlockStats</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainCoreDump</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainCreateLinux</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainCreateWithFlags</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainCreateXML</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainDetachDevice</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainDetachDeviceFlags</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetBlockInfo</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainGetJobInfo</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetMaxMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetMaxVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetName</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainGetOSType</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetSchedulerParameters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetSchedulerType</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetSecurityLabel</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetVcpus</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainHasCurrentSnapshot</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainHasManagedSaveImage</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainInterfaceStats </td><td>No</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainIsPersistent</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainLookupByID</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virDomainLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainManagedSave    </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainManagedSaveRemove</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainMemoryPeek</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainMemoryStats</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainMigrate</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainMigrateSetMaxDowntime</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainMigrateToURI   </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainPinVcpu</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainReboot</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainRef    </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainRestore</td><td>Yes </td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainResume </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainRevertToSnapshot</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSave</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSetMaxMemory   </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSetMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSetSchedulerParameters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSetVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainShutdown</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotCreateXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotCurrent</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotDelete</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotListNames</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotLookupByName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSnapshotNum</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainSuspend</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virDomainUpdateDeviceFlags</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virEventAddHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virEventAddTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virEventHandleCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virEventRegisterImpl</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virEventRemoveHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virEventRemoveTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virEventTimeoutCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virEventUpdateHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virEventUpdateTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virFreeCallback</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virGetVersion</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virInitialize</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceCreate</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceDestroy</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceGetConnect</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceGetMACString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceIsActive</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceLookupByMACString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceLookupByName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceRef </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virInterfaceUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterGetUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterLookupByName </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterLookupByUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterLookupByUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterRef  </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNWFilterUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkCreateXML</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetBridgeName</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetName</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetUUIDString </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkIsPersistent</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkSetAutostart</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNetworkUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceCreateXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceDestroy</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceDettach</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceGetParent</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceListCaps</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceNumOfCaps</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceReAttach</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeDeviceReset</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeGetCellsFreeMemory</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeGetFreeMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeGetInfo</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeGetSecurityModel </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeListDevices</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virNodeNumOfDevices</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretFree   </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetConnect</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetUUIDString  </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetUsageID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetUsageType</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetValue</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretLookupByUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretLookupByUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretLookupByUsage</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretSetValue</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virSecretUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolBuild</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolCreateXML </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolDelete</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetUUIDString</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolIsPersistent</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolListVolumes</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolLookupByVolume</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolNumOfVolumes</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolRefresh</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolSetAutostart</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStoragePoolUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolCreateXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolCreateXMLFrom</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolDelete</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolFree</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetConnect  </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetKey</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetPath</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolGetXMLDesc </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolLookupByKey</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolLookupByPath</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>No</td><td></td><td></td><td></td></tr>
-      <tr><td>virStorageVolWipe</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamAbort  </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamEventAddCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamEventCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamEventRemoveCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamEventUpdateCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamFinish </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamFree   </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamNew</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamRecv</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamRecvAll</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamSend</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamSendAll</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamSinkFunc</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virStreamSourceFunc</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
-      <tr><td>virGetLastError</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectSetErrorFunc</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virConnSetErrorFunc</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectSetErrorFunc</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-      <tr><td>virErrorFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
-    </table>
-  </body>
-</html>

docs/dbus.html.in

@@ -1,102 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>D-Bus API bindings</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="description">Description</a></h2>
-
-    <p>
-      libvirt-dbus wraps libvirt API to provide a high-level object-oriented
-      API better suited for dbus-based applications.
-    </p>
-
-    <h2><a id="git">GIT source repository</a></h2>
-    <p>
-      The D-Bus bindings source code is maintained in a
-      <a href="https://git-scm.com/">git</a> repository available on
-      <a href="https://libvirt.org/git/">libvirt.org</a>:
-    </p>
-
-<pre>
-git clone https://libvirt.org/git/libvirt-dbus.git
-</pre>
-
-    <p>
-      They can also be browsed online:
-    </p>
-
-<pre>
-<a href="https://libvirt.org/git/?p=libvirt-dbus.git">https://libvirt.org/git/?p=libvirt-dbus.git</a>
-</pre>
-
-    <h2><a id="usage">Usage</a></h2>
-
-    <p>
-      libvirt-dbus exports libvirt API using D-Bus objects with methods and
-      properties described by interfaces.  Currently only local connection
-      to libvirt is exported and the list of supported drivers depends
-      on the type of the bus connection (session or system).
-    </p>
-
-    <p>
-      The name of the libvirt-dbus service is <code>org.libvirt</code>.
-      libvirt-dbus distributes an interface XML descriptions which can be
-      usually found at <code>/usr/share/dbus-1/interfaces/</code>.
-    </p>
-
-    <p>
-      By default unprivileged user has access only to the session D-Bus
-      connection. In order to allow specific user "foo" to access the system
-      D-Bus connection you need to create a file
-      <code>/etc/dbus-1/system.d/org.libvirt.conf</code> that contains:
-    </p>
-
-<pre>
-&lt;?xml version="1.0"?&gt;
-&lt;!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
- "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"&gt;
-
-&lt;busconfig&gt;
-
-  &lt;policy user="foo"&gt;
-    &lt;allow send_destination="org.libvirt"/&gt;
-  &lt;/policy&gt;
-
-&lt;/busconfig&gt;
-</pre>
-
-    <p>
-      To get a list of supported drivers for the specific bus connection
-      you can run these commands (not all drivers may be available on
-      the host):
-    </p>
-
-<pre>
-gdbus introspect --xml --session --dest org.libvirt --object-path /org/libvirt
-gdbus introspect --xml --system --dest org.libvirt --object-path /org/libvirt
-</pre>
-
-    <p>
-      Every object is introspectable so you can get a list of available
-      interfaces with methods, signals and properties running this command:
-    </p>
-
-<pre>
-gdbus introspect --xml --system --dest org.libvirt --object-path /org/libvirt/QEMU
-</pre>
-
-    <p>
-      To get a list of domains for specific connection driver you can run
-      this command:
-    </p>
-
-<pre>
-gdbus call --system --dest org.libvirt --object-path /org/libvirt/QEMU \
-    --method org.libvirt.Connect.ListDomains 0
-</pre>
-
-  </body>
-</html>

docs/devguide.html.in

@@ -1,42 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>libvirt Application Development Guides</h1>
-
-    <p>
-      The libvirt API is accessible from a number of programming languages.
-      At this time, there are application development guides available
-      which cover the C API and the Python API. Of the two, the Python guide
-      is currently the more comprehensive document.
-    </p>
-
-    <ul>
-      <li><a href="https://libvirt.org/docs/libvirt-appdev-guide/en-US/html/">Application Development Guide (C language) HTML</a></li>
-      <li><a href="https://libvirt.org/docs/libvirt-appdev-guide/en-US/pdf/">Application Development Guide (C language) PDF</a></li>
-      <li><a href="https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/">Application Development Guide (Python language) HTML</a></li>
-      <li><a href="https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/pdf/">Application Development Guide (Python language) PDF</a></li>
-    </ul>
-
-    <h2>Contributing content</h2>
-
-    <p>
-      These guides are written in DocBook and published with the
-      publican tool, which is also used for Fedora and Red Hat
-      documentation. The original content is provided in GIT and
-      any contributions to the guide are welcome.
-    </p>
-
-    <pre>
-# C language
-$ git clone <a href="https://libvirt.org/git/?p=libvirt-appdev-guide.git">https://libvirt.org/git/libvirt-appdev-guide.git</a>
-
-# Python language
-$ git clone <a href="https://libvirt.org/git/?p=libvirt-appdev-guide-python.git">https://libvirt.org/git/libvirt-appdev-guide-python.git</a>
-
-# Publican Style/Theme
-$ git clone <a href="https://libvirt.org/git/?p=libvirt-publican.git">https://libvirt.org/git/libvirt-publican.git</a>
-    </pre>
-
-  </body>
-</html>

docs/docs.html.in

@@ -1,178 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body class="docs">
-    <div class="panel">
-      <h2>Deployment / operation</h2>
-
-      <dl>
-        <dt><a href="apps.html">Applications</a></dt>
-        <dd>Applications known to use libvirt</dd>
-
-        <dt><a href="manpages/index.html">Manual pages</a></dt>
-        <dd>Manual pages for libvirt tools / daemons</dd>
-
-        <dt><a href="windows.html">Windows</a></dt>
-        <dd>Downloads for Windows</dd>
-
-        <dt><a href="migration.html">Migration</a></dt>
-        <dd>Migrating guests between machines</dd>
-
-        <dt><a href="remote.html">Remote access</a></dt>
-        <dd>Enable remote access over TCP</dd>
-
-        <dt><a href="tlscerts.html">TLS certs</a></dt>
-        <dd>Generate and deploy x509 certificates for TLS</dd>
-
-        <dt><a href="auth.html">Authentication</a></dt>
-        <dd>Configure authentication for the libvirt daemon</dd>
-
-        <dt><a href="acl.html">Access control</a></dt>
-        <dd>Configure access control libvirt APIs with <a href="aclpolkit.html">polkit</a></dd>
-
-        <dt><a href="logging.html">Logging</a></dt>
-        <dd>The library and the daemon logging support</dd>
-
-        <dt><a href="auditlog.html">Audit log</a></dt>
-        <dd>Audit trail logs for host operations</dd>
-
-        <dt><a href="firewall.html">Firewall</a></dt>
-        <dd>Firewall and network filter configuration</dd>
-
-        <dt><a href="hooks.html">Hooks</a></dt>
-        <dd>Hooks for system specific management</dd>
-
-        <dt><a href="nss.html">NSS module</a></dt>
-        <dd>Enable domain host name translation to IP addresses</dd>
-
-        <dt><a href="http://wiki.libvirt.org/page/FAQ">FAQ</a></dt>
-        <dd>Frequently asked questions</dd>
-      </dl>
-
-    </div>
-
-    <div class="panel">
-      <h2>Application development</h2>
-      <dl>
-        <dt><a href="html/index.html">API reference</a></dt>
-        <dd>Reference manual for the C public API, split in
-          <a href="html/libvirt-libvirt-common.html">common</a>,
-          <a href="html/libvirt-libvirt-domain.html">domain</a>,
-          <a href="html/libvirt-libvirt-domain-checkpoint.html">domain checkpoint</a>,
-          <a href="html/libvirt-libvirt-domain-snapshot.html">domain snapshot</a>,
-          <a href="html/libvirt-virterror.html">error</a>,
-          <a href="html/libvirt-libvirt-event.html">event</a>,
-          <a href="html/libvirt-libvirt-host.html">host</a>,
-          <a href="html/libvirt-libvirt-interface.html">interface</a>,
-          <a href="html/libvirt-libvirt-network.html">network</a>,
-          <a href="html/libvirt-libvirt-nodedev.html">node device</a>,
-          <a href="html/libvirt-libvirt-nwfilter.html">network filter</a>,
-          <a href="html/libvirt-libvirt-secret.html">secret</a>,
-          <a href="html/libvirt-libvirt-storage.html">storage</a>,
-          <a href="html/libvirt-libvirt-stream.html">stream</a>
-          and
-          <a href="html/index-admin.html">admin</a>,
-          <a href="html/index-qemu.html">QEMU</a>,
-          <a href="html/index-lxc.html">LXC</a> libs
-        </dd>
-
-        <dt><a href="bindings.html">Language bindings and API modules</a></dt>
-        <dd>Bindings of the libvirt API for
-          <a href="csharp.html">c#</a>,
-          <a href="https://godoc.org/github.com/libvirt/libvirt-go">go</a>,
-          <a href="java.html">java</a>,
-          <a href="https://libvirt.org/ocaml/">ocaml</a>,
-          <a href="http://search.cpan.org/dist/Sys-Virt/">perl</a>,
-          <a href="python.html">python</a>,
-          <a href="php.html">php</a>,
-          <a href="https://libvirt.org/ruby/">ruby</a>
-          and integration API modules for
-          <a href="dbus.html">D-Bus</a></dd>
-
-
-        <dt><a href="format.html">XML schemas</a></dt>
-        <dd>Description of the XML schemas for
-          <a href="formatdomain.html">domains</a>,
-          <a href="formatnetwork.html">networks</a>,
-          <a href="formatnetworkport.html">network ports</a>,
-          <a href="formatnwfilter.html">network filtering</a>,
-          <a href="formatstorage.html">storage</a>,
-          <a href="formatstorageencryption.html">storage encryption</a>,
-          <a href="formatcaps.html">capabilities</a>,
-          <a href="formatdomaincaps.html">domain capabilities</a>,
-          <a href="formatstoragecaps.html">storage pool capabilities</a>,
-          <a href="formatnode.html">node devices</a>,
-          <a href="formatsecret.html">secrets</a>,
-          <a href="formatsnapshot.html">snapshots</a>,
-          <a href="formatcheckpoint.html">checkpoints</a>,
-          <a href="formatbackup.html">backup jobs</a></dd>
-
-        <dt><a href="uri.html">URI format</a></dt>
-        <dd>The URI formats used for connecting to libvirt</dd>
-
-        <dt><a href="cgroups.html">CGroups</a></dt>
-        <dd>Control groups integration</dd>
-
-        <dt><a href="drivers.html">Drivers</a></dt>
-        <dd>Hypervisor specific driver information</dd>
-
-        <dt><a href="support.html">Support guarantees</a></dt>
-        <dd>Details of support status for various interfaces</dd>
-
-        <dt><a href="hvsupport.html">Driver support</a></dt>
-        <dd>matrix of API support per hypervisor per release</dd>
-
-        <dt><a href="kbase.html">Knowledge Base</a></dt>
-        <dd>Task oriented guides to key features</dd>
-      </dl>
-    </div>
-
-    <div class="panel">
-      <h2>Project development</h2>
-      <dl>
-        <dt><a href="hacking.html">Contributor guidelines</a></dt>
-        <dd>General hacking guidelines for contributors</dd>
-
-        <dt><a href="styleguide.html">Docs style guide</a></dt>
-        <dd>Style guidelines for reStructuredText docs</dd>
-
-        <dt><a href="strategy.html">Project strategy</a></dt>
-        <dd>Sets a vision for future direction &amp; technical choices</dd>
-
-        <dt><a href="bugs.html">Bug reports</a></dt>
-        <dd>How and where to report bugs and request features</dd>
-
-        <dt><a href="compiling.html">Compiling</a></dt>
-        <dd>How to compile libvirt</dd>
-
-        <dt><a href="goals.html">Goals</a></dt>
-        <dd>Terminology and goals of libvirt API</dd>
-
-        <dt><a href="api.html">API concepts</a></dt>
-        <dd>The libvirt API concepts</dd>
-
-        <dt><a href="api_extension.html">API extensions</a></dt>
-        <dd>Adding new public libvirt APIs</dd>
-
-        <dt><a href="internals/eventloop.html">Event loop and worker pool</a></dt>
-        <dd>Libvirt's event loop and worker pool mode</dd>
-
-        <dt><a href="internals/command.html">Spawning commands</a></dt>
-        <dd>Spawning commands from libvirt driver code</dd>
-
-        <dt><a href="internals/rpc.html">RPC protocol &amp; APIs</a></dt>
-        <dd>RPC protocol information and API / dispatch guide</dd>
-
-        <dt><a href="internals/locking.html">Lock managers</a></dt>
-        <dd>Use lock managers to protect disk content</dd>
-
-        <dt><a href="testsuites.html">Functional testing</a></dt>
-        <dd>Testing libvirt with <a href="testtck.html">TCK test suite</a> and
-         <a href="testapi.html">Libvirt-test-API</a></dd>
-      </dl>
-    </div>
-
-    <br class="clear"/>
-
-  </body>
-</html>

docs/downloads.html.in

@@ -1,524 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Downloads</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="releases">Project modules</a></h2>
-
-    <p>
-      The libvirt project maintains a number of inter-related modules beyond
-      the core C library/daemon.
-    </p>
-
-    <table class="top_table downloads">
-      <thead>
-        <tr>
-          <th>Module</th>
-          <th>Releases</th>
-          <th>GIT Repo</th>
-          <th>GIT Mirrors</th>
-          <th>Resources</th>
-        </tr>
-      </thead>
-      <tbody>
-        <tr>
-          <td>libvirt</td>
-          <td>
-            <a href="https://libvirt.org/sources/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt">github</a>
-          </td>
-          <td>
-            <a href="html/index.html">api ref</a>
-            <a href="news.html">changes</a>
-          </td>
-        </tr>
-        <tr>
-          <th colspan="7">Language bindings</th>
-        </tr>
-        <tr>
-          <td>C#</td>
-          <td>
-            <a href="https://libvirt.org/sources/csharp/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-csharp.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-csharp">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-csharp">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Go</td>
-          <td>
-            <a href="https://libvirt.org/sources/go/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-go.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-go">github</a>
-          </td>
-          <td>
-            <a href="https://godoc.org/github.com/libvirt/libvirt-go">api ref</a>
-          </td>
-        </tr>
-        <tr>
-          <td>Java</td>
-          <td>
-            <a href="https://libvirt.org/sources/java/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-java.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-java">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-java">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>OCaml</td>
-          <td>
-            <a href="https://libvirt.org/sources/ocaml/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-ocaml">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-ocaml">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Perl (Sys::Virt)</td>
-          <td>
-            <a href="https://metacpan.org/release/Sys-Virt/">cpan</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-perl.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-perl">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-perl">github</a>
-          </td>
-          <td>
-            <a href="https://metacpan.org/release/Sys-Virt/">api ref</a>
-            <a href="https://libvirt.org/git/?p=libvirt-perl.git;a=blob;f=Changes;hb=HEAD">changes</a>
-          </td>
-        </tr>
-        <tr>
-          <td>PHP</td>
-          <td>
-            <a href="https://libvirt.org/sources/php/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-php">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-php">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Python</td>
-          <td>
-            <a href="https://libvirt.org/sources/python/">libvirt</a>
-            <a href="https://pypi.python.org/pypi/libvirt-python">pypi</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-python.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-python">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-python">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Ruby</td>
-          <td>
-            <a href="https://libvirt.org/sources/ruby/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=ruby-libvirt.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/ruby-libvirt">gitlab</a>
-            <a href="https://github.com/libvirt/ruby-libvirt">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Rust</td>
-          <td>
-            <a href="https://libvirt.org/sources/rust/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-rust.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-rust">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-rust">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <th colspan="7">Integration modules</th>
-        </tr>
-        <tr>
-          <td>GLib / GConfig / GObject</td>
-          <td>
-            <a href="https://libvirt.org/sources/glib/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-glib.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-glib">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-glib">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Go XML</td>
-          <td>
-            <a href="https://libvirt.org/sources/go/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-go-xml.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-go-xml">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-go-xml">github</a>
-          </td>
-          <td>
-            <a href="https://godoc.org/github.com/libvirt/libvirt-go-xml">api ref</a>
-          </td>
-        </tr>
-        <tr>
-          <td>D-Bus</td>
-          <td>
-            <a href="https://libvirt.org/sources/dbus/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-dbus.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-dbus">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-dbus">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Console Proxy</td>
-          <td>
-            <a href="https://libvirt.org/sources/consoleproxy/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-console-proxy.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-console-proxy">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-console-proxy">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>CIM provider</td>
-          <td>
-            <a href="https://libvirt.org/sources/CIM/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-cim.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-cim">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-cim">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>CIM utils</td>
-          <td>
-            <a href="https://libvirt.org/sources/CIM/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libcmpiutil.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libcmpiutil">gitlab</a>
-            <a href="https://github.com/libvirt/libcmpiutil">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>SNMP</td>
-          <td>
-            <a href="https://libvirt.org/sources/snmp/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-snmp.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-snmp">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-snmp">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Application Sandbox</td>
-          <td>
-            <a href="https://libvirt.org/sources/sandbox/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-sandbox.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-sandbox">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-sandbox">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <th colspan="7">Testing</th>
-        </tr>
-        <tr>
-          <td>TCK</td>
-          <td>
-            <a href="https://libvirt.org/sources/tck/">libvirt</a>
-          </td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-tck.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-tck">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-tck">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Test API</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-test-API.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-test-API">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-test-API">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>Jenkins Config</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-jenkins-ci">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-jenkins-ci">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>CIM Test</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=cimtest.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/cimtest">gitlab</a>
-            <a href="https://github.com/libvirt/cimtest">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <th colspan="7">Documentation</th>
-        </tr>
-        <tr>
-          <td>Publican Brand</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-publican.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-publican">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-publican">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>App Development Guide</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-appdev-guide.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-appdev-guide">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-appdev-guide">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>App Development Guide Python</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-appdev-guide-python.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-appdev-guide-python">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-appdev-guide-python">github</a>
-          </td>
-          <td></td>
-        </tr>
-        <tr>
-          <td>virsh Command Reference</td>
-          <td></td>
-          <td>
-            <a href="https://libvirt.org/git/?p=libvirt-virshcmdref.git;a=summary">libvirt</a>
-          </td>
-          <td>
-            <a href="https://gitlab.com/libvirt/libvirt-virshcmdref">gitlab</a>
-            <a href="https://github.com/libvirt/libvirt-virshcmdref">github</a>
-          </td>
-          <td></td>
-        </tr>
-      </tbody>
-    </table>
-
-    <h2>Primary download site</h2>
-
-    <p>
-      Most modules have releases made available for download on the project
-      site via HTTPS. Some modules are instead made available at alternative
-      locations, for example, the Perl binding is made available only on CPAN.
-    </p>
-
-    <ul>
-      <li><a href="https://libvirt.org/sources/">libvirt.org HTTPS server</a></li>
-    </ul>
-
-    <h2><a id="schedule">Primary release schedule</a></h2>
-
-    <p>
-      The core libvirt module follows a time based plan, with releases made
-      once a month on the 1st of each month give or take a few days. The only
-      exception is at the start of the year where there are two 6 weeks gaps
-      (first release in the middle of Jan, then skip the Feb release), giving
-      a total of 11 releases a year. The Python and Perl modules will aim to
-      release at the same time as the core libvirt module. Other modules have
-      independent ad-hoc releases with no fixed time schedule.
-    </p>
-
-    <h2><a id="numbering">Release numbering</a></h2>
-
-    <p>
-      Since libvirt 2.0.0, a time based version numbering rule
-      is applied to the core library releases. As such, the changes
-      in version number have do not have any implications with respect
-      to the scope of features or bugfixes included, the stability of
-      the code, or the API / ABI compatibility (libvirt API / ABI is
-      guaranteed stable forever). The rules applied for changing the
-      libvirt version number are:
-    </p>
-
-    <dl>
-      <dt><code>major</code></dt>
-      <dd>incremented by 1 for the first release of the year (the
-        Jan 15th release)</dd>
-      <dt><code>minor</code></dt>
-      <dd>reset to 0 with every major increment, otherwise incremented by 1
-        for each monthly release from git master</dd>
-      <dt><code>micro</code></dt>
-      <dd>always 0 for releases from git master, incremented by 1
-        for each stable maintenance release</dd>
-    </dl>
-
-    <p>
-      Prior to 2.0.0, the major/minor numbers were incremented
-      fairly arbitrarily, and maintenance releases appended a
-      fourth digit. The language bindings will aim to use the
-      same version number as the most recent core library API
-      they support. The other modules have their own distinct
-      release numbering sequence, though they generally aim
-      to follow the above rules for incrementing major/minor/micro
-      digits.
-    </p>
-
-    <h2><a id="maintenance">Maintenance releases</a></h2>
-    <p>
-      In the git repository are several stable maintenance branches
-      for the core library, matching the
-      pattern <code>v<i>major</i>.<i>minor</i>-maint</code>;
-      these branches are forked off the corresponding
-      <code>v<i>major</i>.<i>minor</i>.0</code> formal
-      release, and may have further releases of the
-      form <code>v<i>major</i>.<i>minor</i>.<i>micro</i></code>.
-      These maintenance branches should only contain bug fixes, and no
-      new features, backported from the master branch, and are
-      supported as long as at least one downstream distribution
-      expresses interest in a given branch.  These maintenance
-      branches are considered during CVE analysis. In contrast
-      to the primary releases which are made once a month, there
-      is no formal schedule for the maintenance releases, which
-      are made whenever there is a need to make available key
-      bugfixes to downstream consumers. The language bindings
-      and other modules generally do not provide stable branch
-      releases.
-    </p>
-
-    <p>
-      For more details about contents of maintenance releases, see
-      <a href="http://wiki.libvirt.org/page/Maintenance_Releases">the
-      wiki page</a>.
-    </p>
-
-    <h2><a id="git">GIT source repository</a></h2>
-
-    <p>
-      All modules maintained by the libvirt project have their primary
-      source available in the <a href="https://libvirt.org/git/">project GIT server</a>.
-      Each module can be cloned anonymously using:
-    </p>
-
-    <pre>
-git clone https://libvirt.org/git/[module name].git</pre>
-
-    <p>
-      The <code>git://</code> protocol is also available if desired, but
-      <code>https://</code> is encouraged, since it is more reliable when
-      faced with strict firewalls.
-    </p>
-
-    <pre>
-git clone git://libvirt.org/[module name].git</pre>
-
-    <p>
-      In addition to this primary repository, there are the following read-only git
-      repositories which mirror the master one. Note that we currently do not
-      use the full set of features on these mirrors (e.g. pull requests on
-      GitHub, so please don't use them). All patch review and discussion only
-      occurs on the <a href="contact.html">libvir-list</a> mailing list. Also
-      note that some repositories listed below allow HTTP checkouts too.
-    </p>
-
-    <pre>
-<a href="https://github.com/libvirt/">https://github.com/libvirt/</a>
-<a href="https://gitlab.com/libvirt/libvirt">https://gitlab.com/libvirt/</a></pre>
-
-  </body>
-</html>

docs/drivers.html.in

@@ -1,42 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Internal drivers</h1>
-
-    <ul>
-      <li><a href="#hypervisor">Hypervisor drivers</a></li>
-      <li><a href="storage.html">Storage drivers</a></li>
-      <li><a href="drvnodedev.html">Node device driver</a></li>
-    </ul>
-
-    <p>
-      The libvirt public API delegates its implementation to one or
-      more internal drivers, depending on the <a href="uri.html">connection URI</a>
-      passed when initializing the library. There is always a hypervisor driver
-      active, and if the libvirt daemon is available there will usually be a
-      network and storage driver active.
-    </p>
-
-    <h2><a id="hypervisor">Hypervisor drivers</a></h2>
-
-    <p>
-      The hypervisor drivers currently supported by libvirt are:
-    </p>
-
-    <ul>
-      <li><strong><a href="drvlxc.html">LXC</a></strong> - Linux Containers</li>
-      <li><strong><a href="drvopenvz.html">OpenVZ</a></strong></li>
-      <li><strong><a href="drvqemu.html">QEMU</a></strong></li>
-      <li><strong><a href="drvtest.html">Test</a></strong> - Used for testing</li>
-      <li><strong><a href="drvvbox.html">VirtualBox</a></strong></li>
-      <li><strong><a href="drvesx.html">VMware ESX</a></strong></li>
-      <li><strong><a href="drvvmware.html">VMware Workstation/Player</a></strong></li>
-      <li><strong><a href="drvxen.html">Xen</a></strong></li>
-      <li><strong><a href="drvhyperv.html">Microsoft Hyper-V</a></strong></li>
-      <li><strong><a href="drvvirtuozzo.html">Virtuozzo</a></strong></li>
-      <li><strong><a href="drvbhyve.html">Bhyve</a></strong> - The BSD Hypervisor</li>
-    </ul>
-
-  </body>
-</html>

docs/drvbhyve.html.in

@@ -1,493 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Bhyve driver</h1>
-
-    <ul id="toc"></ul>
-
-<p>
-Bhyve is a FreeBSD hypervisor. It first appeared in FreeBSD 10.0. However, it's
-recommended to keep tracking FreeBSD 10-STABLE to make sure all new features
-of bhyve are supported.
-
-In order to enable bhyve on your FreeBSD host, you'll need to load the <code>vmm</code>
-kernel module. Additionally, <code>if_tap</code> and <code>if_bridge</code> modules
-should be loaded for networking support. Also, <span class="since">since 3.2.0</span> the
-<code>virt-host-validate(1)</code> supports the bhyve host validation and could be
-used like this:
-</p>
-
-<pre>
-$ virt-host-validate bhyve
- BHYVE: Checking for vmm module                                              : PASS
- BHYVE: Checking for if_tap module                                           : PASS
- BHYVE: Checking for if_bridge module                                        : PASS
- BHYVE: Checking for nmdm module                                             : PASS
-$
-</pre>
-
-<p>
-Additional information on bhyve could be obtained on <a href="http://bhyve.org/">bhyve.org</a>.
-</p>
-
-<h2><a id="uri">Connections to the Bhyve driver</a></h2>
-<p>
-The libvirt bhyve driver is a single-instance privileged driver. Some sample
-connection URIs are:
-</p>
-
-<pre>
-bhyve:///system                     (local access)
-bhyve+unix:///system                (local access)
-bhyve+ssh://root@example.com/system (remote access, SSH tunnelled)
-</pre>
-
-<h2><a id="exconfig">Example guest domain XML configurations</a></h2>
-
-<h3>Example config</h3>
-<p>
-The bhyve driver in libvirt is in its early stage and under active development. So it supports
-only limited number of features bhyve provides.
-</p>
-
-<p>
-Note: in older libvirt versions, only a single network device and a single
-disk device were supported per-domain. However,
-<span class="since">since 1.2.6</span> the libvirt bhyve driver supports
-up to 31 PCI devices.
-</p>
-
-<p>
-Note: the Bhyve driver in libvirt will boot whichever device is first. If you
-want to install from CD, put the CD device first. If not, put the root HDD
-first.
-</p>
-
-<p>
-Note: Only the SATA bus is supported. Only <code>cdrom</code>- and
-<code>disk</code>-type disks are supported.
-</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    &lt;name&gt;bhyve&lt;/name&gt;
-    &lt;uuid&gt;df3be7e7-a104-11e3-aeb0-50e5492bd3dc&lt;/uuid&gt;
-    &lt;memory&gt;219136&lt;/memory&gt;
-    &lt;currentMemory&gt;219136&lt;/currentMemory&gt;
-    &lt;vcpu&gt;1&lt;/vcpu&gt;
-    &lt;os&gt;
-       &lt;type&gt;hvm&lt;/type&gt;
-    &lt;/os&gt;
-    &lt;features&gt;
-      &lt;apic/&gt;
-      &lt;acpi/&gt;
-    &lt;/features&gt;
-    &lt;clock offset='utc'/&gt;
-    &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-    &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-    &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-    &lt;devices&gt;
-      &lt;disk type='file'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-        &lt;source file='/path/to/bhyve_freebsd.img'/&gt;
-        &lt;target dev='hda' bus='sata'/&gt;
-      &lt;/disk&gt;
-      &lt;disk type='file' device='cdrom'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-        &lt;source file='/path/to/cdrom.iso'/&gt;
-        &lt;target dev='hdc' bus='sata'/&gt;
-        &lt;readonly/&gt;
-      &lt;/disk&gt;
-      &lt;interface type='bridge'&gt;
-        &lt;model type='virtio'/&gt;
-        &lt;source bridge="virbr0"/&gt;
-      &lt;/interface&gt;
-    &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-<p>(The &lt;disk&gt; sections may be swapped in order to install from
-<em>cdrom.iso</em>.)</p>
-
-<h3>Example config (Linux guest)</h3>
-
-<p>
-Note the addition of &lt;bootloader&gt;.
-</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    &lt;name&gt;linux_guest&lt;/name&gt;
-    &lt;uuid&gt;df3be7e7-a104-11e3-aeb0-50e5492bd3dc&lt;/uuid&gt;
-    &lt;memory&gt;131072&lt;/memory&gt;
-    &lt;currentMemory&gt;131072&lt;/currentMemory&gt;
-    &lt;vcpu&gt;1&lt;/vcpu&gt;
-    &lt;bootloader&gt;/usr/local/sbin/grub-bhyve&lt;/bootloader&gt;
-    &lt;os&gt;
-       &lt;type&gt;hvm&lt;/type&gt;
-    &lt;/os&gt;
-    &lt;features&gt;
-      &lt;apic/&gt;
-      &lt;acpi/&gt;
-    &lt;/features&gt;
-    &lt;clock offset='utc'/&gt;
-    &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-    &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-    &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-    &lt;devices&gt;
-      &lt;disk type='file' device='disk'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-        &lt;source file='/path/to/guest_hdd.img'/&gt;
-        &lt;target dev='hda' bus='sata'/&gt;
-      &lt;/disk&gt;
-      &lt;disk type='file' device='cdrom'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-        &lt;source file='/path/to/cdrom.iso'/&gt;
-        &lt;target dev='hdc' bus='sata'/&gt;
-        &lt;readonly/&gt;
-      &lt;/disk&gt;
-      &lt;interface type='bridge'&gt;
-        &lt;model type='virtio'/&gt;
-        &lt;source bridge="virbr0"/&gt;
-      &lt;/interface&gt;
-    &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-<h3>Example config (Linux UEFI guest, VNC, tablet)</h3>
-
-<p>This is an example to boot into Fedora 25 installation:</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    &lt;name&gt;fedora_uefi_vnc_tablet&lt;/name&gt;
-    &lt;memory unit='G'&gt;4&lt;/memory&gt;
-    &lt;vcpu&gt;2&lt;/vcpu&gt;
-    &lt;os&gt;
-       &lt;type&gt;hvm&lt;/type&gt;
-       <b>&lt;loader readonly=&quot;yes&quot; type=&quot;pflash&quot;&gt;/usr/local/share/uefi-firmware/BHYVE_UEFI.fd&lt;/loader&gt;</b>
-    &lt;/os&gt;
-    &lt;features&gt;
-      &lt;apic/&gt;
-      &lt;acpi/&gt;
-    &lt;/features&gt;
-    &lt;clock offset='utc'/&gt;
-    &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-    &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-    &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-    &lt;devices&gt;
-      &lt;disk type='file' device='cdrom'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-          &lt;source file='/path/to/Fedora-Workstation-Live-x86_64-25-1.3.iso'/&gt;
-        &lt;target dev='hdc' bus='sata'/&gt;
-        &lt;readonly/&gt;
-      &lt;/disk&gt;
-      &lt;disk type='file' device='disk'&gt;
-        &lt;driver name='file' type='raw'/&gt;
-        &lt;source file='/path/to/linux_uefi.img'/&gt;
-        &lt;target dev='hda' bus='sata'/&gt;
-        &lt;/disk&gt;
-      &lt;interface type='bridge'&gt;
-        &lt;model type='virtio'/&gt;
-        &lt;source bridge=&quot;virbr0&quot;/&gt;
-      &lt;/interface&gt;
-      &lt;serial type=&quot;nmdm&quot;&gt;
-        &lt;source master=&quot;/dev/nmdm0A&quot; slave=&quot;/dev/nmdm0B&quot;/&gt;
-      &lt;/serial&gt;
-      <b>&lt;graphics type='vnc' port='5904'&gt;
-        &lt;listen type='address' address='127.0.0.1'/&gt;
-      &lt;/graphics&gt;
-      &lt;controller type='usb' model='nec-xhci'/&gt;
-      &lt;input type='tablet' bus='usb'/&gt;</b>
-    &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-<p>Please refer to the <a href="#uefi">UEFI</a> section for a more detailed explanation.</p>
-
-<h2><a id="usage">Guest usage / management</a></h2>
-
-<h3><a id="console">Connecting to a guest console</a></h3>
-
-<p>
-Guest console connection is supported through the <code>nmdm</code> device. It could be enabled by adding
-the following to the domain XML (<span class="since">Since 1.2.4</span>):
-</p>
-
-<pre>
-...
-&lt;devices&gt;
-  &lt;serial type="nmdm"&gt;
-    &lt;source master="/dev/nmdm0A" slave="/dev/nmdm0B"/&gt;
-  &lt;/serial&gt;
-&lt;/devices&gt;
-...</pre>
-
-
-<p>Make sure to load the <code>nmdm</code> kernel module if you plan to use that.</p>
-
-<p>
-Then <code>virsh console</code> command can be used to connect to the text console
-of a guest.</p>
-
-<p><b>NB:</b> Some versions of bhyve have a bug that prevents guests from booting
-until the console is opened by a client. This bug was fixed in FreeBSD
-<a href="http://svnweb.freebsd.org/changeset/base/262884">r262884</a>. If
-an older version is used, one either has to open a console manually with <code>virsh console</code>
-to let a guest boot or start a guest using:</p>
-
-<pre>start --console domname</pre>
-
-<p><b>NB:</b> A bootloader configured to require user interaction will prevent
-the domain from starting (and thus <code>virsh console</code> or <code>start
---console</code> from functioning) until the user interacts with it manually on
-the VM host. Because users typically do not have access to the VM host,
-interactive bootloaders are unsupported by libvirt. <em>However,</em> if you happen to
-run into this scenario and also happen to have access to the Bhyve host
-machine, you may select a boot option and allow the domain to finish starting
-by using an alternative terminal client on the VM host to connect to the
-domain-configured null modem device. One example (assuming
-<code>/dev/nmdm0B</code> is configured as the slave end of the domain serial
-device) is:</p>
-
-<pre>cu -l /dev/nmdm0B</pre>
-
-<h3><a id="xmltonative">Converting from domain XML to Bhyve args</a></h3>
-
-<p>
-The <code>virsh domxml-to-native</code> command can preview the actual
-<code>bhyve</code> commands that will be executed for a given domain.
-It outputs two lines, the first line is a <code>bhyveload</code> command and
-the second is a <code>bhyve</code> command.
-</p>
-
-<p>Please note that the <code>virsh domxml-to-native</code> doesn't do any
-real actions other than printing the command, for example, it doesn't try to
-find a proper TAP interface and create it, like what is done when starting
-a domain; and always returns <code>tap0</code> for the network interface. So
-if you're going to run these commands manually, most likely you might want to
-tweak them.</p>
-
-<pre>
-# virsh -c "bhyve:///system"  domxml-to-native --format bhyve-argv --xml /path/to/bhyve.xml
-/usr/sbin/bhyveload -m 214 -d /home/user/vm1.img vm1
-/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1
-</pre>
-
-<h3><a id="zfsvolume">Using ZFS volumes</a></h3>
-
-<p>It's possible to use ZFS volumes as disk devices <span class="since">since 1.2.8</span>.
-An example of domain XML device entry for that will look like:</p>
-
-<pre>
-...
-&lt;disk type='volume' device='disk'&gt;
-  &lt;source pool='zfspool' volume='vol1'/&gt;
-  &lt;target dev='vdb' bus='virtio'/&gt;
-&lt;/disk&gt;
-...</pre>
-
-<p>Please refer to the <a href="storage.html">Storage documentation</a> for more details on storage
-management.</p>
-
-<h3><a id="grubbhyve">Using grub2-bhyve or Alternative Bootloaders</a></h3>
-
-<p>It's possible to boot non-FreeBSD guests by specifying an explicit
-bootloader, e.g. <code>grub-bhyve(1)</code>. Arguments to the bootloader may be
-specified as well. If the bootloader is <code>grub-bhyve</code> and arguments
-are omitted, libvirt will try and infer boot ordering from user-supplied
-&lt;boot order='N'&gt; configuration in the domain. Failing that, it will boot
-the first disk in the domain (either <code>cdrom</code>- or
-<code>disk</code>-type devices). If the disk type is <code>disk</code>, it will
-attempt to boot from the first partition in the disk image.</p>
-
-<pre>
-...
-&lt;bootloader&gt;/usr/local/sbin/grub-bhyve&lt;/bootloader&gt;
-&lt;bootloader_args&gt;...&lt;/bootloader_args&gt;
-...
-</pre>
-
-<p>Caveat: <code>bootloader_args</code> does not support any quoting.
-Filenames, etc, must not have spaces or they will be tokenized incorrectly.</p>
-
-<h3><a id="uefi">Using UEFI bootrom, VNC, and USB tablet</a></h3>
-
-<p><span class="since">Since 3.2.0</span>, in addition to <a href="#grubbhyve">grub-bhyve</a>,
-non-FreeBSD guests could be also booted using an UEFI boot ROM, provided both guest OS and
-installed <code>bhyve(1)</code> version support UEFI. To use that, <code>loader</code>
-should be specified in the <code>os</code> section:</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    ...
-    &lt;os&gt;
-       &lt;type&gt;hvm&lt;/type&gt;
-       &lt;loader readonly="yes" type="pflash"&gt;/usr/local/share/uefi-firmware/BHYVE_UEFI.fd&lt;/loader&gt;
-    &lt;/os&gt;
-    ...
-</pre>
-
-<p>This uses the UEFI firmware provided by
-the <a href="https://www.freshports.org/sysutils/bhyve-firmware/">sysutils/bhyve-firmware</a>
-FreeBSD port.</p>
-
-<p>VNC and the tablet input device could be configured this way:</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    &lt;devices&gt;
-      ...
-      &lt;graphics type='vnc' port='5904'&gt;
-        &lt;listen type='address' address='127.0.0.1'/&gt;
-      &lt;/graphics&gt;
-      &lt;controller type='usb' model='nec-xhci'/&gt;
-      &lt;input type='tablet' bus='usb'/&gt;
-    &lt;/devices&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<p>This way, VNC will be accessible on <code>127.0.0.1:5904</code>.</p>
-
-<p>Please note that the tablet device requires to have a USB controller
-of the <code>nec-xhci</code> model. Currently, only a single controller of this
-type and a single tablet are supported per domain.</p>
-
-<p><span class="since">Since 3.5.0</span>, it's possible to configure how the video device is exposed
-to the guest using the <code>vgaconf</code> attribute:</p>
-
-<pre>
-&lt;domain type='bhyve'&gt;
-    &lt;devices&gt;
-    ...
-      &lt;graphics type='vnc' port='5904'&gt;
-        &lt;listen type='address' address='127.0.0.1'/&gt;
-      &lt;/graphics&gt;
-      &lt;video&gt;
-        &lt;driver vgaconf='on'/&gt;
-        &lt;model type='gop' heads='1' primary='yes'/&gt;
-      &lt;/video&gt;
-      ...
-    &lt;/devices&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<p>If not specified, bhyve's default mode for <code>vgaconf</code>
-will be used. Please refer to the
-<a href="https://www.freebsd.org/cgi/man.cgi?query=bhyve&amp;sektion=8&amp;manpath=FreeBSD+12-current">bhyve(8)</a>
-manual page and the <a href="https://wiki.freebsd.org/bhyve">bhyve wiki</a> for more details on using
-the <code>vgaconf</code> option.</p>
-
-<p><span class="since">Since 3.7.0</span>, it's possible to use <code>autoport</code>
-to let libvirt allocate VNC port automatically (instead of explicitly specifying
-it with the <code>port</code> attribute):</p>
-
-<pre>
-    &lt;graphics type='vnc' autoport='yes'&gt;
-</pre>
-
-<h3><a id="clockconfig">Clock configuration</a></h3>
-
-<p>Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in
-<a href="http://svnweb.freebsd.org/changeset/base/284894">r284894</a> for <i>10-STABLE</i> and
-in <a href="http://svnweb.freebsd.org/changeset/base/279225">r279225</a> for <i>-CURRENT</i>.
-It's possible to use this in libvirt <span class="since">since 1.2.18</span>, just place the
-following to domain XML:</p>
-
-<pre>
-&lt;domain type="bhyve"&gt;
-    ...
-    &lt;clock offset='utc'/&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<p>Please note that if you run the older bhyve version that doesn't support UTC time, you'll
-fail to start a domain. As UTC is used as a default when you do not specify clock settings,
-you'll need to explicitly specify 'localtime' in this case:</p>
-
-<pre>
-&lt;domain type="bhyve"&gt;
-    ...
-    &lt;clock offset='localtime'/&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<h3><a id="e1000">e1000 NIC</a></h3>
-
-<p>As of <a href="https://svnweb.freebsd.org/changeset/base/302504">r302504</a> bhyve
-supports Intel e1000 network adapter emulation. It's supported in libvirt
-<span class="since">since 3.1.0</span> and could be used as follows:</p>
-
-<pre>
-...
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='virbr0'/&gt;
-      &lt;model type='<b>e1000</b>'/&gt;
-    &lt;/interface&gt;
-...
-</pre>
-
-<h3><a id="wired">Wiring guest memory</a></h3>
-
-<p><span class="since">Since 4.4.0</span>, it's possible to specify that guest memory should
-be wired and cannot be swapped out as follows:</p>
-<pre>
-&lt;domain type="bhyve"&gt;
-    ...
-    &lt;memoryBacking&gt;
-      &lt;locked/&gt;
-    &lt;/memoryBacking&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<h3><a id="cputopology">CPU topology</a></h3>
-
-<p><span class="since">Since 4.5.0</span>, it's possible to specify guest CPU topology, if bhyve
-supports that. Support for specifying guest CPU topology was added to bhyve in
-<a href="http://svnweb.freebsd.org/changeset/base/332298">r332298</a> for <i>-CURRENT</i>.
-Example:</p>
-<pre>
-&lt;domain type="bhyve"&gt;
-    ...
-    &lt;cpu&gt;
-      &lt;topology sockets='1' cores='2' threads='1'/&gt;
-    &lt;/cpu&gt;
-    ...
-&lt;/domain&gt;
-</pre>
-
-<h3><a id="bhyvecommand">Pass-through of arbitrary bhyve commands</a></h3>
-
-<p><span class="since">Since 5.1.0</span>, it's possible to pass additional command-line
-arguments to the bhyve process when starting the domain using the
-<code>&lt;bhyve:commandline&gt;</code> element under <code>domain</code>.
-To supply an argument, use the element <code>&lt;bhyve:arg&gt;</code> with
-the attribute <code>value</code> set to additional argument to be added.
-The arg element may be repeated multiple times. To use this XML addition, it is necessary
-to issue an XML namespace request (the special <code>xmlns:<i>name</i></code> attribute)
-that pulls in <code>http://libvirt.org/schemas/domain/bhyve/1.0</code>;
-typically, the namespace is given the name of <code>bhyve</code>.
-</p>
-<p>Example:</p>
-<pre>
-&lt;domain type="bhyve" xmlns:bhyve="http://libvirt.org/schemas/domain/bhyve/1.0"&gt;
-  ...
-  &lt;bhyve:commandline&gt;
-    &lt;bhyve:arg value='-somebhyvearg'/&gt;
-  &lt;/bhyve:commandline&gt;
-&lt;/domain&gt;
-</pre>
-
-<p>Note that these extensions are for testing and development purposes only.
-They are <b>unsupported</b>, using them may result in inconsistent state,
-and upgrading either bhyve or libvirtd maybe break behavior of a domain that
-was relying on a specific commands pass-through.</p>
-
-  </body>
-</html>

docs/drvesx.html.in

@@ -1,824 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>VMware ESX hypervisor driver</h1>
-    <ul id="toc"></ul>
-    <p>
-        The libvirt VMware ESX driver can manage VMware ESX/ESXi 3.5/4.x/5.x and
-        VMware GSX 2.0, also called VMware Server 2.0, and possibly later
-        versions. <span class="since">Since 0.8.3</span> the driver can also
-        connect to a VMware vCenter 2.5/4.x/5.x (VPX).
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="http://www.vmware.com/">VMware ESX and GSX</a>
-        hypervisors
-      </li>
-    </ul>
-
-    <h2><a id="prereq">Deployment pre-requisites</a></h2>
-    <p>
-        None. Any out-of-the-box installation of VPX/ESX(i)/GSX should work. No
-        preparations are required on the server side, no libvirtd must be
-        installed on the ESX server. The driver uses version 2.5 of the remote,
-        SOAP based
-        <a href="http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/">
-        VMware Virtual Infrastructure API</a> (VI API) to communicate with the
-        ESX server, like the VMware Virtual Infrastructure Client (VI client)
-        does. Since version 4.0 this API is called
-        <a href="http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/">
-        VMware vSphere API</a>.
-    </p>
-
-    <h2><a id="uri">Connections to the VMware ESX driver</a></h2>
-    <p>
-        Some example remote connection URIs for the driver are:
-    </p>
-<pre>
-vpx://example-vcenter.com/dc1/srv1     (VPX over HTTPS, select ESX server 'srv1' in datacenter 'dc1')
-esx://example-esx.com                  (ESX over HTTPS)
-gsx://example-gsx.com                  (GSX over HTTPS)
-esx://example-esx.com/?transport=http  (ESX over HTTP)
-esx://example-esx.com/?no_verify=1     (ESX over HTTPS, but doesn't verify the server's SSL certificate)
-</pre>
-    <p>
-        <strong>Note</strong>: In contrast to other drivers, the ESX driver is
-        a client-side-only driver. It connects to the ESX server using HTTP(S).
-        Therefore, the <a href="remote.html">remote transport mechanism</a>
-        provided by the remote driver and libvirtd will not work, and you
-        cannot use URIs like <code>esx+ssh://example.com</code>.
-    </p>
-
-
-    <h3><a id="uriformat">URI Format</a></h3>
-    <p>
-        URIs have this general form (<code>[...]</code> marks an optional part).
-    </p>
-<pre>
-type://[username@]hostname[:port]/[[folder/...]datacenter/[folder/...][cluster/]server][?extraparameters]
-</pre>
-    <p>
-        The <code>type://</code> is either <code>esx://</code> or
-        <code>gsx://</code> or <code>vpx://</code> <span class="since">since 0.8.3</span>.
-        The driver selects the default port depending on the <code>type://</code>.
-        For <code>esx://</code> and <code>vpx://</code> the default HTTPS port
-        is 443, for <code>gsx://</code> it is 8333.
-        If the port parameter is given, it overrides the default port.
-    </p>
-    <p>
-        A <code>vpx://</code> connection is currently restricted to a single
-        ESX server. This might be relaxed in the future. The path part of the
-        URI is used to specify the datacenter and the ESX server in it. If the
-        ESX server is part of a cluster then the cluster has to be specified too.
-    </p>
-    <p>
-        An example: ESX server <code>example-esx.com</code> is managed by
-        vCenter <code>example-vcenter.com</code> and part of cluster
-        <code>cluster1</code>. This cluster is part of datacenter <code>dc1</code>.
-    </p>
-<pre>
-vpx://example-vcenter.com/dc1/cluster1/example-esx.com
-</pre>
-    <p>
-        Datacenters and clusters can be organized in folders, those have to be
-        specified as well. The driver can handle folders
-        <span class="since">since 0.9.7</span>.
-    </p>
-<pre>
-vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
-</pre>
-
-
-    <h4><a id="extraparams">Extra parameters</a></h4>
-    <p>
-        Extra parameters can be added to a URI as part of the query string
-        (the part following <code>?</code>). A single parameter is formed by a
-        <code>name=value</code> pair. Multiple parameters are separated by
-        <code>&amp;</code>.
-    </p>
-<pre>
-?<span style="color: #E50000">no_verify=1</span>&amp;<span style="color: #00B200">auto_answer=1</span>&amp;<span style="color: #0000E5">proxy=socks://example-proxy.com:23456</span>
-</pre>
-    <p>
-        The driver understands the extra parameters shown below.
-    </p>
-    <table class="top_table">
-        <tr>
-            <th>Name</th>
-            <th>Values</th>
-            <th>Meaning</th>
-        </tr>
-        <tr>
-            <td>
-                <code>transport</code>
-            </td>
-            <td>
-                <code>http</code> or <code>https</code>
-            </td>
-            <td>
-                Overrides the default HTTPS transport. For <code>esx://</code>
-                and <code>vpx://</code> the default HTTP port is 80, for
-                <code>gsx://</code> it is 8222.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>vcenter</code>
-            </td>
-            <td>
-                Hostname of a VMware vCenter or <code>*</code>
-            </td>
-            <td>
-                In order to perform a migration the driver needs to know the
-                VMware vCenter for the ESX server. If set to <code>*</code>,
-                the driver connects to the vCenter known to the ESX server.
-                This parameter in useful when connecting to an ESX server only.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>no_verify</code>
-            </td>
-            <td>
-                <code>0</code> or <code>1</code>
-            </td>
-            <td>
-                If set to 1, this disables libcurl client checks of the server's
-                SSL certificate. The default value is 0. See the
-                <a href="#certificates">Certificates for HTTPS</a> section for
-                details.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>auto_answer</code>
-            </td>
-            <td>
-                <code>0</code> or <code>1</code>
-            </td>
-            <td>
-                If set to 1, the driver answers all
-                <a href="#questions">questions</a> with the default answer.
-                If set to 0, questions are reported as errors. The default
-                value is 0. <span class="since">Since 0.7.5</span>.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>proxy</code>
-            </td>
-            <td>
-                <code>[type://]hostname[:port]</code>
-            </td>
-            <td>
-                Allows to specify a proxy for HTTP and HTTPS communication.
-                <span class="since">Since 0.8.2</span>.
-                The optional <code>type</code> part may be one of:
-                <code>http</code>, <code>socks</code>, <code>socks4</code>,
-                <code>socks4a</code> or <code>socks5</code>. The default is
-                <code>http</code> and <code>socks</code> is synonymous for
-                <code>socks5</code>. The optional <code>port</code> allows to
-                override the default port 1080.
-            </td>
-        </tr>
-    </table>
-
-
-    <h3><a id="auth">Authentication</a></h3>
-    <p>
-        In order to perform any useful operation the driver needs to log into
-        the ESX server. Therefore, only <code>virConnectOpenAuth</code> can be
-        used to connect to an ESX server, <code>virConnectOpen</code> and
-        <code>virConnectOpenReadOnly</code> don't work.
-        To log into an ESX server or vCenter the driver will request
-        credentials using the callback passed to the
-        <code>virConnectOpenAuth</code> function. The driver passes the
-        hostname as challenge parameter to the callback. This enables the
-        callback to distinguish between requests for ESX server and vCenter.
-    </p>
-    <p>
-        <strong>Note</strong>: During the ongoing driver development, testing
-        is done using an unrestricted <code>root</code> account. Problems may
-        occur if you use a restricted account. Detailed testing with restricted
-        accounts has not been done yet.
-    </p>
-
-
-    <h3><a id="certificates">Certificates for HTTPS</a></h3>
-    <p>
-        By default the ESX driver uses HTTPS to communicate with an ESX server.
-        Proper HTTPS communication requires correctly configured SSL
-        certificates. This certificates are different from the ones libvirt
-        uses for <a href="remote.html">secure communication over TLS</a> to a
-        libvirtd one a remote server.
-    </p>
-    <p>
-        By default the driver tries to verify the server's SSL certificate
-        using the CA certificate pool installed on your client computer. With
-        an out-of-the-box installed ESX server this won't work, because a newly
-        installed ESX server uses auto-generated self-signed certificates.
-        Those are singed by a CA certificate that is typically not known to your
-        client computer and libvirt will report an error like this one:
-    </p>
-<pre>
-error: internal error curl_easy_perform() returned an error: Peer certificate cannot be authenticated with known CA certificates (60)
-</pre>
-    <p>
-        Where are two ways to solve this problem:
-    </p>
-    <ul>
-        <li>
-            Use the <code>no_verify=1</code> <a href="#extraparams">extra parameter</a>
-            to disable server certificate verification.
-        </li>
-        <li>
-            Generate new SSL certificates signed by a CA known to your client
-            computer and replace the original ones on your ESX server. See the
-            section <i>Replace a Default Certificate with a CA-Signed Certificate</i>
-            in the <a href="http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esx_server_config.pdf">ESX Configuration Guide</a>
-        </li>
-    </ul>
-
-
-    <h3><a id="connproblems">Connection problems</a></h3>
-    <p>
-        There are also other causes for connection problems than the
-        <a href="#certificates">HTTPS certificate</a> related ones.
-    </p>
-    <ul>
-        <li>
-            As stated before the ESX driver doesn't need the
-            <a href="remote.html">remote transport mechanism</a>
-            provided by the remote driver and libvirtd, nor does the ESX driver
-            support it. Therefore, using an URI including a transport in the
-            scheme won't work. Only <a href="#uriformat">URIs as described</a>
-            are supported by the ESX driver. Here's a collection of possible
-            error messages:
-<pre>
-$ virsh -c esx+tcp://example.com/
-error: unable to connect to libvirtd at 'example.com': Connection refused
-</pre>
-<pre>
-$ virsh -c esx+tls://example.com/
-error: Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
-</pre>
-<pre>
-$ virsh -c esx+ssh://example.com/
-error: cannot recv data: ssh: connect to host example.com port 22: Connection refused
-</pre>
-<pre>
-$ virsh -c esx+ssh://example.com/
-error: cannot recv data: Resource temporarily unavailable
-</pre>
-        </li>
-        <li>
-            <span class="since">Since 0.7.0</span> libvirt contains the ESX
-            driver. Earlier versions of libvirt will report a misleading error
-            about missing certificates when you try to connect to an ESX server.
-<pre>
-$ virsh -c esx://example.com/
-error: Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
-</pre>
-            <p>
-                Don't let this error message confuse you. Setting up certificates
-                as described on the <a href="remote.html#Remote_certificates">remote transport mechanism</a> page
-                does not help, as this is not a certificate related problem.
-            </p>
-            <p>
-                To fix this problem you need to update your libvirt to 0.7.0 or newer.
-                You may also see this error when you use a libvirt version that
-                contains the ESX driver but you or your distro disabled the ESX
-                driver during compilation. <span class="since">Since 0.8.3</span>
-                the error message has been improved in this case:
-            </p>
-<pre>
-$ virsh -c esx://example.com/
-error: invalid argument in libvirt was built without the 'esx' driver
-</pre>
-        </li>
-    </ul>
-
-
-    <h2><a id="questions">Questions blocking tasks</a></h2>
-    <p>
-        Some methods of the VI API start tasks, for example
-        <code>PowerOnVM_Task()</code>. Such tasks may be blocked by questions
-        if the ESX server detects an issue with the domain that requires user
-        interaction. The ESX driver cannot prompt the user to answer a
-        question, libvirt doesn't have an API for something like this.
-    </p>
-    <p>
-        The VI API provides the <code>AnswerVM()</code> method to
-        programmatically answer a questions. So the driver has two options
-        how to handle such a situation: either answer the questions with the
-        default answer or report the question as an error and cancel the
-        blocked task if possible. The
-        <a href="#uriformat"><code>auto_answer</code></a> query parameter
-        controls the answering behavior.
-    </p>
-
-
-    <h2><a id="xmlspecial">Specialties in the domain XML config</a></h2>
-    <p>
-        There are several specialties in the domain XML config for ESX domains.
-    </p>
-
-    <h3><a id="restrictions">Restrictions</a></h3>
-    <p>
-        There are some restrictions for some values of the domain XML config.
-        The driver will complain if this restrictions are violated.
-    </p>
-    <ul>
-        <li>
-            Memory size has to be a multiple of 4096
-        </li>
-        <li>
-            Number of virtual CPU has to be 1 or a multiple of 2.
-            <span class="since">Since 4.10.0</span> any number of vCPUs is
-            supported.
-        </li>
-        <li>
-            Valid MAC address prefixes are <code>00:0c:29</code> and
-            <code>00:50:56</code>. <span class="since">Since 0.7.6</span>
-            arbitrary <a href="#macaddresses">MAC addresses</a> are supported.
-        </li>
-    </ul>
-
-
-    <h3><a id="datastore">Datastore references</a></h3>
-    <p>
-        Storage is managed in datastores. VMware uses a special path format to
-        reference files in a datastore. Basically, the datastore name is put
-        into squared braces in front of the path.
-    </p>
-<pre>
-[datastore] directory/filename
-</pre>
-    <p>
-        To define a new domain the driver converts the domain XML into a
-        VMware VMX file and uploads it to a datastore known to the ESX server.
-        Because multiple datastores may be known to an ESX server the driver
-        needs to decide to which datastore the VMX file should be uploaded.
-        The driver deduces this information from the path of the source of the
-        first file-based harddisk listed in the domain XML.
-    </p>
-
-
-    <h3><a id="macaddresses">MAC addresses</a></h3>
-    <p>
-        VMware has registered two MAC address prefixes for domains:
-        <code>00:0c:29</code> and <code>00:50:56</code>. These prefixes are
-        split into ranges for different purposes.
-    </p>
-    <table class="top_table">
-        <tr>
-            <th>Range</th>
-            <th>Purpose</th>
-        </tr>
-        <tr>
-            <td>
-                <code>00:0c:29:00:00:00</code> - <code>00:0c:29:ff:ff:ff</code>
-            </td>
-            <td>
-                An ESX server autogenerates MAC addresses from this range if
-                the VMX file doesn't contain a MAC address when trying to start
-                a domain.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>00:50:56:00:00:00</code> - <code>00:50:56:3f:ff:ff</code>
-            </td>
-            <td>
-                MAC addresses from this range can by manually assigned by the
-                user in the VI client.
-            </td>
-        </tr>
-        <tr>
-            <td>
-                <code>00:50:56:80:00:00</code> - <code>00:50:56:bf:ff:ff</code>
-            </td>
-            <td>
-                A VI client autogenerates MAC addresses from this range for
-                newly defined domains.
-            </td>
-        </tr>
-    </table>
-    <p>
-        The VMX files generated by the ESX driver always contain a MAC address,
-        because libvirt generates a random one if an interface element in the
-        domain XML file lacks a MAC address.
-        <span class="since">Since 0.7.6</span> the ESX driver sets the prefix
-        for generated MAC addresses to <code>00:0c:29</code>. Before 0.7.6
-        the <code>00:50:56</code> prefix was used. Sometimes this resulted in
-        the generation of out-of-range MAC address that were rejected by the
-        ESX server.
-    </p>
-    <p>
-        Also <span class="since">since 0.7.6</span> every MAC address outside
-        this ranges can be used. For such MAC addresses the ESX server-side
-        check is disabled in the VMX file to stop the ESX server from rejecting
-        out-of-predefined-range MAC addresses.
-    </p>
-<pre>
-ethernet0.checkMACAddress = "false"
-</pre>
-
-
-    <h3><a id="hardware">Available hardware</a></h3>
-    <p>
-        VMware ESX supports different models of SCSI controllers and network
-        cards.
-    </p>
-
-    <h4>SCSI controller models</h4>
-    <dl>
-        <dt><code>auto</code></dt>
-        <dd>
-            This isn't an actual controller model. If specified the ESX driver
-            tries to detect the SCSI controller model referenced in the
-            <code>.vmdk</code> file and use it. Autodetection fails when a
-            SCSI controller has multiple disks attached and the SCSI controller
-            models referenced in the <code>.vmdk</code> files are inconsistent.
-            <span class="since">Since 0.8.3</span>
-        </dd>
-        <dt><code>buslogic</code></dt>
-        <dd>
-            BusLogic SCSI controller for older guests.
-        </dd>
-        <dt><code>lsilogic</code></dt>
-        <dd>
-            LSI Logic SCSI controller for recent guests.
-        </dd>
-        <dt><code>lsisas1068</code></dt>
-        <dd>
-            LSI Logic SAS 1068 controller. <span class="since">Since 0.8.0</span>
-        </dd>
-        <dt><code>vmpvscsi</code></dt>
-        <dd>
-            Special VMware Paravirtual SCSI controller, requires VMware tools inside
-            the guest. See <a href="http://kb.vmware.com/kb/1010398">VMware KB1010398</a>
-            for details. <span class="since">Since 0.8.3</span>
-        </dd>
-    </dl>
-    <p>
-        Here a domain XML snippet:
-    </p>
-<pre>
-...
-&lt;disk type='file' device='disk'&gt;
-  &lt;source file='[local-storage] Fedora11/Fedora11.vmdk'/&gt;
-  &lt;target dev='sda' bus='scsi'/&gt;
-  &lt;address type='drive' controller='0' bus='0' unit='0'/&gt;
-&lt;/disk&gt;
-&lt;controller type='scsi' index='0' model='<strong>lsilogic</strong>'/&gt;
-...
-</pre>
-    <p>
-        The controller element is supported <span class="since">since 0.8.2</span>.
-        Prior to this <code>&lt;driver name='lsilogic'/&gt;</code> was abused to
-        specify the SCSI controller model. This attribute usage is deprecated now.
-    </p>
-<pre>
-...
-&lt;disk type='file' device='disk'&gt;
-  &lt;driver name='<strong>lsilogic</strong>'/&gt;
-  &lt;source file='[local-storage] Fedora11/Fedora11.vmdk'/&gt;
-  &lt;target dev='sda' bus='scsi'/&gt;
-&lt;/disk&gt;
-...
-</pre>
-
-
-    <h4>Network card models</h4>
-    <dl>
-        <dt><code>vlance</code></dt>
-        <dd>
-            AMD PCnet32 network card for older guests.
-        </dd>
-        <dt><code>vmxnet</code>, <code>vmxnet2</code>, <code>vmxnet3</code></dt>
-        <dd>
-            Special VMware VMXnet network card, requires VMware tools inside
-            the guest. See <a href="http://kb.vmware.com/kb/1001805">VMware KB1001805</a>
-            for details.
-        </dd>
-        <dt><code>e1000</code></dt>
-        <dd>
-            Intel E1000 network card for recent guests.
-        </dd>
-    </dl>
-    <p>
-        Here a domain XML snippet:
-    </p>
-<pre>
-...
-&lt;interface type='bridge'&gt;
-  &lt;mac address='00:50:56:25:48:c7'/&gt;
-  &lt;source bridge='VM Network'/&gt;
-  &lt;model type='<strong>e1000</strong>'/&gt;
-&lt;/interface&gt;
-...
-</pre>
-
-
-    <h2><a id="importexport">Import and export of domain XML configs</a></h2>
-    <p>
-        The ESX driver currently supports a native config format known as
-        <code>vmware-vmx</code> to handle VMware VMX configs.
-    </p>
-
-
-    <h3><a id="xmlimport">Converting from VMware VMX config to domain XML config</a></h3>
-    <p>
-        The <code>virsh domxml-from-native</code> provides a way to convert an
-        existing VMware VMX config into a domain XML config that can then be
-        used by libvirt.
-    </p>
-<pre>
-$ cat &gt; demo.vmx &lt;&lt; EOF
-#!/usr/bin/vmware
-config.version = "8"
-virtualHW.version = "4"
-floppy0.present = "false"
-nvram = "Fedora11.nvram"
-deploymentPlatform = "windows"
-virtualHW.productCompatibility = "hosted"
-tools.upgrade.policy = "useGlobal"
-powerType.powerOff = "default"
-powerType.powerOn = "default"
-powerType.suspend = "default"
-powerType.reset = "default"
-displayName = "Fedora11"
-extendedConfigFile = "Fedora11.vmxf"
-scsi0.present = "true"
-scsi0.sharedBus = "none"
-scsi0.virtualDev = "lsilogic"
-memsize = "1024"
-scsi0:0.present = "true"
-scsi0:0.fileName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11.vmdk"
-scsi0:0.deviceType = "scsi-hardDisk"
-ide0:0.present = "true"
-ide0:0.clientDevice = "true"
-ide0:0.deviceType = "cdrom-raw"
-ide0:0.startConnected = "false"
-ethernet0.present = "true"
-ethernet0.networkName = "VM Network"
-ethernet0.addressType = "vpx"
-ethernet0.generatedAddress = "00:50:56:91:48:c7"
-chipset.onlineStandby = "false"
-guestOSAltName = "Red Hat Enterprise Linux 5 (32-Bit)"
-guestOS = "rhel5"
-uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
-snapshot.action = "keep"
-sched.cpu.min = "0"
-sched.cpu.units = "mhz"
-sched.cpu.shares = "normal"
-sched.mem.minsize = "0"
-sched.mem.shares = "normal"
-toolScripts.afterPowerOn = "true"
-toolScripts.afterResume = "true"
-toolScripts.beforeSuspend = "true"
-toolScripts.beforePowerOff = "true"
-scsi0:0.redo = ""
-tools.syncTime = "false"
-uuid.location = "56 4d b5 06 a2 bd fb eb-ae 86 f7 d8 49 27 d0 c4"
-sched.cpu.max = "unlimited"
-sched.swap.derivedName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11-7de040d8.vswp"
-tools.remindInstall = "TRUE"
-EOF
-
-$ virsh -c esx://example.com domxml-from-native vmware-vmx demo.vmx
-Enter username for example.com [root]:
-Enter root password for example.com:
-&lt;domain type='vmware'&gt;
-  &lt;name&gt;Fedora11&lt;/name&gt;
-  &lt;uuid&gt;50115e16-9bdc-49d7-f171-53c4d7f91710&lt;/uuid&gt;
-  &lt;memory&gt;1048576&lt;/memory&gt;
-  &lt;currentMemory&gt;1048576&lt;/currentMemory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch='i686'&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;clock offset='utc'/&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='[local-storage] Fedora11/Fedora11.vmdk'/&gt;
-      &lt;target dev='sda' bus='scsi'/&gt;
-      &lt;address type='drive' controller='0' bus='0' unit='0'/&gt;
-    &lt;/disk&gt;
-    &lt;controller type='scsi' index='0' model='lsilogic'/&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='00:50:56:91:48:c7'/&gt;
-      &lt;source bridge='VM Network'/&gt;
-    &lt;/interface&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-
-    <h3><a id="xmlexport">Converting from domain XML config to VMware VMX config</a></h3>
-    <p>
-      The <code>virsh domxml-to-native</code> provides a way to convert a
-      domain XML config into a VMware VMX config.
-    </p>
-<pre>
-$ cat &gt; demo.xml &lt;&lt; EOF
-&lt;domain type='vmware'&gt;
-  &lt;name&gt;Fedora11&lt;/name&gt;
-  &lt;uuid&gt;50115e16-9bdc-49d7-f171-53c4d7f91710&lt;/uuid&gt;
-  &lt;memory&gt;1048576&lt;/memory&gt;
-  &lt;currentMemory&gt;1048576&lt;/currentMemory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch='x86_64'&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='[local-storage] Fedora11/Fedora11.vmdk'/&gt;
-      &lt;target dev='sda' bus='scsi'/&gt;
-      &lt;address type='drive' controller='0' bus='0' unit='0'/&gt;
-    &lt;/disk&gt;
-    &lt;controller type='scsi' index='0' model='lsilogic'/&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='00:50:56:25:48:c7'/&gt;
-      &lt;source bridge='VM Network'/&gt;
-    &lt;/interface&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-EOF
-
-$ virsh -c esx://example.com domxml-to-native vmware-vmx demo.xml
-Enter username for example.com [root]:
-Enter root password for example.com:
-config.version = "8"
-virtualHW.version = "4"
-guestOS = "other-64"
-uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
-displayName = "Fedora11"
-memsize = "1024"
-numvcpus = "1"
-scsi0.present = "true"
-scsi0.virtualDev = "lsilogic"
-scsi0:0.present = "true"
-scsi0:0.deviceType = "scsi-hardDisk"
-scsi0:0.fileName = "/vmfs/volumes/local-storage/Fedora11/Fedora11.vmdk"
-ethernet0.present = "true"
-ethernet0.networkName = "VM Network"
-ethernet0.connectionType = "bridged"
-ethernet0.addressType = "static"
-ethernet0.address = "00:50:56:25:48:C7"
-</pre>
-
-
-    <h2><a id="xmlconfig">Example domain XML configs</a></h2>
-
-    <h3>Fedora11 on x86_64</h3>
-<pre>
-&lt;domain type='vmware'&gt;
-  &lt;name&gt;Fedora11&lt;/name&gt;
-  &lt;uuid&gt;50115e16-9bdc-49d7-f171-53c4d7f91710&lt;/uuid&gt;
-  &lt;memory&gt;1048576&lt;/memory&gt;
-  &lt;currentMemory&gt;1048576&lt;/currentMemory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch='x86_64'&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='[local-storage] Fedora11/Fedora11.vmdk'/&gt;
-      &lt;target dev='sda' bus='scsi'/&gt;
-      &lt;address type='drive' controller='0' bus='0' unit='0'/&gt;
-    &lt;/disk&gt;
-    &lt;controller type='scsi' index='0'/&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='00:50:56:25:48:c7'/&gt;
-      &lt;source bridge='VM Network'/&gt;
-    &lt;/interface&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-
-    <h2><a id="migration">Migration</a></h2>
-    <p>
-        A migration cannot be initiated on an ESX server directly, a VMware
-        vCenter is necessary for this. The <code>vcenter</code> query
-        parameter must be set either to the hostname or IP address of the
-        vCenter managing the ESX server or to <code>*</code>. Setting it
-        to <code>*</code> causes the driver to connect to the vCenter known to
-        the ESX server. If the ESX server is not managed by a vCenter an error
-        is reported.
-    </p>
-<pre>
-esx://example.com/?vcenter=example-vcenter.com
-</pre>
-    <p>
-        Here's an example how to migrate the domain <code>Fedora11</code> from
-        ESX server <code>example-src.com</code> to ESX server
-        <code>example-dst.com</code> implicitly involving vCenter
-        <code>example-vcenter.com</code> using <code>virsh</code>.
-    </p>
-<pre>
-$ virsh -c esx://example-src.com/?vcenter=* migrate Fedora11 esx://example-dst.com/?vcenter=*
-Enter username for example-src.com [root]:
-Enter root password for example-src.com:
-Enter username for example-vcenter.com [administrator]:
-Enter administrator password for example-vcenter.com:
-Enter username for example-dst.com [root]:
-Enter root password for example-dst.com:
-Enter username for example-vcenter.com [administrator]:
-Enter administrator password for example-vcenter.com:
-</pre>
-    <p>
-        <span class="since">Since 0.8.3</span> you can directly connect to a vCenter.
-        This simplifies migration a bit. Here's the same migration as above but
-        using <code>vpx://</code> connections and assuming both ESX server are in
-        datacenter <code>dc1</code> and aren't part of a cluster.
-    </p>
-<pre>
-$ virsh -c vpx://example-vcenter.com/dc1/example-src.com migrate Fedora11 vpx://example-vcenter.com/dc1/example-dst.com
-Enter username for example-vcenter.com [administrator]:
-Enter administrator password for example-vcenter.com:
-Enter username for example-vcenter.com [administrator]:
-Enter administrator password for example-vcenter.com:
-</pre>
-
-
-    <h2><a id="scheduler">Scheduler configuration</a></h2>
-    <p>
-        The driver exposes the ESX CPU scheduler. The parameters listed below
-        are available to control the scheduler.
-    </p>
-    <dl>
-        <dt><code>reservation</code></dt>
-        <dd>
-            The amount of CPU resource in MHz that is guaranteed to be
-            available to the domain. Valid values are 0 and greater.
-        </dd>
-        <dt><code>limit</code></dt>
-        <dd>
-            The CPU utilization of the domain will be
-            limited to this value in MHz, even if more CPU resources are
-            available. If the limit is set to -1, the CPU utilization of the
-            domain is unlimited. If the limit is not set to -1, it must be
-            greater than or equal to the reservation.
-        </dd>
-        <dt><code>shares</code></dt>
-        <dd>
-            Shares are used to determine relative CPU
-            allocation between domains. In general, a domain with more shares
-            gets proportionally more of the CPU resource. Valid values are 0
-            and greater. The special values -1, -2 and -3 represent the
-            predefined shares level <code>low</code>, <code>normal</code> and
-            <code>high</code>.
-        </dd>
-    </dl>
-
-
-    <h2><a id="tools">VMware tools</a></h2>
-    <p>
-        Some actions require installed VMware tools. If the VMware tools are
-        not installed in the guest and one of the actions below is to be
-        performed the ESX server raises an error and the driver reports it.
-    </p>
-    <ul>
-        <li>
-            <code>virDomainReboot</code>
-        </li>
-        <li>
-            <code>virDomainShutdown</code>
-        </li>
-    </ul>
-
-
-    <h2><a id="links">Links</a></h2>
-    <ul>
-        <li>
-            <a href="http://www.vmware.com/support/developer/vc-sdk/">
-                VMware vSphere Web Services SDK Documentation
-            </a>
-        </li>
-        <li>
-            <a href="http://www.vmware.com/pdf/esx3_memory.pdf">
-                The Role of Memory in VMware ESX Server 3
-            </a>
-        </li>
-        <li>
-            <a href="http://www.sanbarrow.com/vmx.html">
-                VMware VMX config parameters
-            </a>
-        </li>
-        <li>
-            <a href="http://www.vmware.com/pdf/vsp_4_pvscsi_perf.pdf">
-                VMware ESX 4.0 PVSCSI Storage Performance
-            </a>
-        </li>
-    </ul>
-</body></html>

docs/drvhyperv.html.in

@@ -1,115 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Microsoft Hyper-V hypervisor driver</h1>
-    <ul id="toc"></ul>
-    <p>
-        The libvirt Microsoft Hyper-V driver can manage Hyper-V 2008 R2 and newer.
-    </p>
-
-
-    <h2><a id="project">Project Links</a></h2>
-    <ul>
-      <li>
-        The <a href="http://www.microsoft.com/hyper-v-server/">Microsoft Hyper-V</a>
-        hypervisor
-      </li>
-    </ul>
-
-
-    <h2><a id="uri">Connections to the Microsoft Hyper-V driver</a></h2>
-    <p>
-        Some example remote connection URIs for the driver are:
-    </p>
-<pre>
-hyperv://example-hyperv.com                  (over HTTPS)
-hyperv://example-hyperv.com/?transport=http  (over HTTP)
-</pre>
-    <p>
-        <strong>Note</strong>: In contrast to other drivers, the Hyper-V driver
-        is a client-side-only driver. It connects to the Hyper-V server using
-        WS-Management over HTTP(S). Therefore, the
-        <a href="remote.html">remote transport mechanism</a> provided by the
-        remote driver and libvirtd will not work, and you cannot use URIs like
-        <code>hyperv+ssh://example.com</code>.
-    </p>
-
-
-    <h3><a id="uriformat">URI Format</a></h3>
-    <p>
-        URIs have this general form (<code>[...]</code> marks an optional part).
-    </p>
-<pre>
-hyperv://[username@]hostname[:port]/[?extraparameters]
-</pre>
-    <p>
-        The default HTTPS ports is 5986. If the port parameter is given, it
-        overrides the default port.
-    </p>
-
-
-    <h4><a id="extraparams">Extra parameters</a></h4>
-    <p>
-        Extra parameters can be added to a URI as part of the query string
-        (the part following <code>?</code>). A single parameter is formed by a
-        <code>name=value</code> pair. Multiple parameters are separated by
-        <code>&amp;</code>.
-    </p>
-<pre>
-?transport=http
-</pre>
-    <p>
-        The driver understands the extra parameters shown below.
-    </p>
-    <table class="top_table">
-        <tr>
-            <th>Name</th>
-            <th>Values</th>
-            <th>Meaning</th>
-        </tr>
-        <tr>
-            <td>
-                <code>transport</code>
-            </td>
-            <td>
-                <code>http</code> or <code>https</code>
-            </td>
-            <td>
-                Overrides the default HTTPS transport. The default HTTP port
-                is 5985.
-            </td>
-        </tr>
-    </table>
-
-
-    <h3><a id="auth">Authentication</a></h3>
-    <p>
-        In order to perform any useful operation the driver needs to log into
-        the Hyper-V server. Therefore, only <code>virConnectOpenAuth</code> can
-        be used to connect to an Hyper-V server, <code>virConnectOpen</code> and
-        <code>virConnectOpenReadOnly</code> don't work.
-        To log into an Hyper-V server the driver will request credentials using
-        the callback passed to the <code>virConnectOpenAuth</code> function.
-        The driver passes the hostname as challenge parameter to the callback.
-    </p>
-    <p>
-        <strong>Note</strong>: Currently only <code>Basic</code> authentication
-        is supported by libvirt. This method is disabled by default on the
-        Hyper-V server and can be enabled via the WinRM commandline tool.
-    </p>
-<pre>
-winrm set winrm/config/service/auth @{Basic="true"}
-</pre>
-    <p>
-        To allow <code>Basic</code> authentication with HTTP transport WinRM
-        needs to allow unencrypted communication. This can be enabled via the
-        WinRM commandline tool. However, this is not the recommended
-        communication mode.
-    </p>
-<pre>
-winrm set winrm/config/service @{AllowUnencrypted="true"}
-</pre>
-
-
-</body></html>

docs/drvlxc.html.in

@@ -1,812 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>LXC container driver</h1>
-
-    <ul id="toc"></ul>
-
-<p>
-The libvirt LXC driver manages "Linux Containers". At their simplest, containers
-can just be thought of as a collection of processes, separated from the main
-host processes via a set of resource namespaces and constrained via control
-groups resource tunables. The libvirt LXC driver has no dependency on the LXC
-userspace tools hosted on sourceforge.net. It directly utilizes the relevant
-kernel features to build the container environment. This allows for sharing
-of many libvirt technologies across both the QEMU/KVM and LXC drivers. In
-particular sVirt for mandatory access control, auditing of operations,
-integration with control groups and many other features.
-</p>
-
-<h2><a id="cgroups">Control groups Requirements</a></h2>
-
-<p>
-In order to control the resource usage of processes inside containers, the
-libvirt LXC driver requires that certain cgroups controllers are mounted on
-the host OS. The minimum required controllers are 'cpuacct', 'memory' and
-'devices', while recommended extra controllers are 'cpu', 'freezer' and
-'blkio'. Libvirt will not mount the cgroups filesystem itself, leaving
-this up to the init system to take care of. Systemd will do the right thing
-in this respect, while for other init systems the <code>cgconfig</code>
-init service will be required. For further information, consult the general
-libvirt <a href="cgroups.html">cgroups documentation</a>.
-</p>
-
-<h2><a id="namespaces">Namespace requirements</a></h2>
-
-<p>
-In order to separate processes inside a container from those in the
-primary "host" OS environment, the libvirt LXC driver requires that
-certain kernel namespaces are compiled in. Libvirt currently requires
-the 'mount', 'ipc', 'pid', and 'uts' namespaces to be available. If
-separate network interfaces are desired, then the 'net' namespace is
-required. If the guest configuration declares a
-<a href="formatdomain.html#elementsOSContainer">UID or GID mapping</a>,
-the 'user' namespace will be enabled to apply these. <strong>A suitably
-configured UID/GID mapping is a pre-requisite to making containers
-secure, in the absence of sVirt confinement.</strong>
-</p>
-
-<h2><a id="init">Default container setup</a></h2>
-
-<h3><a id="cliargs">Command line arguments</a></h3>
-
-<p>
-When the container "init" process is started, it will typically
-not be given any command line arguments (eg the equivalent of
-the bootloader args visible in <code>/proc/cmdline</code>). If
-any arguments are desired, then must be explicitly set in the
-container XML configuration via one or more <code>initarg</code>
-elements. For example, to run <code>systemd --unit emergency.service</code>
-would use the following XML
-</p>
-
-<pre>
-&lt;os&gt;
-  &lt;type arch='x86_64'&gt;exe&lt;/type&gt;
-  &lt;init&gt;/bin/systemd&lt;/init&gt;
-  &lt;initarg&gt;--unit&lt;/initarg&gt;
-  &lt;initarg&gt;emergency.service&lt;/initarg&gt;
-&lt;/os&gt;
-</pre>
-
-<h3><a id="envvars">Environment variables</a></h3>
-
-<p>
-When the container "init" process is started, it will be given several useful
-environment variables. The following standard environment variables are mandated
-by <a href="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">systemd container interface</a>
-to be provided by all container technologies on Linux.
-</p>
-
-<dl>
-<dt><code>container</code></dt>
-<dd>The fixed string <code>libvirt-lxc</code> to identify libvirt as the creator</dd>
-<dt><code>container_uuid</code></dt>
-<dd>The UUID assigned to the container by libvirt</dd>
-<dt><code>PATH</code></dt>
-<dd>The fixed string <code>/bin:/usr/bin</code></dd>
-<dt><code>TERM</code></dt>
-<dd>The fixed string <code>linux</code></dd>
-<dt><code>HOME</code></dt>
-<dd>The fixed string <code>/</code></dd>
-</dl>
-
-<p>
-In addition to the standard variables, the following libvirt specific
-environment variables are also provided
-</p>
-
-<dl>
-<dt><code>LIBVIRT_LXC_NAME</code></dt>
-<dd>The name assigned to the container by libvirt</dd>
-<dt><code>LIBVIRT_LXC_UUID</code></dt>
-<dd>The UUID assigned to the container by libvirt</dd>
-<dt><code>LIBVIRT_LXC_CMDLINE</code></dt>
-<dd>The unparsed command line arguments specified in the container configuration.
-Use of this is discouraged, in favour of passing arguments directly to the
-container init process via the <code>initarg</code> config element.</dd>
-</dl>
-
-<h3><a id="fsmounts">Filesystem mounts</a></h3>
-
-<p>
-In the absence of any explicit configuration, the container will
-inherit the host OS filesystem mounts. A number of mount points will
-be made read only, or re-mounted with new instances to provide
-container specific data. The following special mounts are setup
-by libvirt
-</p>
-
-<ul>
-<li><code>/dev</code> a new "tmpfs" pre-populated with authorized device nodes</li>
-<li><code>/dev/pts</code> a new private "devpts" instance for console devices</li>
-<li><code>/sys</code> the host "sysfs" instance remounted read-only</li>
-<li><code>/proc</code> a new instance of the "proc" filesystem</li>
-<li><code>/proc/sys</code> the host "/proc/sys" bind-mounted read-only</li>
-<li><code>/sys/fs/selinux</code> the host "selinux" instance remounted read-only</li>
-<li><code>/sys/fs/cgroup/NNNN</code> the host cgroups controllers bind-mounted to
-only expose the sub-tree associated with the container</li>
-<li><code>/proc/meminfo</code> a FUSE backed file reflecting memory limits of the container</li>
-</ul>
-
-
-<h3><a id="devnodes">Device nodes</a></h3>
-
-<p>
-The container init process will be started with <code>CAP_MKNOD</code>
-capability removed and blocked from re-acquiring it. As such it will
-not be able to create any device nodes in <code>/dev</code> or anywhere
-else in its filesystems. Libvirt itself will take care of pre-populating
-the <code>/dev</code> filesystem with any devices that the container
-is authorized to use. The current devices that will be made available
-to all containers are
-</p>
-
-<ul>
-<li><code>/dev/zero</code></li>
-<li><code>/dev/null</code></li>
-<li><code>/dev/full</code></li>
-<li><code>/dev/random</code></li>
-<li><code>/dev/urandom</code></li>
-<li><code>/dev/stdin</code> symlinked to <code>/proc/self/fd/0</code></li>
-<li><code>/dev/stdout</code> symlinked to <code>/proc/self/fd/1</code></li>
-<li><code>/dev/stderr</code> symlinked to <code>/proc/self/fd/2</code></li>
-<li><code>/dev/fd</code> symlinked to <code>/proc/self/fd</code></li>
-<li><code>/dev/ptmx</code> symlinked to <code>/dev/pts/ptmx</code></li>
-<li><code>/dev/console</code> symlinked to <code>/dev/pts/0</code></li>
-</ul>
-
-<p>
-In addition, for every console defined in the guest configuration,
-a symlink will be created from <code>/dev/ttyN</code> symlinked to
-the corresponding <code>/dev/pts/M</code> pseudo TTY device. The
-first console will be <code>/dev/tty1</code>, with further consoles
-numbered incrementally from there.
-</p>
-
-<p>
-Since /dev/ttyN and /dev/console are linked to the pts devices. The
-tty device of login program is pts device. The pam module securetty
-may prevent root user from logging in container. If you want root
-user to log in container successfully, add the pts device to the file
-/etc/securetty of container.
-</p>
-
-<p>
-Further block or character devices will be made available to containers
-depending on their configuration.
-</p>
-
-<h2><a id="security">Security considerations</a></h2>
-
-<p>
-The libvirt LXC driver is fairly flexible in how it can be configured,
-and as such does not enforce a requirement for strict security
-separation between a container and the host. This allows it to be used
-in scenarios where only resource control capabilities are important,
-and resource sharing is desired. Applications wishing to ensure secure
-isolation between a container and the host must ensure that they are
-writing a suitable configuration.
-</p>
-
-<h3><a id="securenetworking">Network isolation</a></h3>
-
-<p>
-If the guest configuration does not list any network interfaces,
-the <code>network</code> namespace will not be activated, and thus
-the container will see all the host's network interfaces. This will
-allow apps in the container to bind to/connect from TCP/UDP addresses
-and ports from the host OS. It also allows applications to access
-UNIX domain sockets associated with the host OS, which are in the
-abstract namespace. If access to UNIX domains sockets in the abstract
-namespace is not wanted, then applications should set the
-<code>&lt;privnet/&gt;</code> flag in the
-<code>&lt;features&gt;....&lt;/features&gt;</code> element.
-</p>
-
-<h3><a id="securefs">Filesystem isolation</a></h3>
-
-<p>
-If the guest configuration does not list any filesystems, then
-the container will be set up with a root filesystem that matches
-the host's root filesystem. As noted earlier, only a few locations
-such as <code>/dev</code>, <code>/proc</code> and <code>/sys</code>
-will be altered. This means that, in the absence of restrictions
-from sVirt, a process running as user/group N:M inside the container
-will be able to access almost exactly the same files as a process
-running as user/group N:M in the host.
-</p>
-
-<p>
-There are multiple options for restricting this. It is possible to
-simply map the existing root filesystem through to the container in
-read-only mode. Alternatively a completely separate root filesystem
-can be configured for the guest. In both cases, further sub-mounts
-can be applied to customize the content that is made visible. Note
-that in the absence of sVirt controls, it is still possible for the
-root user in a container to unmount any sub-mounts applied. The user
-namespace feature can also be used to restrict access to files based
-on the UID/GID mappings.
-</p>
-
-<p>
-Sharing the host filesystem tree, also allows applications to access
-UNIX domains sockets associated with the host OS, which are in the
-filesystem namespaces. It should be noted that a number of init
-systems including at least <code>systemd</code> and <code>upstart</code>
-have UNIX domain socket which are used to control their operation.
-Thus, if the directory/filesystem holding their UNIX domain socket is
-exposed to the container, it will be possible for a user in the container
-to invoke operations on the init service in the same way it could if
-outside the container. This also applies to other applications in the
-host which use UNIX domain sockets in the filesystem, such as DBus,
-Libvirtd, and many more. If this is not desired, then applications
-should either specify the UID/GID mapping in the configuration to
-enable user namespaces and thus block access to the UNIX domain socket
-based on permissions, or should ensure the relevant directories have
-a bind mount to hide them. This is particularly important for the
-<code>/run</code> or <code>/var/run</code> directories.
-</p>
-
-
-<h3><a id="secureusers">User and group isolation</a></h3>
-
-<p>
-If the guest configuration does not list any ID mapping, then the
-user and group IDs used inside the container will match those used
-outside the container. In addition, the capabilities associated with
-a process in the container will infer the same privileges they would
-for a process in the host. This has obvious implications for security,
-since a root user inside the container will be able to access any
-file owned by root that is visible to the container, and perform more
-or less any privileged kernel operation. In the absence of additional
-protection from sVirt, this means that the root user inside a container
-is effectively as powerful as the root user in the host. There is no
-security isolation of the root user.
-</p>
-
-<p>
-The ID mapping facility was introduced to allow for stricter control
-over the privileges of users inside the container. It allows apps to
-define rules such as "user ID 0 in the container maps to user ID 1000
-in the host". In addition the privileges associated with capabilities
-are somewhat reduced so that they cannot be used to escape from the
-container environment. A full description of user namespaces is outside
-the scope of this document, however LWN has
-<a href="https://lwn.net/Articles/532593/">a good write-up on the topic</a>.
-From the libvirt point of view, the key thing to remember is that defining
-an ID mapping for users and groups in the container XML configuration
-causes libvirt to activate the user namespace feature.
-</p>
-
-
-<h2><a id="activation">Systemd Socket Activation Integration</a></h2>
-
-<p>
-The libvirt LXC driver provides the ability to pass across pre-opened file
-descriptors when starting LXC guests. This allows for libvirt LXC to support
-systemd's <a href="http://0pointer.de/blog/projects/socket-activated-containers.html">socket
-activation capability</a>, where an incoming client connection
-in the host OS will trigger the startup of a container, which runs another
-copy of systemd which gets passed the server socket, and then activates the
-actual service handler in the container.
-</p>
-
-<p>
-Let us assume that you already have a LXC guest created, running
-a systemd instance as PID 1 inside the container, which has an
-SSHD service configured. The goal is to automatically activate
-the container when the first SSH connection is made. The first
-step is to create a couple of unit files for the host OS systemd
-instance. The <code>/etc/systemd/system/mycontainer.service</code>
-unit file specifies how systemd will start the libvirt LXC container
-</p>
-
-<pre>
-[Unit]
-Description=My little container
-
-[Service]
-ExecStart=/usr/bin/virsh -c lxc:///system start --pass-fds 3 mycontainer
-ExecStop=/usr/bin/virsh -c lxc:///system destroy mycontainer
-Type=oneshot
-RemainAfterExit=yes
-KillMode=none
-</pre>
-
-<p>
-The <code>--pass-fds 3</code> argument specifies that the file
-descriptor number 3 that <code>virsh</code> inherits from systemd,
-is to be passed into the container. Since <code>virsh</code> will
-exit immediately after starting the container, the <code>RemainAfterExit</code>
-and <code>KillMode</code> settings must be altered from their defaults.
-</p>
-
-<p>
-Next, the <code>/etc/systemd/system/mycontainer.socket</code> unit
-file is created to get the host systemd to listen on port 23 for
-TCP connections. When this unit file is activated by the first
-incoming connection, it will cause the <code>mycontainer.service</code>
-unit to be activated with the FD corresponding to the listening TCP
-socket passed in as FD 3.
-</p>
-
-<pre>
-[Unit]
-Description=The SSH socket of my little container
-
-[Socket]
-ListenStream=23
-</pre>
-
-<p>
-Port 23 was picked here so that the container doesn't conflict
-with the host's SSH which is on the normal port 22. That's it
-in terms of host side configuration.
-</p>
-
-<p>
-Inside the container, the <code>/etc/systemd/system/sshd.socket</code>
-unit file must be created
-</p>
-
-<pre>
-[Unit]
-Description=SSH Socket for Per-Connection Servers
-
-[Socket]
-ListenStream=23
-Accept=yes
-</pre>
-
-<p>
-The <code>ListenStream</code> value listed in this unit file, must
-match the value used in the host file. When systemd in the container
-receives the pre-opened FD from libvirt during container startup, it
-looks at the <code>ListenStream</code> values to figure out which
-FD to give to which service. The actual service to start is defined
-by a correspondingly named <code>/etc/systemd/system/sshd@.service</code>
-</p>
-
-<pre>
-[Unit]
-Description=SSH Per-Connection Server for %I
-
-[Service]
-ExecStart=-/usr/sbin/sshd -i
-StandardInput=socket
-</pre>
-
-<p>
-Finally, make sure this SSH service is set to start on boot of the container,
-by running the following command inside the container:
-</p>
-
-<pre>
-# mkdir -p /etc/systemd/system/sockets.target.wants/
-# ln -s /etc/systemd/system/sshd.socket /etc/systemd/system/sockets.target.wants/
-</pre>
-
-<p>
-This example shows how to activate the container based on an incoming
-SSH connection. If the container was also configured to have an httpd
-service, it may be desirable to activate it upon either an httpd or a
-sshd connection attempt. In this case, the <code>mycontainer.socket</code>
-file in the host would simply list multiple socket ports. Inside the
-container a separate <code>xxxxx.socket</code> file would need to be
-created for each service, with a corresponding <code>ListenStream</code>
-value set.
-</p>
-
-<!--
-<h2>Container configuration</h2>
-
-<h3>Init process</h3>
-
-<h3>Console devices</h3>
-
-<h3>Filesystem devices</h3>
-
-<h3>Disk devices</h3>
-
-<h3>Block devices</h3>
-
-<h3>USB devices</h3>
-
-<h3>Character devices</h3>
-
-<h3>Network devices</h3>
--->
-
-<h2>Container security</h2>
-
-<h3>sVirt SELinux</h3>
-
-<p>
-In the absence of the "user" namespace being used, containers cannot
-be considered secure against exploits of the host OS. The sVirt SELinux
-driver provides a way to secure containers even when the "user" namespace
-is not used. The cost is that writing a policy to allow execution of
-arbitrary OS is not practical. The SELinux sVirt policy is typically
-tailored to work with a simpler application confinement use case,
-as provided by the "libvirt-sandbox" project.
-</p>
-
-<h3>Auditing</h3>
-
-<p>
-The LXC driver is integrated with libvirt's auditing subsystem, which
-causes audit messages to be logged whenever there is an operation
-performed against a container which has impact on host resources.
-So for example, start/stop, device hotplug will all log audit messages
-providing details about what action occurred and any resources
-associated with it. There are the following 3 types of audit messages
-</p>
-
-<ul>
-<li><code>VIRT_MACHINE_ID</code> - details of the SELinux process and
-image security labels assigned to the container.</li>
-<li><code>VIRT_CONTROL</code> - details of an action / operation
-performed against a container. There are the following types of
-operation
-  <ul>
-    <li><code>op=start</code> - a container has been started. Provides
-      the machine name, uuid and PID of the <code>libvirt_lxc</code>
-      controller process</li>
-    <li><code>op=init</code> - the init PID of the container has been
-      started. Provides the machine name, uuid and PID of the
-      <code>libvirt_lxc</code> controller process and PID of the
-      init process (in the host PID namespace)</li>
-    <li><code>op=stop</code> - a container has been stopped. Provides
-      the machine name, uuid</li>
-  </ul>
-</li>
-<li><code>VIRT_RESOURCE</code> - details of a host resource
-associated with a container action.</li>
-</ul>
-
-<h3>Device access</h3>
-
-<p>
-All containers are launched with the CAP_MKNOD capability cleared
-and removed from the bounding set. Libvirt will ensure that the
-/dev filesystem is pre-populated with all devices that a container
-is allowed to use. In addition, the cgroup "device" controller is
-configured to block read/write/mknod from all devices except those
-that a container is authorized to use.
-</p>
-
-<h2><a id="exconfig">Example configurations</a></h2>
-
-<h3>Example config version 1</h3>
-<p></p>
-<pre>
-&lt;domain type='lxc'&gt;
-  &lt;name&gt;vm1&lt;/name&gt;
-  &lt;memory&gt;500000&lt;/memory&gt;
-  &lt;os&gt;
-    &lt;type&gt;exe&lt;/type&gt;
-    &lt;init&gt;/bin/sh&lt;/init&gt;
-  &lt;/os&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;clock offset='utc'/&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/libexec/libvirt_lxc&lt;/emulator&gt;
-    &lt;interface type='network'&gt;
-      &lt;source network='default'/&gt;
-    &lt;/interface&gt;
-    &lt;console type='pty' /&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-<p>
-In the &lt;emulator&gt; element, be sure you specify the correct path
-to libvirt_lxc, if it does not live in /usr/libexec on your system.
-</p>
-
-<p>
-The next example assumes there is a private root filesystem
-(perhaps hand-crafted using busybox, or installed from media,
-debootstrap, whatever) under /opt/vm-1-root:
-</p>
-<p></p>
-<pre>
-&lt;domain type='lxc'&gt;
-  &lt;name&gt;vm1&lt;/name&gt;
-  &lt;memory&gt;32768&lt;/memory&gt;
-  &lt;os&gt;
-    &lt;type&gt;exe&lt;/type&gt;
-    &lt;init&gt;/init&lt;/init&gt;
-  &lt;/os&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;clock offset='utc'/&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/libexec/libvirt_lxc&lt;/emulator&gt;
-    &lt;filesystem type='mount'&gt;
-      &lt;source dir='/opt/vm-1-root'/&gt;
-      &lt;target dir='/'/&gt;
-    &lt;/filesystem&gt;
-    &lt;interface type='network'&gt;
-      &lt;source network='default'/&gt;
-    &lt;/interface&gt;
-    &lt;console type='pty' /&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-<h2><a id="capabilities">Altering the available capabilities</a></h2>
-
-<p>
-By default the libvirt LXC driver drops some capabilities among which CAP_MKNOD.
-However <span class="since">since 1.2.6</span> libvirt can be told to keep or
-drop some capabilities using a domain configuration like the following:
-</p>
-<pre>
-...
-&lt;features&gt;
-  &lt;capabilities policy='default'&gt;
-    &lt;mknod state='on'/&gt;
-    &lt;sys_chroot state='off'/&gt;
-  &lt;/capabilities&gt;
-&lt;/features&gt;
-...
-</pre>
-<p>
-The capabilities children elements are named after the capabilities as defined in
-<code>man 7 capabilities</code>. An <code>off</code> state tells libvirt to drop the
-capability, while an <code>on</code> state will force to keep the capability even though
-this one is dropped by default.
-</p>
-<p>
-The <code>policy</code> attribute can be one of <code>default</code>, <code>allow</code>
-or <code>deny</code>. It defines the default rules for capabilities: either keep the
-default behavior that is dropping a few selected capabilities, or keep all capabilities
-or drop all capabilities. The interest of <code>allow</code> and <code>deny</code> is that
-they guarantee that all capabilities will be kept (or removed) even if new ones are added
-later.
-</p>
-<p>
-The following example, drops all capabilities but CAP_MKNOD:
-</p>
-<pre>
-...
-&lt;features&gt;
-  &lt;capabilities policy='deny'&gt;
-    &lt;mknod state='on'/&gt;
-  &lt;/capabilities&gt;
-&lt;/features&gt;
-...
-</pre>
-<p>
-Note that allowing capabilities that are normally dropped by default can seriously
-affect the security of the container and the host.
-</p>
-
-<h2><a id="share">Inherit namespaces</a></h2>
-
-<p>
-Libvirt allows you to inherit the namespace from container/process just like lxc tools
-or docker provides to share the network namespace. The following can be used to share
-required namespaces. If we want to share only one then the other namespaces can be ignored.
-The netns option is specific to sharenet. It can be used in cases we want to use existing network namespace
-rather than creating new network namespace for the container. In this case privnet option will be
-ignored.
-</p>
-<pre>
-&lt;domain type='lxc' xmlns:lxc='http://libvirt.org/schemas/domain/lxc/1.0'&gt;
-...
-&lt;lxc:namespace&gt;
-  &lt;lxc:sharenet type='netns' value='red'/&gt;
-  &lt;lxc:shareuts type='name' value='container1'/&gt;
-  &lt;lxc:shareipc type='pid' value='12345'/&gt;
-&lt;/lxc:namespace&gt;
-&lt;/domain&gt;
-</pre>
-
-<p>
-The use of namespace passthrough requires libvirt >= 1.2.19
-</p>
-
-<h2><a id="usage">Container usage / management</a></h2>
-
-<p>
-As with any libvirt virtualization driver, LXC containers can be
-managed via a wide variety of libvirt based tools. At the lowest
-level the <code>virsh</code> command can be used to perform many
-tasks, by passing the <code>-c lxc:///system</code> argument. As an
-alternative to repeating the URI with every command, the <code>LIBVIRT_DEFAULT_URI</code>
-environment variable can be set to <code>lxc:///system</code>. The
-examples that follow outline some common operations with virsh
-and LXC. For further details about usage of virsh consult its
-manual page.
-</p>
-
-<h3><a id="usageSave">Defining (saving) container configuration</a></h3>
-
-<p>
-The <code>virsh define</code> command takes an XML configuration
-document and loads it into libvirt, saving the configuration on disk
-</p>
-
-<pre>
-# virsh -c lxc:///system define myguest.xml
-</pre>
-
-<h3><a id="usageView">Viewing container configuration</a></h3>
-
-<p>
-The <code>virsh dumpxml</code> command can be used to view the
-current XML configuration of a container. By default the XML
-output reflects the current state of the container. If the
-container is running, it is possible to explicitly request the
-persistent configuration, instead of the current live configuration
-using the <code>--inactive</code> flag
-</p>
-
-<pre>
-# virsh -c lxc:///system dumpxml myguest
-</pre>
-
-<h3><a id="usageStart">Starting containers</a></h3>
-
-<p>
-The <code>virsh start</code> command can be used to start a
-container from a previously defined persistent configuration
-</p>
-
-<pre>
-# virsh -c lxc:///system start myguest
-</pre>
-
-<p>
-It is also possible to start so called "transient" containers,
-which do not require a persistent configuration to be saved
-by libvirt, using the <code>virsh create</code> command.
-</p>
-
-<pre>
-# virsh -c lxc:///system create myguest.xml
-</pre>
-
-
-<h3><a id="usageStop">Stopping containers</a></h3>
-
-<p>
-The <code>virsh shutdown</code> command can be used
-to request a graceful shutdown of the container. By default
-this command will first attempt to send a message to the
-init process via the <code>/dev/initctl</code> device node.
-If no such device node exists, then it will send SIGTERM
-to PID 1 inside the container.
-</p>
-
-<pre>
-# virsh -c lxc:///system shutdown myguest
-</pre>
-
-<p>
-If the container does not respond to the graceful shutdown
-request, it can be forcibly stopped using the <code>virsh destroy</code>
-</p>
-
-<pre>
-# virsh -c lxc:///system destroy myguest
-</pre>
-
-
-<h3><a id="usageReboot">Rebooting a container</a></h3>
-
-<p>
-The <code>virsh reboot</code> command can be used
-to request a graceful shutdown of the container. By default
-this command will first attempt to send a message to the
-init process via the <code>/dev/initctl</code> device node.
-If no such device node exists, then it will send SIGHUP
-to PID 1 inside the container.
-</p>
-
-<pre>
-# virsh -c lxc:///system reboot myguest
-</pre>
-
-<h3><a id="usageDelete">Undefining (deleting) a container configuration</a></h3>
-
-<p>
-The <code>virsh undefine</code> command can be used to delete the
-persistent configuration of a container. If the guest is currently
-running, this will turn it into a "transient" guest.
-</p>
-
-<pre>
-# virsh -c lxc:///system undefine myguest
-</pre>
-
-<h3><a id="usageConnect">Connecting to a container console</a></h3>
-
-<p>
-The <code>virsh console</code> command can be used to connect
-to the text console associated with a container.
-</p>
-
-<pre>
-# virsh -c lxc:///system console myguest
-</pre>
-
-<p>
-If the container has been configured with multiple console devices,
-then the <code>--devname</code> argument can be used to choose the
-console to connect to.
-In LXC, multiple consoles will be named
-as 'console0', 'console1', 'console2', etc.
-</p>
-
-<pre>
-# virsh -c lxc:///system console myguest --devname console1
-</pre>
-
-<h3><a id="usageEnter">Running commands in a container</a></h3>
-
-<p>
-The <code>virsh lxc-enter-namespace</code> command can be used
-to enter the namespaces and security context of a container
-and then execute an arbitrary command.
-</p>
-
-<pre>
-# virsh -c lxc:///system lxc-enter-namespace myguest -- /bin/ls -al /dev
-</pre>
-
-<h3><a id="usageTop">Monitoring container utilization</a></h3>
-
-<p>
-The <code>virt-top</code> command can be used to monitor the
-activity and resource utilization of all containers on a
-host
-</p>
-
-<pre>
-# virt-top -c lxc:///system
-</pre>
-
-<h3><a id="usageConvert">Converting LXC container configuration</a></h3>
-
-<p>
-The <code>virsh domxml-from-native</code> command can be used to convert
-most of the LXC container configuration into a domain XML fragment
-</p>
-
-<pre>
-# virsh -c lxc:///system domxml-from-native lxc-tools /var/lib/lxc/myguest/config
-</pre>
-
-<p>
-This conversion has some limitations due to the fact that the
-domxml-from-native command output has to be independent of the host. Here
-are a few things to take care of before converting:
-</p>
-
-<ul>
-<li>
-Replace the fstab file referenced by <tt>lxc.mount</tt> by the corresponding
-lxc.mount.entry lines.
-</li>
-<li>
-Replace all relative sizes of tmpfs mount entries to absolute sizes. Also
-make sure that tmpfs entries all have a size option (default is 50%).
-</li>
-<li>
-Define <tt>lxc.cgroup.memory.limit_in_bytes</tt> to properly limit the memory
-available to the container. The conversion will use 64MiB as the default.
-</li>
-</ul>
-
-  </body>
-</html>

docs/drvnodedev.html.in

@@ -1,374 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Host device management</h1>
-
-    <p>
-      Libvirt provides management of both physical and virtual host devices
-      (historically also referred to as node devices) like USB, PCI, SCSI, and
-      network devices. This also includes various virtualization capabilities
-      which the aforementioned devices provide for utilization, for example
-      SR-IOV, NPIV, MDEV, DRM, etc.
-    </p>
-
-    <p>
-      The node device driver provides means to list and show details about host
-      devices (<code>virsh nodedev-list</code>,
-      <code>virsh nodedev-dumpxml</code>), which are generic and can be used
-      with all devices. It also provides means to create and destroy devices
-      (<code>virsh nodedev-create</code>, <code>virsh nodedev-destroy</code>)
-      which are meant to be used to create virtual devices, currently only
-      supported by NPIV
-      (<a href="http://wiki.libvirt.org/page/NPIV_in_libvirt">more info about NPIV)</a>).
-      Devices on the host system are arranged in a tree-like hierarchy, with
-      the root node being called <code>computer</code>. The node device driver
-      supports two backends to manage the devices, HAL and udev, with the former
-      being deprecated in favour of the latter.
-    </p>
-
-    <p>
-      The generic format of a host device XML can be seen below.
-      To identify a device both within the host and the device tree hierarchy,
-      the following elements are used:
-    </p>
-      <dl>
-        <dt><code>name</code></dt>
-        <dd>
-          The device's name will be generated by libvirt using the subsystem,
-          like pci and the device's sysfs basename.
-        </dd>
-        <dt><code>path</code></dt>
-        <dd>
-          Fully qualified sysfs path to the device.
-        </dd>
-        <dt><code>parent</code></dt>
-        <dd>
-          This element identifies the parent node in the device hierarchy. The
-          value of the element will correspond with the device parent's
-          <code>name</code> element or <code>computer</code> if the device does
-          not have any parent.
-        </dd>
-        <dt><code>driver</code></dt>
-        <dd>
-          This elements reports the driver in use for this device. The presence
-          of this element in the output XML depends on whether the underlying
-          device manager (most likely udev) exposes information about the
-          driver.
-        </dd>
-        <dt><code>capability</code></dt>
-        <dd>
-          Describes the device in terms of feature support. The element has one
-          mandatory attribute <code>type</code> the value of which determines
-          the type of the device. Currently recognized values for the attribute
-          are:
-          <code>system</code>,
-          <code>pci</code>,
-          <code>usb</code>,
-          <code>usb_device</code>,
-          <code>net</code>,
-          <code>scsi</code>,
-          <code>scsi_host</code> (<span class="since">Since 0.4.7</span>),
-          <code>fc_host</code>,
-          <code>vports</code>,
-          <code>scsi_target</code> (<span class="since">Since 0.7.3</span>),
-          <code>storage</code> (<span class="since">Since 1.0.4</span>),
-          <code>scsi_generic</code> (<span class="since">Since 1.0.7</span>),
-          <code>drm</code> (<span class="since">Since 3.1.0</span>), and
-          <code>mdev</code> (<span class="since">Since 3.4.0</span>).
-          This element can be nested in which case it further specifies a
-          device's capability. Refer to specific device types to see more values
-          for the <code>type</code> attribute which are exclusive.
-        </dd>
-      </dl>
-
-    <h2>Basic structure of a node device</h2>
-    <pre>
-&lt;device&gt;
-  &lt;name&gt;pci_0000_00_17_0&lt;/name&gt;
-  &lt;path&gt;/sys/devices/pci0000:00/0000:00:17.0&lt;/path&gt;
-  &lt;parent&gt;computer&lt;/parent&gt;
-  &lt;driver&gt;
-    &lt;name&gt;ahci&lt;/name&gt;
-  &lt;/driver&gt;
-  &lt;capability type='pci'&gt;
-...
-  &lt;/capability&gt;
-&lt;/device&gt;</pre>
-
-    <ul id="toc"/>
-
-    <h2><a id="PCI">PCI host devices</a></h2>
-    <dl>
-      <dt><code>capability</code></dt>
-      <dd>
-        When used as top level element, the supported values for the
-        <code>type</code> attribute are <code>pci</code> and
-        <code>phys_function</code> (see <a href="#SRIOVCap">SR-IOV below</a>).
-      </dd>
-    </dl>
-    <pre>
-&lt;device&gt;
-  &lt;name&gt;pci_0000_04_00_1&lt;/name&gt;
-  &lt;path&gt;/sys/devices/pci0000:00/0000:00:06.0/0000:04:00.1&lt;/path&gt;
-  &lt;parent&gt;pci_0000_00_06_0&lt;/parent&gt;
-  &lt;driver&gt;
-    &lt;name&gt;igb&lt;/name&gt;
-  &lt;/driver&gt;
-  &lt;capability type='pci'&gt;
-    &lt;domain&gt;0&lt;/domain&gt;
-    &lt;bus&gt;4&lt;/bus&gt;
-    &lt;slot&gt;0&lt;/slot&gt;
-    &lt;function&gt;1&lt;/function&gt;
-    &lt;product id='0x10c9'&gt;82576 Gigabit Network Connection&lt;/product&gt;
-    &lt;vendor id='0x8086'&gt;Intel Corporation&lt;/vendor&gt;
-    &lt;iommuGroup number='15'&gt;
-      &lt;address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/&gt;
-    &lt;/iommuGroup&gt;
-    &lt;numa node='0'/&gt;
-    &lt;pci-express&gt;
-      &lt;link validity='cap' port='1' speed='2.5' width='2'/&gt;
-      &lt;link validity='sta' speed='2.5' width='2'/&gt;
-    &lt;/pci-express&gt;
-  &lt;/capability&gt;
-&lt;/device&gt;</pre>
-
-    <p>
-      The XML format for a PCI device stays the same for any further
-      capabilities it supports, a single nested <code>&lt;capability&gt;</code>
-      element will be included for each capability the device supports.
-    </p>
-
-    <h3><a id="SRIOVCap">SR-IOV capability</a></h3>
-    <p>
-      Single root input/output virtualization (SR-IOV) allows sharing of the
-      PCIe resources by multiple virtual environments. That is achieved by
-      slicing up a single full-featured physical resource called physical
-      function (PF) into multiple devices called virtual functions (VFs) sharing
-      their configuration with the underlying PF. Despite the SR-IOV
-      specification, the amount of VFs that can be created on a PF varies among
-      manufacturers.
-    </p>
-
-    <p>
-      Suppose the NIC <a href="#PCI">above</a> was also SR-IOV capable, it would
-      also include a nested
-      <code>&lt;capability&gt;</code> element enumerating all virtual
-      functions available on the physical device (physical port) like in the
-      example below.
-    </p>
-
-    <pre>
-&lt;capability type='pci'&gt;
-...
-  &lt;capability type='virt_functions' maxCount='7'&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x10' function='0x1'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x10' function='0x3'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x10' function='0x5'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x10' function='0x7'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x11' function='0x1'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x11' function='0x3'/&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x11' function='0x5'/&gt;
-  &lt;/capability&gt;
-...
-&lt;/capability&gt;</pre>
-    <p>
-      A SR-IOV child device on the other hand, would then report its top level
-      capability type as a <code>phys_function</code> instead:
-    </p>
-
-    <pre>
-&lt;device&gt;
-...
-  &lt;capability type='phys_function'&gt;
-    &lt;address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/&gt;
-  &lt;/capability&gt;
-...
-&lt;device&gt;</pre>
-
-    <h3><a id="MDEVCap">MDEV capability</a></h3>
-    <p>
-      A PCI device capable of creating mediated devices will include a nested
-      capability <code>mdev_types</code> which enumerates all supported mdev
-      types on the physical device, along with the type attributes available
-      through sysfs:
-    </p>
-
-    <dl>
-      <dt><code>type</code></dt>
-      <dd>
-        This element describes a mediated device type which acts as an
-        abstract template defining a resource allocation for instances of this
-        device type. The element has one attribute <code>id</code> which holds
-        an official vendor-supplied identifier for the type.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-
-      <dt><code>name</code></dt>
-      <dd>
-        The <code>name</code> element holds a vendor-supplied code name for
-        the given mediated device type. This is an optional element.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-
-      <dt><code>deviceAPI</code></dt>
-      <dd>
-        The value of this element describes how an instance of the given type
-        will be presented to the guest by the VFIO framework.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-
-      <dt><code>availableInstances</code></dt>
-      <dd>
-        This element reports the current state of resource allocation. In other
-        words, how many instances of the given type can still be successfully
-        created on the physical device.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-    </dl>
-
-    <p>
-      For a more info about mediated devices, refer to the
-      <a href="#MDEV">paragraph below</a>.
-    </p>
-
-<pre>
-&lt;device&gt;
-...
-  &lt;driver&gt;
-    &lt;name&gt;nvidia&lt;/name&gt;
-  &lt;/driver&gt;
-  &lt;capability type='pci'&gt;
-...
-    &lt;capability type='mdev_types'&gt;
-      &lt;type id='nvidia-11'&gt;
-        &lt;name&gt;GRID M60-0B&lt;/name&gt;
-        &lt;deviceAPI&gt;vfio-pci&lt;/deviceAPI&gt;
-        &lt;availableInstances&gt;16&lt;/availableInstances&gt;
-      &lt;/type&gt;
-      &lt;!-- Here would come the rest of the available mdev types --&gt;
-    &lt;/capability&gt;
-...
-  &lt;/capability&gt;
-&lt;/device&gt;</pre>
-
-    <h2><a id="MDEV">Mediated devices (MDEVs)</a></h2>
-    <p>
-      Mediated devices (<span class="since">Since 3.2.0</span>) are software
-      devices defining resource allocation on the backing physical device which
-      in turn allows the parent physical device's resources to be divided into
-      several mediated devices, thus sharing the physical device's performance
-      among multiple guests. Unlike SR-IOV however, where a PCIe device appears
-      as multiple separate PCIe devices on the host's PCI bus, mediated devices
-      only appear on the mdev virtual bus. Therefore, no detach/reattach
-      procedure from/to the host driver procedure is involved even though
-      mediated devices are used in a direct device assignment manner.
-    </p>
-
-    <p>
-      The following sub-elements and attributes are exposed within the
-      <code>capability</code> element:
-    </p>
-
-    <dl>
-      <dt><code>type</code></dt>
-      <dd>
-        This element describes a mediated device type which acts as an
-        abstract template defining a resource allocation for instances of this
-        device type. The element has one attribute <code>id</code> which holds
-        an official vendor-supplied identifier for the type.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-
-      <dt><code>iommuGroup</code></dt>
-      <dd>
-        This element supports a single attribute <code>number</code> which holds
-        the IOMMU group number the mediated device belongs to.
-        <span class="since">Since 3.4.0</span>
-      </dd>
-    </dl>
-
-    <h3>Example of a mediated device</h3>
-    <pre>
-&lt;device&gt;
-  &lt;name&gt;mdev_4b20d080_1b54_4048_85b3_a6a62d165c01&lt;/name&gt;
-  &lt;path&gt;/sys/devices/pci0000:00/0000:00:02.0/4b20d080-1b54-4048-85b3-a6a62d165c01&lt;/path&gt;
-  &lt;parent&gt;pci_0000_06_00_0&lt;/parent&gt;
-  &lt;driver&gt;
-    &lt;name&gt;vfio_mdev&lt;/name&gt;
-  &lt;/driver&gt;
-  &lt;capability type='mdev'&gt;
-    &lt;type id='nvidia-11'/&gt;
-    &lt;iommuGroup number='12'/&gt;
-  &lt;capability/&gt;
-&lt;device/&gt;</pre>
-
-    <p>
-      The support of mediated device's framework in libvirt's node device driver
-      covers the following features:
-    </p>
-
-    <ul>
-      <li>
-        list available mediated devices on the host
-        (<span class="since">Since 3.4.0</span>)
-      </li>
-      <li>
-        display device details
-        (<span class="since">Since 3.4.0</span>)
-      </li>
-    </ul>
-
-    <p>
-      Because mediated devices are instantiated from vendor specific templates,
-      simply called 'types', information describing these types is contained
-      within the parent device's capabilities
-      (see the example in <a href="#PCI">PCI host devices</a>).
-    </p>
-
-    <p>
-      To see the supported mediated device types on a specific physical device
-      use the following:
-    </p>
-
-    <pre>
-$ ls /sys/class/mdev_bus/&lt;device&gt;/mdev_supported_types</pre>
-
-    <p>
-      Before creating a mediated device, unbind the device from the respective
-      device driver, eg. subchannel I/O driver for a CCW device. Then bind the
-      device to the respective VFIO driver. For a CCW device, also unbind the
-      corresponding subchannel of the CCW device from the subchannel I/O driver
-      and then bind the subchannel (instead of the CCW device) to the vfio_ccw
-      driver. The below example shows the unbinding and binding steps for a CCW
-      device.
-    </p>
-
-    <pre>
-device="0.0.1234"
-subchannel="0.0.0123"
-echo $device &gt; /sys/bus/ccw/devices/$device/driver/unbind
-echo $subchannel &gt; /sys/bus/css/devices/$subchannel/driver/unbind
-echo $subchannel &gt; /sys/bus/css/drivers/vfio_ccw/bind
-    </pre>
-
-    <p>
-      To manually instantiate a mediated device, use one of the following as a
-      reference. For a CCW device, use the subchannel ID instead of the device
-      ID.
-    </p>
-
-    <pre>
-$ uuidgen &gt; /sys/class/mdev_bus/&lt;device&gt;/mdev_supported_types/&lt;type&gt;/create
-...
-$ echo &lt;UUID&gt; &gt; /sys/class/mdev_bus/&lt;device&gt;/mdev_supported_types/&lt;type&gt;/create</pre>
-
-    <p>
-      Manual removal of a mediated device is then performed as follows:
-    </p>
-
-    <pre>
-$ echo 1 &gt; /sys/bus/mdev/devices/&lt;uuid&gt;/remove</pre>
-
-  </body>
-</html>

docs/drvopenvz.html.in

@@ -1,123 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>OpenVZ container driver</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-    The OpenVZ driver for libvirt allows use and management of container
-    based virtualization on a Linux host OS. Prior to using the OpenVZ
-    driver, the OpenVZ enabled kernel must be installed &amp; booted, and the
-    OpenVZ userspace tools installed. The libvirt driver has been tested
-    with OpenVZ 3.0.22, but other 3.0.x versions should also work without
-    undue trouble.
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="http://openvz.org/">OpenVZ</a> Linux container
-        system
-      </li>
-    </ul>
-
-    <h2><a id="connections">Connections to OpenVZ driver</a></h2>
-
-    <p>
-    The libvirt OpenVZ driver is a single-instance privileged driver,
-    with a driver name of 'openvz'. Some example connection URIs for
-    the libvirt driver are:
-    </p>
-
-<pre>
-openvz:///system                     (local access)
-openvz+unix:///system                (local access)
-openvz://example.com/system          (remote access, TLS/x509)
-openvz+tcp://example.com/system      (remote access, SASl/Kerberos)
-openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
-</pre>
-
-    <h2><a id="notes">Notes on bridged networking</a></h2>
-
-    <p>
-    Bridged networking enables a guest domain (ie container) to have its
-    network interface connected directly to the host's physical LAN. Before
-    this can be used there are a couple of configuration pre-requisites for
-    the host OS.
-    </p>
-
-    <h3><a id="host">Host network devices</a></h3>
-
-    <p>
-    One or more of the physical devices must be attached to a bridge. The
-    process for this varies according to the operating system in use, so
-    for up to date notes consult the <a href="http://wiki.libvirt.org">Wiki</a>
-    or your operating system's networking documentation. The basic idea is
-    that the host OS should end up with a bridge device "br0" containing a
-    physical device "eth0", or a bonding device "bond0".
-    </p>
-
-    <h3><a id="tools">OpenVZ tools configuration</a></h3>
-
-    <p>
-    OpenVZ releases later than 3.0.23 ship with a standard network device
-    setup script that is able to setup bridging, named
-    <code>/usr/sbin/vznetaddbr</code>. For releases prior to 3.0.23, this
-    script must be created manually by the host OS administrator. The
-    simplest way is to just download the latest version of this script
-    from a newer OpenVZ release, or upstream source repository. Then
-    a generic configuration file <code>/etc/vz/vznet.conf</code>
-    must be created containing
-    </p>
-
-<pre>
-#!/bin/bash
-EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
-</pre>
-
-    <p>
-    The host OS is now ready to allow bridging of guest containers, which
-    will work whether the container is started with libvirt, or OpenVZ
-    tools.
-    </p>
-
-
-    <h2><a id="example">Example guest domain XML configuration</a></h2>
-
-    <p>
-    The current libvirt OpenVZ driver has a restriction that the
-    domain names must match the OpenVZ container VEID, which by
-    convention start at 100, and are incremented from there. The
-    choice of OS template to use inside the container is determined
-    by the <code>filesystem</code> tag, and the template source name
-    matches the templates known to OpenVZ tools.
-    </p>
-
-<pre>
-&lt;domain type='openvz' id='104'&gt;
-  &lt;name&gt;104&lt;/name&gt;
-  &lt;uuid&gt;86c12009-e591-a159-6e9f-91d18b85ef78&lt;/uuid&gt;
-  &lt;vcpu&gt;3&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type&gt;exe&lt;/type&gt;
-    &lt;init&gt;/sbin/init&lt;/init&gt;
-  &lt;/os&gt;
-  &lt;devices&gt;
-    &lt;filesystem type='template'&gt;
-      &lt;source name='fedora-9-i386-minimal'/&gt;
-      &lt;target dir='/'/&gt;
-    &lt;/filesystem&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='00:18:51:5b:ea:bf'/&gt;
-      &lt;source bridge='br0'/&gt;
-      &lt;target dev='veth101.0'/&gt;
-    &lt;/interface&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-  </body>
-</html>

docs/drvqemu.html.in

@@ -1,601 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>KVM/QEMU hypervisor driver</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      The libvirt KVM/QEMU driver can manage any QEMU emulator from
-      version 1.5.0 or later.
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="https://www.linux-kvm.org/">KVM</a> Linux
-        hypervisor
-      </li>
-      <li>
-        The <a href="https://wiki.qemu.org/Index.html">QEMU</a> emulator
-      </li>
-    </ul>
-
-    <h2><a id="prereq">Deployment pre-requisites</a></h2>
-
-    <ul>
-      <li>
-        <strong>QEMU emulators</strong>: The driver will probe <code>/usr/bin</code>
-        for the presence of <code>qemu</code>, <code>qemu-system-x86_64</code>,
-        <code>qemu-system-microblaze</code>,
-        <code>qemu-system-microblazeel</code>,
-        <code>qemu-system-mips</code>,<code>qemu-system-mipsel</code>,
-        <code>qemu-system-sparc</code>,<code>qemu-system-ppc</code>. The results
-        of this can be seen from the capabilities XML output.
-      </li>
-      <li>
-        <strong>KVM hypervisor</strong>: The driver will probe <code>/usr/bin</code>
-        for the presence of <code>qemu-kvm</code> and <code>/dev/kvm</code> device
-        node. If both are found, then KVM fully virtualized, hardware accelerated
-        guests will be available.
-      </li>
-    </ul>
-
-    <h2><a id="uris">Connections to QEMU driver</a></h2>
-
-    <p>
-    The libvirt QEMU driver is a multi-instance driver, providing a single
-    system wide privileged driver (the "system" instance), and per-user
-    unprivileged drivers (the "session" instance). The URI driver protocol
-    is "qemu". Some example connection URIs for the libvirt driver are:
-    </p>
-
-<pre>
-qemu:///session                      (local access to per-user instance)
-qemu+unix:///session                 (local access to per-user instance)
-
-qemu:///system                       (local access to system instance)
-qemu+unix:///system                  (local access to system instance)
-qemu://example.com/system            (remote access, TLS/x509)
-qemu+tcp://example.com/system        (remote access, SASl/Kerberos)
-qemu+ssh://root@example.com/system   (remote access, SSH tunnelled)
-</pre>
-
-    <h2><a id="security">Driver security architecture</a></h2>
-
-    <p>
-      There are multiple layers to security in the QEMU driver, allowing for
-      flexibility in the use of QEMU based virtual machines.
-    </p>
-
-    <h3><a id="securitydriver">Driver instances</a></h3>
-
-    <p>
-      As explained above there are two ways to access the QEMU driver
-      in libvirt. The "qemu:///session" family of URIs connect to a
-      libvirtd instance running as the same user/group ID as the client
-      application. Thus the QEMU instances spawned from this driver will
-      share the same privileges as the client application. The intended
-      use case for this driver is desktop virtualization, with virtual
-      machines storing their disk images in the user's home directory and
-      being managed from the local desktop login session.
-    </p>
-
-    <p>
-      The "qemu:///system" family of URIs connect to a
-      libvirtd instance running as the privileged system account 'root'.
-      Thus the QEMU instances spawned from this driver may have much
-      higher privileges than the client application managing them.
-      The intended use case for this driver is server virtualization,
-      where the virtual machines may need to be connected to host
-      resources (block, PCI, USB, network devices) whose access requires
-      elevated privileges.
-    </p>
-
-    <h3><a id="securitydac">POSIX users/groups</a></h3>
-
-    <p>
-      In the "session" instance, the POSIX users/groups model restricts QEMU
-      virtual machines (and libvirtd in general) to only have access to resources
-      with the same user/group ID as the client application. There is no
-      finer level of configuration possible for the "session" instances.
-    </p>
-
-    <p>
-      In the "system" instance, libvirt releases from 0.7.0 onwards allow
-      control over the user/group that the QEMU virtual machines are run
-      as. A build of libvirt with no configuration parameters set will
-      still run QEMU processes as root:root. It is possible to change
-      this default by using the --with-qemu-user=$USERNAME and
-      --with-qemu-group=$GROUPNAME arguments to 'configure' during
-      build. It is strongly recommended that vendors build with both
-      of these arguments set to 'qemu'. Regardless of this build time
-      default, administrators can set a per-host default setting in
-      the <code>/etc/libvirt/qemu.conf</code> configuration file via
-      the <code>user=$USERNAME</code> and <code>group=$GROUPNAME</code>
-      parameters. When a non-root user or group is configured, the
-      libvirt QEMU driver will change uid/gid to match immediately
-      before executing the QEMU binary for a virtual machine.
-    </p>
-
-    <p>
-      If QEMU virtual machines from the "system" instance are being
-      run as non-root, there will be greater restrictions on what
-      host resources the QEMU process will be able to access. The
-      libvirtd daemon will attempt to manage permissions on resources
-      to minimise the likelihood of unintentional security denials,
-      but the administrator / application developer must be aware of
-      some of the consequences / restrictions.
-    </p>
-
-    <ul>
-      <li>
-        <p>
-          The directories <code>/var/run/libvirt/qemu/</code>,
-          <code>/var/lib/libvirt/qemu/</code> and
-          <code>/var/cache/libvirt/qemu/</code> must all have their
-          ownership set to match the user / group ID that QEMU
-          guests will be run as. If the vendor has set a non-root
-          user/group for the QEMU driver at build time, the
-          permissions should be set automatically at install time.
-          If a host administrator customizes user/group in
-          <code>/etc/libvirt/qemu.conf</code>, they will need to
-          manually set the ownership on these directories.
-        </p>
-      </li>
-      <li>
-        <p>
-          When attaching USB and PCI devices to a QEMU guest,
-          QEMU will need to access files in <code>/dev/bus/usb</code>
-          and <code>/sys/bus/pci/devices</code> respectively. The libvirtd daemon
-          will automatically set the ownership on specific devices
-          that are assigned to a guest at start time. There should
-          not be any need for administrator changes in this respect.
-        </p>
-      </li>
-      <li>
-        <p>
-          Any files/devices used as guest disk images must be
-          accessible to the user/group ID that QEMU guests are
-          configured to run as. The libvirtd daemon will automatically
-          set the ownership of the file/device path to the correct
-          user/group ID. Applications / administrators must be aware
-          though that the parent directory permissions may still
-          deny access. The directories containing disk images
-          must either have their ownership set to match the user/group
-          configured for QEMU, or their UNIX file permissions must
-          have the 'execute/search' bit enabled for 'others'.
-        </p>
-        <p>
-          The simplest option is the latter one, of just enabling
-          the 'execute/search' bit. For any directory to be used
-          for storing disk images, this can be achieved by running
-          the following command on the directory itself, and any
-          parent directories
-        </p>
-<pre>
-chmod o+x /path/to/directory
-</pre>
-        <p>
-          In particular note that if using the "system" instance
-          and attempting to store disk images in a user home
-          directory, the default permissions on $HOME are typically
-          too restrictive to allow access.
-        </p>
-      </li>
-    </ul>
-
-    <p>
-      The libvirt maintainers <strong>strongly recommend against</strong>
-      running QEMU as the root user/group. This should not be required
-      in most supported usage scenarios, as libvirt will generally do the
-      right thing to grant QEMU access to files it is permitted to
-      use when it is running non-root.
-    </p>
-
-    <h3><a id="securitycap">Linux process capabilities</a></h3>
-
-    <p>
-      In versions of libvirt prior to 6.0.0, even if QEMU was configured
-      to run as the root user / group, libvirt would strip all process
-      capabilities. This meant that QEMU could only read/write files
-      owned by root, or with open permissions. In reality, stripping
-      capabilities did not have any security benefit, as it was trivial
-      to get commands to run in another context with full capabilities,
-      for example, by creating a cronjob.
-    </p>
-    <p>
-      Thus since 6.0.0, if QEMU is running as root, it will keep all
-      process capabilities. Behaviour when QEMU is running non-root
-      is unchanged, it still has no capabilities.
-    </p>
-
-    <h3><a id="securityselinux">SELinux basic confinement</a></h3>
-
-    <p>
-      The basic SELinux protection for QEMU virtual machines is intended to
-      protect the host OS from a compromised virtual machine process. There
-      is no protection between guests.
-    </p>
-
-    <p>
-      In the basic model, all QEMU virtual machines run under the confined
-      domain <code>root:system_r:qemu_t</code>. It is required that any
-      disk image assigned to a QEMU virtual machine is labelled with
-      <code>system_u:object_r:virt_image_t</code>. In a default deployment,
-      package vendors/distributor will typically ensure that the directory
-      <code>/var/lib/libvirt/images</code> has this label, such that any
-      disk images created in this directory will automatically inherit the
-      correct labelling. If attempting to use disk images in another
-      location, the user/administrator must ensure the directory has be
-      given this requisite label. Likewise physical block devices must
-      be labelled <code>system_u:object_r:virt_image_t</code>.
-    </p>
-    <p>
-      Not all filesystems allow for labelling of individual files. In
-      particular NFS, VFat and NTFS have no support for labelling. In
-      these cases administrators must use the 'context' option when
-      mounting the filesystem to set the default label to
-      <code>system_u:object_r:virt_image_t</code>. In the case of
-      NFS, there is an alternative option, of enabling the <code>virt_use_nfs</code>
-      SELinux boolean.
-    </p>
-
-    <h3><a id="securitysvirt">SELinux sVirt confinement</a></h3>
-
-    <p>
-      The SELinux sVirt protection for QEMU virtual machines builds to the
-      basic level of protection, to also allow individual guests to be
-      protected from each other.
-    </p>
-
-    <p>
-      In the sVirt model, each QEMU virtual machine runs under its own
-      confined domain, which is based on <code>system_u:system_r:svirt_t:s0</code>
-      with a unique category appended, eg, <code>system_u:system_r:svirt_t:s0:c34,c44</code>.
-      The rules are setup such that a domain can only access files which are
-      labelled with the matching category level, eg
-      <code>system_u:object_r:svirt_image_t:s0:c34,c44</code>. This prevents one
-      QEMU process accessing any file resources that are prevent to another QEMU
-      process.
-    </p>
-
-    <p>
-      There are two ways of assigning labels to virtual machines under sVirt.
-      In the default setup, if sVirt is enabled, guests will get an automatically
-      assigned unique label each time they are booted. The libvirtd daemon will
-      also automatically relabel exclusive access disk images to match this
-      label.  Disks that are marked as &lt;shared&gt; will get a generic
-      label <code>system_u:system_r:svirt_image_t:s0</code> allowing all guests
-      read/write access them, while disks marked as &lt;readonly&gt; will
-      get a generic label <code>system_u:system_r:svirt_content_t:s0</code>
-      which allows all guests read-only access.
-    </p>
-
-    <p>
-      With statically assigned labels, the application should include the
-      desired guest and file labels in the XML at time of creating the
-      guest with libvirt. In this scenario the application is responsible
-      for ensuring the disk images &amp; similar resources are suitably
-      labelled to match, libvirtd will not attempt any relabelling.
-    </p>
-
-    <p>
-      If the sVirt security model is active, then the node capabilities
-      XML will include its details. If a virtual machine is currently
-      protected by the security model, then the guest XML will include
-      its assigned labels. If enabled at compile time, the sVirt security
-      model will always be activated if SELinux is available on the host
-      OS. To disable sVirt, and revert to the basic level of SELinux
-      protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
-      file can be used to change the setting to <code>security_driver="none"</code>
-    </p>
-
-    <h3><a id="securitysvirtaa">AppArmor sVirt confinement</a></h3>
-
-    <p>
-      When using basic AppArmor protection for the libvirtd daemon and
-      QEMU virtual machines, the intention is to protect the host OS
-      from a compromised virtual machine process. There is no protection
-      between guests.
-    </p>
-
-    <p>
-      The AppArmor sVirt protection for QEMU virtual machines builds on
-      this basic level of protection, to also allow individual guests to
-      be protected from each other.
-    </p>
-
-    <p>
-      In the sVirt model, if a profile is loaded for the libvirtd daemon,
-      then each <code>qemu:///system</code> QEMU virtual machine will have
-      a profile created for it when the virtual machine is started if one
-      does not already exist. This generated profile uses a profile name
-      based on the UUID of the QEMU virtual machine and contains rules
-      allowing access to only the files it needs to run, such as its disks,
-      pid file and log files. Just before the QEMU virtual machine is
-      started, the libvirtd daemon will change into this unique profile,
-      preventing the QEMU process from accessing any file resources that
-      are present in another QEMU process or the host machine.
-    </p>
-
-    <p>
-      The AppArmor sVirt implementation is flexible in that it allows an
-      administrator to customize the template file in
-      <code>/etc/apparmor.d/libvirt/TEMPLATE</code> for site-specific
-      access for all newly created QEMU virtual machines. Also, when a new
-      profile is generated, two files are created:
-      <code>/etc/apparmor.d/libvirt/libvirt-&lt;uuid&gt;</code> and
-      <code>/etc/apparmor.d/libvirt/libvirt-&lt;uuid&gt;.files</code>. The
-      former can be fine-tuned by the administrator to allow custom access
-      for this particular QEMU virtual machine, and the latter will be
-      updated appropriately when required file access changes, such as when
-      a disk is added. This flexibility allows for situations such as
-      having one virtual machine in complain mode with all others in
-      enforce mode.
-    </p>
-
-    <p>
-      While users can define their own AppArmor profile scheme, a typical
-      configuration will include a profile for <code>/usr/sbin/libvirtd</code>,
-      <code>/usr/lib/libvirt/virt-aa-helper</code> (a helper program which the
-      libvirtd daemon uses instead of manipulating AppArmor directly), and
-      an abstraction to be included by <code>/etc/apparmor.d/libvirt/TEMPLATE</code>
-      (typically <code>/etc/apparmor.d/abstractions/libvirt-qemu</code>).
-      An example profile scheme can be found in the examples/apparmor
-      directory of the source distribution.
-    </p>
-
-    <p>
-      If the sVirt security model is active, then the node capabilities
-      XML will include its details. If a virtual machine is currently
-      protected by the security model, then the guest XML will include
-      its assigned profile name. If enabled at compile time, the sVirt
-      security model will be activated if AppArmor is available on the host
-      OS and a profile for the libvirtd daemon is loaded when libvirtd is
-      started. To disable sVirt, and revert to the basic level of AppArmor
-      protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
-      file can be used to change the setting to <code>security_driver="none"</code>.
-    </p>
-
-
-    <h3><a id="securityacl">Cgroups device ACLs</a></h3>
-
-    <p>
-      Linux kernels have a capability known as "cgroups" which is used
-      for resource management. It is implemented via a number of "controllers",
-      each controller covering a specific task/functional area. One of the
-      available controllers is the "devices" controller, which is able to
-      setup whitelists of block/character devices that a cgroup should be
-      allowed to access. If the "devices" controller is mounted on a host,
-      then libvirt will automatically create a dedicated cgroup for each
-      QEMU virtual machine and setup the device whitelist so that the QEMU
-      process can only access shared devices, and explicitly disks images
-      backed by block devices.
-    </p>
-
-    <p>
-      The list of shared devices a guest is allowed access to is
-    </p>
-
-<pre>
-/dev/null, /dev/full, /dev/zero,
-/dev/random, /dev/urandom,
-/dev/ptmx, /dev/kvm,
-/dev/rtc, /dev/hpet
-</pre>
-
-    <p>
-      In the event of unanticipated needs arising, this can be customized
-      via the <code>/etc/libvirt/qemu.conf</code> file.
-      To mount the cgroups device controller, the following command
-      should be run as root, prior to starting libvirtd
-    </p>
-
-<pre>
-mkdir /dev/cgroup
-mount -t cgroup none /dev/cgroup -o devices
-</pre>
-
-    <p>
-      libvirt will then place each virtual machine in a cgroup at
-      <code>/dev/cgroup/libvirt/qemu/$VMNAME/</code>
-    </p>
-
-    <h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
-
-    <p>The QEMU driver currently supports a single native
-      config format known as <code>qemu-argv</code>. The data for this format
-      is expected to be a single line first a list of environment variables,
-      then the QEMu binary name, finally followed by the QEMU command line
-      arguments</p>
-
-    <h3><a id="xmlimport">Converting from QEMU args to domain XML</a></h3>
-
-    <p>
-      <b>Note:</b> this operation is <span class="removed"> deleted as of
-        5.5.0</span> and will return an error.
-    </p>
-    <p>
-      The <code>virsh domxml-from-native</code> provides a way to
-      convert an existing set of QEMU args into a guest description
-      using libvirt Domain XML that can then be used by libvirt.
-      Please note that this command is intended to be used to convert
-      existing qemu guests previously started from the command line to
-      be managed through libvirt.  It should not be used a method of
-      creating new guests from scratch.  New guests should be created
-      using an application calling the libvirt APIs (see
-      the <a href="apps.html">libvirt applications page</a> for some
-      examples) or by manually crafting XML to pass to virsh.
-    </p>
-
-    <h3><a id="xmlexport">Converting from domain XML to QEMU args</a></h3>
-
-    <p>
-      The <code>virsh domxml-to-native</code> provides a way to convert a
-      guest description using libvirt Domain XML, into a set of QEMU args
-      that can be run manually. Note that currently the command line formatted
-      by libvirt is no longer suited for manually running qemu as the
-      configuration expects various resources and open file descriptors passed
-      to the process which are usually prepared by libvirtd.
-    </p>
-
-    <h2><a id="qemucommand">Pass-through of arbitrary qemu
-    commands</a></h2>
-
-    <p>Libvirt provides an XML namespace and an optional
-      library <code>libvirt-qemu.so</code> for dealing specifically
-      with qemu.  When used correctly, these extensions allow testing
-      specific qemu features that have not yet been ported to the
-      generic libvirt XML and API interfaces.  However, they
-      are <b>unsupported</b>, in that the library is not guaranteed to
-      have a stable API, abusing the library or XML may result in
-      inconsistent state the crashes libvirtd, and upgrading either
-      qemu-kvm or libvirtd may break behavior of a domain that was
-      relying on a qemu-specific pass-through.  If you find yourself
-      needing to use them to access a particular qemu feature, then
-      please post an RFE to the libvirt mailing list to get that
-      feature incorporated into the stable libvirt XML and API
-      interfaces.
-    </p>
-    <p>The library provides two
-      API: <code>virDomainQemuMonitorCommand</code>, for sending an
-      arbitrary monitor command (in either HMP or QMP format) to a
-      qemu guest (<span class="since">Since 0.8.3</span>),
-      and <code>virDomainQemuAttach</code>, for registering a qemu
-      domain that was manually started so that it can then be managed
-      by libvirtd (<span class="since">Since 0.9.4</span>,
-      <span class="removed">removed as of 5.5.0</span>).
-    </p>
-    <p>Additionally, the following XML additions allow fine-tuning of
-      the command line given to qemu when starting a domain
-      (<span class="since">Since 0.8.3</span>).  In order to use the
-      XML additions, it is necessary to issue an XML namespace request
-      (the special <code>xmlns:<i>name</i></code> attribute) that
-      pulls in <code>http://libvirt.org/schemas/domain/qemu/1.0</code>;
-      typically, the namespace is given the name
-      of <code>qemu</code>.  With the namespace in place, it is then
-      possible to add an element <code>&lt;qemu:commandline&gt;</code>
-      under <code>driver</code>, with the following sub-elements
-      repeated as often as needed:
-    </p>
-      <dl>
-        <dt><code>qemu:arg</code></dt>
-        <dd>Add an additional command-line argument to the qemu
-          process when starting the domain, given by the value of the
-          attribute <code>value</code>.
-        </dd>
-        <dt><code>qemu:env</code></dt>
-        <dd>Add an additional environment variable to the qemu
-          process when starting the domain, given with the name-value
-          pair recorded in the attributes <code>name</code>
-          and optional <code>value</code>.</dd>
-      </dl>
-      <p>Example:</p><pre>
-&lt;domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
-  &lt;name&gt;QEMU-fedora-i686&lt;/name&gt;
-  &lt;memory&gt;219200&lt;/memory&gt;
-  &lt;os&gt;
-    &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-system-x86_64&lt;/emulator&gt;
-  &lt;/devices&gt;
-  &lt;qemu:commandline&gt;
-    &lt;qemu:arg value='-newarg'/&gt;
-    &lt;qemu:env name='QEMU_ENV' value='VAL'/&gt;
-  &lt;/qemu:commandline&gt;
-&lt;/domain&gt;
-</pre>
-
-    <h2><a id="xmlnsfeatures">QEMU feature configuration for testing</a></h2>
-
-      <p>
-        In some cases e.g. when developing a new feature or for testing it may
-        be required to control a given qemu feature (or qemu capability) to test
-        it before it's complete or disable it for debugging purposes.
-        <span class="since">Since 5.5.0</span> it's possible to use the same
-        special qemu namespace as above
-        (<code>http://libvirt.org/schemas/domain/qemu/1.0</code>) and use
-        <code>&lt;qemu:capabilities&gt;</code> element to add
-        (<code>&lt;qemu:add capability="capname"/&gt;</code>) or remove
-        (<code>&lt;qemu:del capability="capname"/&gt;</code>) capability bits.
-        The naming of the feature bits is the same libvirt uses in the status
-        XML. Note that this feature is meant for experiments only and should
-        _not_ be used in production.
-      </p>
-
-      <p>Example:</p><pre>
-&lt;domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
-  &lt;name&gt;testvm&lt;/name&gt;
-
-   [...]
-
-  &lt;qemu:capabilities&gt;
-    &lt;qemu:add capability='blockdev'/&gt;
-    &lt;qemu:del capability='drive'/&gt;
-  &lt;/qemu:capabilities&gt;
-&lt;/domain&gt;
-</pre>
-
-    <h2><a id="xmlconfig">Example domain XML config</a></h2>
-
-    <h3>QEMU emulated guest on x86_64</h3>
-
-        <pre>&lt;domain type='qemu'&gt;
-  &lt;name&gt;QEMU-fedora-i686&lt;/name&gt;
-  &lt;uuid&gt;c7a5fdbd-cdaf-9455-926a-d65c16db1809&lt;/uuid&gt;
-  &lt;memory&gt;219200&lt;/memory&gt;
-  &lt;currentMemory&gt;219200&lt;/currentMemory&gt;
-  &lt;vcpu&gt;2&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch='i686' machine='pc'&gt;hvm&lt;/type&gt;
-    &lt;boot dev='cdrom'/&gt;
-  &lt;/os&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-system-x86_64&lt;/emulator&gt;
-    &lt;disk type='file' device='cdrom'&gt;
-      &lt;source file='/home/user/boot.iso'/&gt;
-      &lt;target dev='hdc'/&gt;
-      &lt;readonly/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/home/user/fedora.img'/&gt;
-      &lt;target dev='hda'/&gt;
-    &lt;/disk&gt;
-    &lt;interface type='network'&gt;
-      &lt;source network='default'/&gt;
-    &lt;/interface&gt;
-    &lt;graphics type='vnc' port='-1'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-    <h3>KVM hardware accelerated guest on i686</h3>
-
-        <pre>&lt;domain type='kvm'&gt;
-  &lt;name&gt;demo2&lt;/name&gt;
-  &lt;uuid&gt;4dea24b3-1d52-d8f3-2516-782e98a23fa0&lt;/uuid&gt;
-  &lt;memory&gt;131072&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch="i686"&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;clock sync="localtime"/&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-kvm&lt;/emulator&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/var/lib/libvirt/images/demo2.img'/&gt;
-      &lt;target dev='hda'/&gt;
-    &lt;/disk&gt;
-    &lt;interface type='network'&gt;
-      &lt;source network='default'/&gt;
-      &lt;mac address='24:42:53:21:52:45'/&gt;
-    &lt;/interface&gt;
-    &lt;graphics type='vnc' port='-1' keymap='de'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-  </body>
-</html>

docs/drvremote.html.in

@@ -1,7 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Remote management driver</h1>
-  </body>
-</html>

docs/drvtest.html.in

@@ -1,27 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Test "mock" driver</h1>
-
-    <h2>Connections to Test driver</h2>
-
-    <p>
-    The libvirt Test driver is a per-process fake hypervisor driver,
-    with a driver name of 'test'. The driver maintains all its state
-    in memory. It can start with a pre-configured default config, or
-    be given a path to an alternate config. Some example connection URIs
-    for the libvirt driver are:
-    </p>
-
-<pre>
-test:///default                     (local access, default config)
-test:///path/to/driver/config.xml   (local access, custom config)
-test+unix:///default                (local access, default config, via daemon)
-test://example.com/default          (remote access, TLS/x509)
-test+tcp://example.com/default      (remote access, SASl/Kerberos)
-test+ssh://root@example.com/default (remote access, SSH tunnelled)
-</pre>
-
-  </body>
-</html>

docs/drvvbox.html.in

@@ -1,172 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-    <body>
-        <h1>VirtualBox hypervisor driver</h1>
-        <p>
-        The libvirt VirtualBox driver can manage any VirtualBox version
-        from version 4.0 onwards
-        (<span class="since">since libvirt 3.0.0</span>).
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="http://www.virtualbox.org/">VirtualBox</a>
-        hypervisor
-      </li>
-    </ul>
-
-    <h2>Connections to VirtualBox driver</h2>
-
-    <p>
-    The libvirt VirtualBox driver provides per-user drivers (the "session" instance).
-    The uri of the driver protocol is "vbox". Some example connection URIs for the driver are:
-    </p>
-
-<pre>
-vbox:///session                      (local access to per-user instance)
-vbox+unix:///session                 (local access to per-user instance)
-vbox+tcp://user@example.com/session  (remote access, SASl/Kerberos)
-vbox+ssh://user@example.com/session  (remote access, SSH tunnelled)
-</pre>
-
-    <p>
-      <strong>NOTE: as of libvirt 1.0.6, the VirtualBox driver will always
-        run inside the libvirtd daemon, instead of being built-in to the
-        libvirt.so library directly. This change was required due to the
-        fact that VirtualBox code is LGPLv2-only licensed, which is not
-        compatible with the libvirt.so license of LGPLv2-or-later. The
-        daemon will be auto-started when the first connection to VirtualBox
-        is requested. This change also means that it will not be possible
-        to use VirtualBox URIs on the Windows platform, until additional
-        work is completed to get the libvirtd daemon working there.</strong>
-    </p>
-
-    <h2><a id="xmlconfig">Example domain XML config</a></h2>
-
-<pre>
-&lt;domain type='vbox'&gt;
-  &lt;name&gt;vbox&lt;/name&gt;
-  &lt;uuid&gt;4dab22b31d52d8f32516782e98ab3fa0&lt;/uuid&gt;
-
-  &lt;os&gt;
-    &lt;type&gt;hvm&lt;/type&gt;
-    &lt;boot dev='cdrom'/&gt;
-    &lt;boot dev='hd'/&gt;
-    &lt;boot dev='fd'/&gt;
-    &lt;boot dev='network'/&gt;
-  &lt;/os&gt;
-
-  &lt;memory&gt;654321&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-
-  &lt;features&gt;
-    &lt;pae/&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-
-  &lt;devices&gt;
-    &lt;!--Set IDE controller model to PIIX4 (default PIIX3)--&gt;
-    &lt;controller type='ide' model='piix4'/&gt;
-
-    &lt;controller type='scsi' index='0'/&gt;
-
-    &lt;!--VirtualBox SAS Controller--&gt;
-    &lt;controller type='scsi' index='1' model='lsisas1068'/&gt;
-
-    &lt;disk type='file' device='cdrom'&gt;
-      &lt;source file='/home/user/Downloads/slax-6.0.9.iso'/&gt;
-      &lt;target dev='hdc'/&gt;
-      &lt;readonly/&gt;
-    &lt;/disk&gt;
-
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/home/user/tmp/vbox.vdi'/&gt;
-      &lt;target dev='hdd'/&gt;
-    &lt;/disk&gt;
-
-    &lt;!--Attach to the SCSI controller (index=0, default)--&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/home/user/tmp/vbox2.vdi'/&gt;
-      &lt;target dev='sda' bus='scsi'/&gt;
-    &lt;/disk&gt;
-
-    &lt;!--Attach to the SAS controller (index=1)--&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/home/user/tmp/vbox3.vdi'/&gt;
-      &lt;target dev='sda' bus='scsi'/&gt;
-      &lt;address type='drive' controller='1' bus='0' target='0' unit='0'/&gt;
-    &lt;/disk&gt;
-
-    &lt;disk type='file' device='floppy'&gt;
-      &lt;source file='/home/user/tmp/WIN98C.IMG'/&gt;
-      &lt;target dev='fda'/&gt;
-    &lt;/disk&gt;
-
-    &lt;filesystem type='mount'&gt;
-      &lt;source dir='/home/user/stuff'/&gt;
-      &lt;target dir='my-shared-folder'/&gt;
-    &lt;/filesystem&gt;
-
-    &lt;!--BRIDGE--&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='eth0'/&gt;
-      &lt;mac address='00:16:3e:5d:c7:9e'/&gt;
-      &lt;model type='am79c973'/&gt;
-    &lt;/interface&gt;
-
-    &lt;!--NAT--&gt;
-    &lt;interface type='user'&gt;
-      &lt;mac address='56:16:3e:5d:c7:9e'/&gt;
-      &lt;model type='82540eM'/&gt;
-    &lt;/interface&gt;
-
-    &lt;graphics type='desktop'/&gt;
-
-    &lt;!--Activate the VRDE server with a port in 3389-3689 range--&gt;
-    &lt;graphics type='rdp' autoport='yes' multiUser='yes'/&gt;
-
-    &lt;sound model='sb16'/&gt;
-
-    &lt;parallel type='dev'&gt;
-      &lt;source path='/dev/pts/1'/&gt;
-      &lt;target port='0'/&gt;
-    &lt;/parallel&gt;
-
-    &lt;parallel type='dev'&gt;
-      &lt;source path='/dev/pts/2'/&gt;
-      &lt;target port='1'/&gt;
-    &lt;/parallel&gt;
-
-    &lt;serial type="dev"&gt;
-      &lt;source path="/dev/ttyS0"/&gt;
-      &lt;target port="0"/&gt;
-    &lt;/serial&gt;
-
-    &lt;serial type="pipe"&gt;
-      &lt;source path="/tmp/serial.txt"/&gt;
-      &lt;target port="1"/&gt;
-    &lt;/serial&gt;
-
-    &lt;hostdev mode='subsystem' type='usb'&gt;
-      &lt;source&gt;
-        &lt;vendor id='0x1234'/&gt;
-        &lt;product id='0xbeef'/&gt;
-      &lt;/source&gt;
-    &lt;/hostdev&gt;
-
-    &lt;hostdev mode='subsystem' type='usb'&gt;
-      &lt;source&gt;
-        &lt;vendor id='0x4321'/&gt;
-        &lt;product id='0xfeeb'/&gt;
-      &lt;/source&gt;
-    &lt;/hostdev&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-    </body>
-</html>

docs/drvvirtuozzo.html.in

@@ -1,70 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Virtuozzo driver</h1>
-    <ul id="toc"></ul>
-    <p>
-        The libvirt vz driver can manage Virtuozzo starting from version 6.0.
-    </p>
-
-
-    <h2><a id="project">Project Links</a></h2>
-    <ul>
-      <li>
-        The <a href="http://www.odin.com/products/virtuozzo/">Virtuozzo</a> Solution.
-      </li>
-    </ul>
-
-
-    <h2><a id="uri">Connections to the Virtuozzo driver</a></h2>
-    <p>
-        The libvirt Virtuozzo driver is a single-instance privileged driver, with a driver name of 'virtuozzo'. Some example connection URIs for the libvirt driver are:
-    </p>
-<pre>
-vz:///system                     (local access)
-vz+unix:///system                (local access)
-vz://example.com/system          (remote access, TLS/x509)
-vz+tcp://example.com/system      (remote access, SASl/Kerberos)
-vz+ssh://root@example.com/system (remote access, SSH tunnelled)
-</pre>
-
-    <h2><a id="example">Example guest domain XML configuration</a></h2>
-
-    <p>
-    Virtuozzo driver require at least one hard disk for new domains
-    at this time. It is used for defining directory, where VM should
-    be created.
-    </p>
-
-<pre>
-&lt;domain type='vz'&gt;
-  &lt;name&gt;demo&lt;/name&gt;
-  &lt;uuid&gt;54cdecad-4492-4e31-a209-33cc21d64057&lt;/uuid&gt;
-  &lt;description&gt;some description&lt;/description&gt;
-  &lt;memory unit='KiB'&gt;1048576&lt;/memory&gt;
-  &lt;currentMemory unit='KiB'&gt;1048576&lt;/currentMemory&gt;
-  &lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
-  &lt;os&gt;
-    &lt;type arch='x86_64'&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;clock offset='utc'/&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;destroy&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/storage/vol1'/&gt;
-      &lt;target dev='hda'/&gt;
-    &lt;/disk&gt;
-    &lt;video&gt;
-      &lt;model type='vga' vram='33554432' heads='1'&gt;
-        &lt;acceleration accel3d='no' accel2d='no'/&gt;
-      &lt;/model&gt;
-    &lt;/video&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-
-</pre>
-
-</body></html>

docs/drvvmware.html.in

@@ -1,89 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-    <body>
-        <h1>VMware Workstation / Player / Fusion hypervisors driver</h1>
-        <p>
-        The libvirt VMware driver should be able to manage any Workstation,
-        Player, Fusion version supported by the VMware VIX API. See the
-        compatibility list
-        <a href="http://www.vmware.com/support/developer/vix-api/vix110_reference/">here</a>.
-    </p>
-    <p>
-    This driver uses the "vmrun" utility which is distributed with the VMware VIX API.
-    You can download the VIX API
-    from <a href="http://www.vmware.com/support/developer/vix-api/">here</a>.
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="http://www.vmware.com/">VMware Workstation and
-        Player</a> hypervisors
-      </li>
-      <li>
-        The <a href="http://www.vmware.com/fusion">VMware Fusion</a>
-        hypervisor
-      </li>
-    </ul>
-
-    <h2>Connections to VMware driver</h2>
-
-    <p>
-    The libvirt VMware driver provides per-user drivers (the "session" instance).
-    Three uris are available:
-    </p>
-    <ul>
-      <li>"vmwareplayer" for VMware Player</li>
-      <li>"vmwarews" for VMware Workstation</li>
-      <li>"vmwarefusion" for VMware Fusion</li>
-    </ul>
-    <p>
-    Some example connection URIs for the driver are:
-    </p>
-
-<pre>
-vmwareplayer:///session                  (local access to VMware Player per-user instance)
-vmwarews:///session                      (local access to VMware Workstation per-user instance)
-vmwarefusion:///session                      (local access to VMware Fusion per-user instance)
-vmwarews+tcp://user@example.com/session  (remote access to VMware Workstation, SASl/Kerberos)
-vmwarews+ssh://user@example.com/session  (remote access to VMware Workstation, SSH tunnelled)
-</pre>
-
-    <h2><a id="xmlconfig">Example domain XML config</a></h2>
-
-<pre>
-&lt;domain type='vmware'&gt;
-  &lt;name&gt;vmware&lt;/name&gt;
-  &lt;uuid&gt;bea92244-8885-4562-828b-3b086731c5b1&lt;/uuid&gt;
-
-  &lt;os&gt;
-    &lt;type&gt;hvm&lt;/type&gt;
-  &lt;/os&gt;
-
-  &lt;memory&gt;524288&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-
-  &lt;features&gt;
-    &lt;pae/&gt;
-    &lt;acpi/&gt;
-  &lt;/features&gt;
-
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;source file='/home/user/tmp/disk.vmdk'/&gt;
-      &lt;target bus='ide' dev='hda'/&gt;
-    &lt;/disk&gt;
-
-    &lt;interface type='bridge'&gt;
-      &lt;target dev='/dev/vmnet1'/&gt;
-      &lt;source bridge=''/&gt;
-      &lt;mac address='00:16:3e:5d:c7:9e'/&gt;
-    &lt;/interface&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;
-</pre>
-
-    </body>
-</html>

docs/drvxen.html.in

@@ -1,318 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>libxl hypervisor driver for Xen</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      The libvirt libxl driver provides the ability to manage virtual
-      machines on any Xen release from 4.6.0 onwards.
-    </p>
-
-    <h2><a id="project">Project Links</a></h2>
-
-    <ul>
-      <li>
-        The <a href="https://www.xenproject.org">Xen</a>
-        hypervisor on Linux and Solaris hosts
-      </li>
-    </ul>
-
-    <h2><a id="prereq">Deployment pre-requisites</a></h2>
-
-    <p>
-      The libvirt libxl driver uses Xen's libxl API, also known as
-      libxenlight, to implement libvirt's hypervisor driver
-      functionality. libxl provides a consolidated interface for
-      managing a Xen host and its virtual machines, unlike old
-      versions of Xen where applications often had to communicate
-      with xend, xenstored, and the hypervisor itself via hypercalls.
-      With libxl the only pre-requisit is a properly installed Xen
-      host with the libxl toolstack running in a service domain
-      (often Domain-0).
-    </p>
-
-    <h2><a id="uri">Connections to libxl driver</a></h2>
-
-    <p>
-      The libvirt libxl driver is a single-instance privileged driver,
-      with a driver name of 'xen'. Some example connection URIs for
-      the libxl driver are:
-    </p>
-
-<pre>
-xen:///system                     (local access, direct)
-xen+unix:///system                (local access, via daemon)
-xen://example.com/system          (remote access, TLS/x509)
-xen+tcp://example.com/system      (remote access, SASl/Kerberos)
-xen+ssh://root@example.com/system (remote access, SSH tunnelled)
-</pre>
-
-    <h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
-
-    <p>
-      The libxl driver currently supports three native
-      config formats. The first, known as <code>xen-xm</code>, is the
-      original Xen virtual machine config format used by the legacy
-      xm/xend toolstack. The second, known as <code>xen-sxpr</code>,
-      is also one of the original formats that was used by xend's
-      legacy HTTP RPC service (<span class='removed'>removed in 5.6.0</span>)
-    </p>
-
-    <p>
-      The third format is <code>xen-xl</code>, which is the virtual
-      machine config format supported by modern Xen. The <code>xen-xl</code>
-      format is described in the xl.cfg(5) man page.
-    </p>
-
-    <h3><a id="xmlimport">Converting from XM config files to domain XML</a></h3>
-
-    <p>
-      The <code>virsh domxml-from-native</code> provides a way to convert an
-      existing set of xl, xm, or sxpr config files to libvirt Domain XML,
-      which can then be used by libvirt.
-    </p>
-
-    <pre>$ virsh -c xen:///system domxml-from-native xen-xm rhel5.cfg
-&lt;domain type='xen'&gt;
-  &lt;name&gt;rhel5pv&lt;/name&gt;
-  &lt;uuid&gt;8f07fe28-753f-2729-d76d-bdbd892f949a&lt;/uuid&gt;
-  &lt;memory&gt;2560000&lt;/memory&gt;
-  &lt;currentMemory&gt;307200&lt;/currentMemory&gt;
-  &lt;vcpu&gt;4&lt;/vcpu&gt;
-  &lt;bootloader&gt;/usr/bin/pygrub&lt;/bootloader&gt;
-  &lt;os&gt;
-    &lt;type arch='x86_64' machine='xenpv'&gt;linux&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;clock offset='utc'/&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;restart&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;driver name='tap' type='aio'/&gt;
-      &lt;source file='/var/lib/xen/images/rhel5pv.img'/&gt;
-      &lt;target dev='xvda' bus='xen'/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;driver name='tap' type='qcow'/&gt;
-      &lt;source file='/root/qcow1-xen.img'/&gt;
-      &lt;target dev='xvdd' bus='xen'/&gt;
-    &lt;/disk&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='00:16:3e:60:36:ba'/&gt;
-      &lt;source bridge='xenbr0'/&gt;
-    &lt;/interface&gt;
-    &lt;console type='pty'&gt;
-      &lt;target port='0'/&gt;
-    &lt;/console&gt;
-    &lt;input type='mouse' bus='xen'/&gt;
-    &lt;graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-    <h3><a id="xmlexport">Converting from domain XML to XM config files</a></h3>
-
-    <p>
-      The <code>virsh domxml-to-native</code> provides a way to convert a
-      guest description using libvirt Domain XML into xl, xm, or sxpr config
-      format.
-    </p>
-
-    <pre>$ virsh -c xen:///system domxml-to-native xen-xm rhel5pv.xml
-name = "rhel5pv"
-uuid = "8f07fe28-753f-2729-d76d-bdbd892f949a"
-maxmem = 2500
-memory = 300
-vcpus = 4
-bootloader = "/usr/bin/pygrub"
-kernel = "/var/lib/xen/boot_kernel.0YK-cS"
-ramdisk = "/var/lib/xen/boot_ramdisk.vWgrxK"
-extra = "ro root=/dev/VolGroup00/LogVol00 rhgb quiet"
-on_poweroff = "destroy"
-on_reboot = "restart"
-on_crash = "restart"
-sdl = 0
-vnc = 1
-vncunused = 1
-vnclisten = "0.0.0.0"
-disk = [ "tap:aio:/var/lib/xen/images/rhel5pv.img,xvda,w", "tap:qcow:/root/qcow1-xen.img,xvdd,w" ]
-vif = [ "mac=00:16:3e:60:36:ba,bridge=virbr0,script=vif-bridge,vifname=vif5.0" ]</pre>
-
-    <h2><a id="xmlconfig">Example domain XML config</a></h2>
-
-    <p>
-      Below are some example XML configurations for Xen guest domains.
-      For full details of the available options, consult the <a href="formatdomain.html">domain XML format</a>
-      guide.
-    </p>
-
-    <h3>Paravirtualized guest bootloader</h3>
-
-    <p>
-      Using a bootloader allows a paravirtualized guest to be booted using
-      a kernel stored inside its virtual disk image
-    </p>
-
-        <pre>&lt;domain type='xen' &gt;
-  &lt;name&gt;fc8&lt;/name&gt;
-  &lt;bootloader&gt;/usr/bin/pygrub&lt;/bootloader&gt;
-  &lt;os&gt;
-    &lt;type&gt;linux&lt;/type&gt;
-  &lt;/os&gt;
-  &lt;memory&gt;131072&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;devices&gt;
-    &lt;disk type='file'&gt;
-      &lt;source file='/var/lib/xen/images/fc4.img'/&gt;
-      &lt;target dev='sda1'/&gt;
-    &lt;/disk&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='xenbr0'/&gt;
-      &lt;mac address='aa:00:00:00:00:11'/&gt;
-      &lt;script path='/etc/xen/scripts/vif-bridge'/&gt;
-    &lt;/interface&gt;
-    &lt;console tty='/dev/pts/5'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-    <h3>Paravirtualized guest direct kernel boot</h3>
-
-    <p>
-      For installation of paravirtualized guests it is typical to boot the
-      domain using a kernel and initrd stored in the host OS
-    </p>
-
-        <pre>&lt;domain type='xen' &gt;
-  &lt;name&gt;fc8&lt;/name&gt;
-  &lt;os&gt;
-    &lt;type&gt;linux&lt;/type&gt;
-    &lt;kernel&gt;/var/lib/xen/install/vmlinuz-fedora8-x86_64&lt;/kernel&gt;
-    &lt;initrd&gt;/var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64&lt;/initrd&gt;
-    &lt;cmdline&gt; kickstart=http://example.com/myguest.ks &lt;/cmdline&gt;
-  &lt;/os&gt;
-  &lt;memory&gt;131072&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;devices&gt;
-    &lt;disk type='file'&gt;
-      &lt;source file='/var/lib/xen/images/fc4.img'/&gt;
-      &lt;target dev='sda1'/&gt;
-    &lt;/disk&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='xenbr0'/&gt;
-      &lt;mac address='aa:00:00:00:00:11'/&gt;
-      &lt;script path='/etc/xen/scripts/vif-bridge'/&gt;
-    &lt;/interface&gt;
-    &lt;graphics type='vnc' port='-1'/&gt;
-    &lt;console tty='/dev/pts/5'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-    <h3>Fullyvirtualized guest BIOS boot</h3>
-
-    <p>
-      Fullyvirtualized guests use the emulated BIOS to boot off the primary
-      harddisk, CDROM or Network PXE ROM.
-    </p>
-
-        <pre>&lt;domain type='xen' id='3'&gt;
-  &lt;name&gt;fv0&lt;/name&gt;
-  &lt;uuid&gt;4dea22b31d52d8f32516782e98ab3fa0&lt;/uuid&gt;
-  &lt;os&gt;
-    &lt;type&gt;hvm&lt;/type&gt;
-    &lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
-    &lt;boot dev='hd'/&gt;
-  &lt;/os&gt;
-  &lt;memory&gt;524288&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;restart&lt;/on_crash&gt;
-  &lt;features&gt;
-    &lt;pae/&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-  &lt;clock sync="localtime"/&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/lib/xen/bin/qemu-dm&lt;/emulator&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='xenbr0'/&gt;
-      &lt;mac address='00:16:3e:5d:c7:9e'/&gt;
-      &lt;script path='vif-bridge'/&gt;
-    &lt;/interface&gt;
-    &lt;disk type='file'&gt;
-      &lt;source file='/var/lib/xen/images/fv0'/&gt;
-      &lt;target dev='hda'/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='cdrom'&gt;
-      &lt;source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/&gt;
-      &lt;target dev='hdc'/&gt;
-      &lt;readonly/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='floppy'&gt;
-      &lt;source file='/root/fd.img'/&gt;
-      &lt;target dev='fda'/&gt;
-    &lt;/disk&gt;
-    &lt;graphics type='vnc' port='5904'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-    <h3>Fullyvirtualized guest direct kernel boot</h3>
-
-    <p>
-      With Xen 3.2.0 or later it is possible to bypass the BIOS and directly
-      boot a Linux kernel and initrd as a fullyvirtualized domain. This allows
-      for complete automation of OS installation, for example using the Anaconda
-      kickstart support.
-    </p>
-
-        <pre>&lt;domain type='xen' id='3'&gt;
-  &lt;name&gt;fv0&lt;/name&gt;
-  &lt;uuid&gt;4dea22b31d52d8f32516782e98ab3fa0&lt;/uuid&gt;
-  &lt;os&gt;
-    &lt;type&gt;hvm&lt;/type&gt;
-    &lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
-    &lt;kernel&gt;/var/lib/xen/install/vmlinuz-fedora8-x86_64&lt;/kernel&gt;
-    &lt;initrd&gt;/var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64&lt;/initrd&gt;
-    &lt;cmdline&gt; kickstart=http://example.com/myguest.ks &lt;/cmdline&gt;
-  &lt;/os&gt;
-  &lt;memory&gt;524288&lt;/memory&gt;
-  &lt;vcpu&gt;1&lt;/vcpu&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;restart&lt;/on_crash&gt;
-  &lt;features&gt;
-    &lt;pae/&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-  &lt;clock sync="localtime"/&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/lib/xen/bin/qemu-dm&lt;/emulator&gt;
-    &lt;interface type='bridge'&gt;
-      &lt;source bridge='xenbr0'/&gt;
-      &lt;mac address='00:16:3e:5d:c7:9e'/&gt;
-      &lt;script path='vif-bridge'/&gt;
-    &lt;/interface&gt;
-    &lt;disk type='file'&gt;
-      &lt;source file='/var/lib/xen/images/fv0'/&gt;
-      &lt;target dev='hda'/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='cdrom'&gt;
-      &lt;source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/&gt;
-      &lt;target dev='hdc'/&gt;
-      &lt;readonly/&gt;
-    &lt;/disk&gt;
-    &lt;disk type='file' device='floppy'&gt;
-      &lt;source file='/root/fd.img'/&gt;
-      &lt;target dev='fda'/&gt;
-    &lt;/disk&gt;
-    &lt;graphics type='vnc' port='5904'/&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</pre>
-
-  </body>
-</html>

docs/errors.html.in

@@ -1,84 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1 >Handling of errors</h1>
-    <p>The main goals of libvirt when it comes to error handling are:</p>
-    <ul>
-      <li>provide as much detail as possible</li>
-      <li>provide the information as soon as possible</li>
-      <li>dont force the library user into one style of error handling</li>
-    </ul>
-    <p>As result the library provide both synchronous, callback based and
-asynchronous error reporting. When an error happens in the library code the
-error is logged, allowing to retrieve it later and if the user registered an
-error callback it will be called synchronously. Once the call to libvirt ends
-the error can be detected by the return value and the full information for
-the last logged error can be retrieved.</p>
-    <p>To avoid as much as possible troubles with a global variable in a
-multithreaded environment, libvirt will associate when possible the errors to
-the current connection they are related to, that way the error is stored in a
-dynamic structure which can be made thread specific. Error callback can be
-set specifically to a connection with</p>
-    <p>So error handling in the code is the following:</p>
-    <ol>
-      <li>if the error can be associated to a connection for example when failing
-    to look up a domain
-    <ol><li>if there is a callback associated to the connection set with <a href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
-        call it with the error information</li><li>otherwise if there is a global callback set with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
-        call it with the error information</li><li>otherwise call <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
-        which is the default error function of the library issuing the error
-        on stderr</li><li>save the error in the connection for later retrieval with <a href="html/libvirt-virterror.html#virConnGetLastError">virConnGetLastError</a></li></ol></li>
-      <li>otherwise like when failing to create a hypervisor connection:
-    <ol><li>if there is a global callback set with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
-        call it with the error information</li><li>otherwise call <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
-        which is the default error function of the library issuing the error
-        on stderr</li><li>save the error in the connection for later retrieval with <a href="html/libvirt-virterror.html#virGetLastError">virGetLastError</a></li></ol></li>
-    </ol>
-    <p>In all cases the error information is provided as a <a href="html/libvirt-virterror.html#virErrorPtr">virErrorPtr</a> pointer to
-read-only structure <a href="html/libvirt-virterror.html#virError">virError</a> containing the
-following fields:</p>
-    <ul>
-      <li>code: an error number from the <a href="html/libvirt-virterror.html#virErrorNumber">virErrorNumber</a>
-  enum</li>
-      <li>domain: an enum indicating which part of libvirt raised the error see
-    <a href="html/libvirt-virterror.html#virErrorDomain">virErrorDomain</a></li>
-      <li>level: the error level, usually VIR_ERR_ERROR, though there is room for
-    warnings like VIR_ERR_WARNING</li>
-      <li>message: the full human-readable formatted string of the error</li>
-      <li>conn: if available a pointer to the <a href="html/libvirt-libvirt-host.html#virConnectPtr">virConnectPtr</a>
-    connection to the hypervisor where this happened</li>
-      <li>dom: if available a pointer to the <a href="html/libvirt-libvirt-domain.html#virDomainPtr">virDomainPtr</a> domain
-    targeted in the operation</li>
-    </ul>
-    <p>and then extra raw information about the error which may be initialized
-to 0 or NULL if unused</p>
-    <ul>
-      <li>str1, str2, str3: string information, usually str1 is the error
-    message format</li>
-      <li>int1, int2: integer information</li>
-    </ul>
-    <p>So usually, setting up specific error handling with libvirt consist of
-registering a handler with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a> or
-with <a href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
-check the value of the code value, take appropriate action, if needed let
-libvirt print the error on stderr by calling <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>.
-For asynchronous error handing, set such a function doing nothing to avoid
-the error being reported on stderr, and call virConnGetLastError or
-virGetLastError when an API call returned an error value. It can be a good
-idea to use <a href="html/libvirt-virterror.html#virResetLastError">virResetError</a> or <a href="html/libvirt-virterror.html#virConnResetLastError">virConnResetLastError</a>
-once an error has been processed fully.</p>
-    <p>At the python level, there only a global reporting callback function at
-this point, see the error.py example about it:</p>
-    <pre>def handler(ctxt, err):
-    global errno
-
-    #print "handler(%s, %s)" % (ctxt, err)
-    errno = err
-
-libvirt.registerErrorHandler(handler, 'context') </pre>
-    <p>the second argument to the registerErrorHandler function is passed as the
-first argument of the callback like in the C version. The error is a tuple
-containing the same field as a virError in C, but cast to Python.</p>
-  </body>
-</html>

docs/firewall.html.in

@@ -1,514 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1 >Firewall and network filtering in libvirt</h1>
-    <p>There are three pieces of libvirt functionality which do network
-       filtering of some type.
-       <br /><br />
-       At a high level they are:
-    </p>
-    <ul>
-      <li>The virtual network driver
-          <br /><br />
-          This provides an isolated bridge device (ie no physical NICs
-          enslaved). Guest TAP devices are attached to this bridge.
-          Guests can talk to each other and the host, and optionally the
-          wider world.
-          <br /><br />
-      </li>
-      <li>The QEMU driver MAC filtering
-          <br /><br />
-          This provides a generic filtering of MAC addresses to prevent
-          the guest spoofing its MAC address. This is mostly obsoleted by
-          the next item, so won't be discussed further.
-          <br /><br />
-      </li>
-      <li>The network filter driver
-          <br /><br />
-          This provides fully configurable, arbitrary network filtering
-          of traffic on guest NICs. Generic rulesets are defined at the
-          host level to control traffic in some manner. Rules sets are
-          then associated with individual NICs of a guest. While not as
-          expressive as directly using iptables/ebtables, this can still
-          do nearly everything you would want to on a guest NIC filter.
-      </li>
-    </ul>
-
-    <h3><a id="fw-virtual-network-driver">The virtual network driver</a>
-    </h3>
-    <p>The typical configuration for guests is to use bridging of the
-       physical NIC on the host to connect the guest directly to the LAN.
-       In RHEL6 there is also the possibility of using macvtap/sr-iov
-       and VEPA connectivity. None of this stuff plays nicely with wireless
-       NICs, since they will typically silently drop any traffic with a
-       MAC address that doesn't match that of the physical NIC.
-    </p>
-    <p>Thus the virtual network driver in libvirt was invented. This takes
-       the form of an isolated bridge device (ie one with no physical NICs
-       enslaved). The TAP devices associated with the guest NICs are attached
-       to the bridge device. This immediately allows guests on a single host
-       to talk to each other and to the host OS (modulo host IPtables rules).
-    </p>
-    <p>libvirt then uses iptables to control what further connectivity is
-       available. There are three configurations possible for a virtual
-       network at time of writing:
-    </p>
-    <ul>
-      <li>isolated: all off-node traffic is completely blocked</li>
-      <li>nat: outbound traffic to the LAN is allowed, but MASQUERADED</li>
-      <li>forward: outbound traffic to the LAN is allowed</li>
-    </ul>
-    <p>The latter 'forward' case requires the virtual network be on a
-       separate sub-net from the main LAN, and that the LAN admin has
-       configured routing for this subnet.  In the future we intend to
-       add support for IP subnetting and/or proxy-arp. This allows for
-       the virtual network to use the same subnet as the main LAN and
-       should avoid need for the LAN admin to configure special routing.
-    </p>
-    <p>Libvirt will optionally also provide DHCP services to the virtual
-       network using DNSMASQ. In all cases, we need to allow DNS/DHCP
-       queries to the host OS. Since we can't predict whether the host
-       firewall setup is already allowing this, we insert 4 rules into
-       the head of the INPUT chain
-    </p>
-    <pre>
-target     prot opt in     out     source               destination
-ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
-ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
-ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
-ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:67</pre>
-    <p>Note we have restricted our rules to just the bridge associated
-       with the virtual network, to avoid opening undesirable holes in
-       the host firewall wrt the LAN/WAN.
-    </p>
-    <p>The next rules depend on the type of connectivity allowed, and go
-       in the main FORWARD chain:
-    </p>
-    <ul>
-      <li>type=isolated
-          <br /><br />
-Allow traffic between guests. Deny inbound. Deny outbound.
-    <pre>
-target     prot opt in     out     source               destination
-ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0
-REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
-REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
-      </li>
-      <li>type=nat
-          <br /><br />
-Allow inbound related to an established connection. Allow
-outbound, but only from our expected subnet. Allow traffic
-between guests. Deny all other inbound. Deny all other outbound.
-    <pre>
-target     prot opt in     out     source               destination
-ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED
-ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0
-ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
-REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
-REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
-      </li>
-      <li>type=routed
-          <br /><br />
-Allow inbound, but only to our expected subnet. Allow
-outbound, but only from our expected subnet. Allow traffic
-between guests. Deny all other inbound. Deny all other outbound.
-    <pre>
-target     prot opt in     out     source               destination
-ACCEPT     all  --  *      virbr2  0.0.0.0/0            192.168.124.0/24
-ACCEPT     all  --  virbr2 *       192.168.124.0/24     0.0.0.0/0
-ACCEPT     all  --  virbr2 virbr2  0.0.0.0/0            0.0.0.0/0
-REJECT     all  --  *      virbr2  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
-REJECT     all  --  virbr2 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
-      </li>
-      <li>Finally, with type=nat, there is also an entry in the POSTROUTING
-chain to apply masquerading:
-    <pre>
-target     prot opt in     out     source               destination
-MASQUERADE all  --  *      *       192.168.122.0/24    !192.168.122.0/24</pre>
-      </li>
-    </ul>
-
-    <h3><a id="fw-firewalld-and-virtual-network-driver">firewalld and the virtual network driver</a>
-    </h3>
-    <p>
-      If <a href="https://firewalld.org">firewalld</a> is active on
-      the host, libvirt will attempt to place the bridge interface of
-      a libvirt virtual network into the firewalld zone named
-      "libvirt" (thus making all guest->host traffic on that network
-      subject to the rules of the "libvirt" zone). This is done
-      because, if firewalld is using its nftables backend (available
-      since firewalld 0.6.0) the default firewalld zone (which would
-      be used if libvirt didn't explicitly set the zone) prevents
-      forwarding traffic from guests through the bridge, as well as
-      preventing DHCP, DNS, and most other traffic from guests to
-      host. The zone named "libvirt" is installed into the firewalld
-      configuration by libvirt (not by firewalld), and allows
-      forwarded traffic through the bridge as well as DHCP, DNS, TFTP,
-      and SSH traffic to the host - depending on firewalld's backend
-      this will be implemented via either iptables or nftables
-      rules. libvirt's own rules outlined above will *always* be
-      iptables rules regardless of which backend is in use by
-      firewalld.
-    </p>
-    <p>
-      NB: It is possible to manually set the firewalld zone for a
-      network's interface with the "zone" attribute of the network's
-      "bridge" element.
-    </p>
-    <p>
-      NB: Prior to libvirt 5.1.0, the firewalld "libvirt" zone did not
-      exist, and prior to firewalld 0.7.0 a feature crucial to making
-      the "libvirt" zone operate properly (rich rule priority
-      settings) was not implemented in firewalld. In cases where one
-      or the other of the two packages is missing the necessary
-      functionality, it's still possible to have functional guest
-      networking by setting the firewalld backend to "iptables" (in
-      firewalld prior to 0.6.0, this was the only backend available).
-    </p>
-
-    <h3><a id="fw-network-filter-driver">The network filter driver</a>
-    </h3>
-    <p>This driver provides a fully configurable network filtering capability
-       that leverages ebtables, iptables and ip6tables. This was written by
-       the libvirt guys at IBM and although its XML schema is defined by libvirt,
-       the conceptual model is closely aligned with the DMTF CIM schema for
-       network filtering:
-    </p>
-    <p><a href="http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf">http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf</a></p>
-    <p>The filters are managed in libvirt as a top level, standalone object.
-       This allows the filters to then be referenced by any libvirt object
-       that requires their functionality, instead tying them only to use
-       by guest NICs. In the current implementation, filters can be associated
-       with individual guest NICs via the libvirt domain XML format. In the
-       future we might allow filters to be associated with the virtual network
-       objects. Further we're expecting to define a new 'virtual switch' object
-       to remove the complexity of configuring bridge/sriov/vepa networking
-       modes. This make also end up making use of network filters.
-    </p>
-    <p>There are a new set of virsh commands for managing network filters:</p>
-    <ul>
-      <li>virsh nwfilter-define
-          <br /><br />
-          define or update a network filter from an XML file
-          <br /><br />
-      </li>
-      <li>virsh nwfilter-undefine
-          <br /><br />
-          undefine a network filter
-          <br /><br />
-      </li>
-      <li>virsh nwfilter-dumpxml
-          <br /><br />
-          network filter information in XML
-          <br /><br />
-      </li>
-      <li>virsh nwfilter-list
-          <br /><br />
-          list network filters
-          <br /><br />
-      </li>
-      <li>virsh nwfilter-edit
-          <br /><br />
-          edit XML configuration for a network filter
-      </li>
-    </ul>
-    <p>There are equivalently named C APIs for each of these commands.</p>
-    <p>As with all objects libvirt manages, network filters are configured
-using an XML format. At a high level the format looks like this:
-    </p>
-<pre>
-&lt;filter name='no-spamming' chain='XXXX'&gt;
-  &lt;uuid&gt;d217f2d7-5a04-0e01-8b98-ec2743436b74&lt;/uuid&gt;
-
-  &lt;rule ...&gt;
-    ....
-  &lt;/rule&gt;
-
-  &lt;filterref filter='XXXX'/&gt;
-&lt;/filter&gt;</pre>
-    <p>Every filter has a name and UUID which serve as unique identifiers.
-       A filter can have zero-or-more <code>&lt;rule&gt;</code> elements which
-       are used to actually define network controls. Filters can be arranged
-       into a DAG, so zero-or-more <code>&lt;filterref/&gt;</code> elements are
-       also allowed. Cycles in the graph are not allowed.
-    </p>
-    <p>The <code>&lt;rule&gt;</code> element is where all the interesting stuff
-       happens. It has three attributes, an action, a traffic direction and an
-       optional priority. E.g.:
-    </p>
-    <pre>&lt;rule action='drop' direction='out' priority='500'&gt;</pre>
-    <p>Within the rule there are a wide variety of elements allowed, which
-       do protocol specific matching. Supported protocols currently include
-       <code>mac</code>, <code>arp</code>, <code>rarp</code>, <code>ip</code>,
-       <code>ipv6</code>, <code>tcp/ip</code>, <code>icmp/ip</code>,
-       <code>igmp/ip</code>, <code>udp/ip</code>, <code>udplite/ip</code>,
-       <code>esp/ip</code>, <code>ah/ip</code>, <code>sctp/ip</code>,
-       <code>tcp/ipv6</code>, <code>icmp/ipv6</code>, <code>igmp/ipv6</code>,
-       <code>udp/ipv6</code>, <code>udplite/ipv6</code>, <code>esp/ipv6</code>,
-       <code>ah/ipv6</code>, <code>sctp/ipv6</code>. Each protocol defines what
-       is valid inside the &lt;rule&gt; element. The general pattern though is:
-    </p>
-    <pre>
-&lt;protocol match='yes|no' attribute1='value1' attribute2='value2'/&gt;</pre>
-    <p>So, eg a TCP protocol, matching ports 0-1023 would be expressed as:</p>
-    <pre>&lt;tcp match='yes' srcportstart='0' srcportend='1023'/&gt;</pre>
-    <p>Attributes can included references to variables defined by the
-       object using the rule. So the guest XML format allows each NIC
-       to have a MAC address and IP address defined. These are made
-       available to filters via the variables <code><b>$IP</b></code> and
-       <code><b>$MAC</b></code>.
-    </p>
-    <p>So to define a filter that prevents IP address spoofing we can
-       simply match on source IP address <code>!= $IP</code> like this:
-    </p>
-    <pre>
-&lt;filter name='no-ip-spoofing' chain='ipv4'&gt;
-  &lt;rule action='drop' direction='out'&gt;
-    &lt;ip match='no' srcipaddr='<b>$IP</b>' /&gt;
-  &lt;/rule&gt;
-&lt;/filter&gt;</pre>
-    <p>I'm not going to go into details on all the other protocol
-       matches you can do, because it'll take far too much space.
-       You can read about the options
-       <a href="formatnwfilter.html#nwfelemsRulesProto">here</a>.
-    </p>
-    <p>Out of the box in RHEL6/Fedora rawhide, libvirt ships with a
-       set of default useful rules:
-    </p>
-    <pre>
-# virsh nwfilter-list
-UUID                                  Name
-----------------------------------------------------------------
-15b1ab2b-b1ac-1be2-ed49-2042caba4abb  allow-arp
-6c51a466-8d14-6d11-46b0-68b1a883d00f  allow-dhcp
-7517ad6c-bd90-37c8-26c9-4eabcb69848d  allow-dhcp-server
-3d38b406-7cf0-8335-f5ff-4b9add35f288  allow-incoming-ipv4
-5ff06320-9228-2899-3db0-e32554933415  allow-ipv4
-db0b1767-d62b-269b-ea96-0cc8b451144e  clean-traffic
-f88f1932-debf-4aa1-9fbe-f10d3aa4bc95  no-arp-spoofing
-772f112d-52e4-700c-0250-e178a3d91a7a  no-ip-multicast
-7ee20370-8106-765d-f7ff-8a60d5aaf30b  no-ip-spoofing
-d5d3c490-c2eb-68b1-24fc-3ee362fc8af3  no-mac-broadcast
-fb57c546-76dc-a372-513f-e8179011b48a  no-mac-spoofing
-dba10ea7-446d-76de-346f-335bd99c1d05  no-other-l2-traffic
-f5c78134-9da4-0c60-a9f0-fb37bc21ac1f  no-other-rarp-traffic
-7637e405-4ccf-42ac-5b41-14f8d03d8cf3  qemu-announce-self
-9aed52e7-f0f3-343e-fe5c-7dcb27b594e5  qemu-announce-self-rarp</pre>
-    <p>Most of these are just building blocks. The interesting one here
-       is 'clean-traffic'. This pulls together all the building blocks
-       into one filter that you can then associate with a guest NIC.
-       This stops the most common bad things a guest might try, IP
-       spoofing, arp spoofing and MAC spoofing. To look at the rules for
-       any of these just do:
-    </p>
-    <pre>virsh nwfilter-dumpxml FILTERNAME|UUID</pre>
-    <p>They are all stored in <code>/etc/libvirt/nwfilter</code>, but don't
-       edit the files there directly. Use <code>virsh nwfilter-define</code>
-       to update them. This ensures the guests have their iptables/ebtables
-       rules recreated.
-    </p>
-    <p>To associate the clean-traffic filter with a guest, edit the
-       guest XML config and change the <code>&lt;interface&gt;</code> element
-       to include a <code>&lt;filterref&gt;</code> and also specify the
-       whitelisted <code>&lt;ip address/&gt;</code> the guest is allowed to
-       use:
-    </p>
-    <pre>
-&lt;interface type='bridge'&gt;
-  &lt;mac address='52:54:00:56:44:32'/&gt;
-  &lt;source bridge='br1'/&gt;
-  &lt;ip address='10.33.8.131'/&gt;
-  &lt;target dev='vnet0'/&gt;
-  &lt;model type='virtio'/&gt;
-  &lt;filterref filter='clean-traffic'/&gt;
-&lt;/interface&gt;</pre>
-    <p>If no <code>&lt;ip address&gt;</code> is included, the network filter
-       driver will activate its 'learning mode'. This uses libpcap to snoop on
-       network traffic the guest sends and attempts to identify the
-       first IP address it uses. It then locks traffic to this address.
-       Obviously this isn't entirely secure, but it does offer some
-       protection against the guest being trojaned once up and running.
-       In the future we intend to enhance the learning mode so that it
-       looks for DHCPOFFERS from a trusted DHCP server and only allows
-       the offered IP address to be used.
-    </p>
-    <p>Now, how is all this implemented...?</p>
-    <p>The network filter driver uses a combination of ebtables, iptables and
-       ip6tables, depending on which protocols are referenced in a filter. The
-       out of the box 'clean-traffic' filter rules only require use of
-       ebtables. If you want to do matching at tcp/udp/etc protocols (eg to add
-       a new filter 'no-email-spamming' to block port 25), then iptables will
-       also be used.
-    </p>
-    <p>The driver attempts to keep its rules separate from those that
-       the host admin might already have configured. So the first thing
-       it does with ebtables, is to add two hooks in POSTROUTING and
-       PREROUTING chains, to redirect traffic to custom chains. These
-       hooks match on the TAP device name of the guest NIC, so they
-       should not interact badly with any administrator defined rules:
-    </p>
-    <pre>
-Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
--i vnet0 -j libvirt-I-vnet0
-
-Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
--o vnet0 -j libvirt-O-vnet0</pre>
-    <p>To keep things manageable and easy to follow, the driver will then
-       create further sub-chains for each protocol then it needs to match
-       against:
-    </p>
-    <pre>
-Bridge chain: libvirt-I-vnet0, entries: 5, policy: ACCEPT
--p IPv4 -j I-vnet0-ipv4
--p ARP -j I-vnet0-arp
--p 0x8035 -j I-vnet0-rarp
--p 0x835 -j ACCEPT
--j DROP
-
-Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
--p IPv4 -j O-vnet0-ipv4
--p ARP -j O-vnet0-arp
--p 0x8035 -j O-vnet0-rarp
--j DROP</pre>
-    <p>Finally, here comes the actual implementation of the filters. This
-       example shows the 'clean-traffic' filter implementation.
-       I'm not going to explain what this is doing now. :-)
-    </p>
-    <pre>
-Bridge chain: I-vnet0-ipv4, entries: 2, policy: ACCEPT
--s ! 52:54:0:56:44:32 -j DROP
--p IPv4 --ip-src ! 10.33.8.131 -j DROP
-
-Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
--j ACCEPT
-
-Bridge chain: I-vnet0-arp, entries: 6, policy: ACCEPT
--s ! 52:54:0:56:44:32 -j DROP
--p ARP --arp-mac-src ! 52:54:0:56:44:32 -j DROP
--p ARP --arp-ip-src ! 10.33.8.131 -j DROP
--p ARP --arp-op Request -j ACCEPT
--p ARP --arp-op Reply -j ACCEPT
--j DROP
-
-Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT
--p ARP --arp-op Reply --arp-mac-dst ! 52:54:0:56:44:32 -j DROP
--p ARP --arp-ip-dst ! 10.33.8.131 -j DROP
--p ARP --arp-op Request -j ACCEPT
--p ARP --arp-op Reply -j ACCEPT
--j DROP
-
-Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT
--p 0x8035 -s 52:54:0:56:44:32 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
--j DROP
-
-Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT
--p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
--j DROP</pre>
-    <p>NB, we would have liked to include the prefix 'libvirt-' in all
-       of our chain names, but unfortunately the kernel limits names
-       to a very short maximum length. So only the first two custom
-       chains can include that prefix. The others just include the
-       TAP device name + protocol name.
-    </p>
-    <p>If I define a new filter 'no-spamming' and then add this to the
-       'clean-traffic' filter, I can illustrate how iptables usage works:
-    </p>
-    <pre>
-# cat &gt; /root/spamming.xml &lt;&lt;EOF
-&lt;filter name='no-spamming' chain='root'&gt;
-  &lt;uuid&gt;d217f2d7-5a04-0e01-8b98-ec2743436b74&lt;/uuid&gt;
-  &lt;rule action='drop' direction='out' priority='500'&gt;
-    &lt;tcp dstportstart='25' dstportend='25'/&gt;
-  &lt;/rule&gt;
-&lt;/filter&gt;
-EOF
-# virsh nwfilter-define /root/spamming.xml
-# virsh nwfilter-edit clean-traffic</pre>
-
-    <p>...add <code>&lt;filterref filter='no-spamming'/&gt;</code></p>
-    <p>All active guests immediately have their iptables/ebtables rules
-       rebuilt.
-    </p>
-    <p>The network filter driver deals with iptables in a very similar
-       way. First it separates out its rules from those the admin may
-       have defined, by adding a couple of hooks into the INPUT/FORWARD
-       chains:
-    </p>
-    <pre>
-Chain INPUT (policy ACCEPT 13M packets, 21G bytes)
-target           prot opt in     out     source               destination
-libvirt-host-in  all  --  *      *       0.0.0.0/0            0.0.0.0/0
-
-Chain FORWARD (policy ACCEPT 5532K packets, 3010M bytes)
-target           prot opt in     out     source               destination
-libvirt-in       all  --  *      *       0.0.0.0/0            0.0.0.0/0
-libvirt-out      all  --  *      *       0.0.0.0/0            0.0.0.0/0
-libvirt-in-post  all  --  *      *       0.0.0.0/0            0.0.0.0/0</pre>
-    <p>These custom chains then do matching based on the TAP device
-       name, so they won't open holes in the admin defined matches for
-       the LAN/WAN (if any).
-    </p>
-    <pre>
-Chain libvirt-host-in (1 references)
-  target     prot opt in     out     source               destination
-  HI-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-in vnet0
-
-Chain libvirt-in (1 references)
-  target     prot opt in     out     source               destination
-  FI-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-in vnet0
-
-Chain libvirt-in-post (1 references)
-  target     prot opt in     out     source               destination
-  ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vnet0
-
-Chain libvirt-out (1 references)
-  target     prot opt in     out     source               destination
-  FO-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-out vnet0</pre>
-    <p>Finally, we can see the interesting bit which is the actual
-       implementation of my filter to block port 25 access:
-    </p>
-    <pre>
-Chain FI-vnet0 (1 references)
-  target     prot opt in     out     source               destination
-  DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25
-
-Chain FO-vnet0 (1 references)
-  target     prot opt in     out     source               destination
-  DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25
-
-Chain HI-vnet0 (1 references)
-  target     prot opt in     out     source               destination
-  DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25</pre>
-    <p>One thing in looking at this you may notice is that if there
-       are many guests all using the same filters, we will be duplicating
-       the iptables rules over and over for each guest. This is merely a
-       limitation of the current rules engine implementation. At the libvirt
-       object modelling level you can clearly see we've designed the model
-       so filter rules are defined in one place, and indirectly referenced
-       by guests. Thus it should be possible to change the implementation in
-       the future so we can share the actual iptables/ebtables rules for
-       each guest to create a more scalable system. The stuff in current libvirt
-       is more or less the very first working implementation we've had of this,
-       so there's not been much optimization work done yet.
-    </p>
-    <p>Also notice that at the XML level we don't expose the fact we
-       are using iptables or ebtables at all. The rule definition is done in
-       terms of network protocols. Thus if we ever find a need, we could
-       plug in an alternative implementation that calls out to a different
-       firewall implementation instead of ebtables/iptables (providing that
-       implementation was suitably expressive of course)
-    </p>
-    <p>Finally, in terms of problems we have in deployment. The biggest
-       problem is that if the admin does <code>service iptables restart</code>
-       all our work gets blown away. We've experimented with using lokkit
-       to record our custom rules in a persistent config file, but that
-       caused different problem. Admins who were not using lokkit for
-       their config found that all their own rules got blown away. So
-       we threw away our lokkit code. Instead we document that if you
-       run <code>service iptables restart</code>, you need to send SIGHUP to
-       libvirt to make it recreate its rules.
-    </p>
-    <p>More in depth documentation on this is <a href="formatnwfilter.html">here</a>.</p>
-  </body>
-</html>

docs/fonts/LICENSE.md

@@ -1,90 +0,0 @@
-## License
-
-Copyright (C) 2015 Red Hat, Inc.,
-
-This Font Software is licensed under the SIL Open Font License, Version 1.1.
-This license is copied below, and is also available with a FAQ at:
-http://scripts.sil.org/OFL
-
-
-#### SIL OPEN FONT LICENSE
-Version 1.1 - 26 February 2007
-
----
-
-#### PREAMBLE
-The goals of the Open Font License (OFL) are to stimulate worldwide development
-of collaborative font projects, to support the font creation efforts of
-academic and linguistic communities, and to provide a free and open framework
-in which fonts may be shared and improved in partnership with others.
-
-The OFL allows the licensed fonts to be used, studied, modified and
-redistributed freely as long as they are not sold by themselves. The fonts,
-including any derivative works, can be bundled, embedded, redistributed and/or
-sold with any software provided that any reserved names are not used by
-derivative works. The fonts and derivatives, however, cannot be released under
-any other type of license. The requirement for fonts to remain under this
-license does not apply to any document created using the fonts or their
-derivatives.
-
-#### DEFINITIONS
-“Font Software” refers to the set of files released by the Copyright Holder(s)
-under this license and clearly marked as such. This may include source files,
-build scripts and documentation.
-
-“Reserved Font Name” refers to any names specified as such after the copyright
-statement(s).
-
-“Original Version” refers to the collection of Font Software components as
-distributed by the Copyright Holder(s).
-
-“Modified Version” refers to any derivative made by adding to, deleting, or
-substituting—in part or in whole—any of the components of the Original Version,
-by changing formats or by porting the Font Software to a new environment.
-
-“Author” refers to any designer, engineer, programmer, technical writer or
-other person who contributed to the Font Software.
-
-#### PERMISSION & CONDITIONS
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-the Font Software, to use, study, copy, merge, embed, modify, redistribute, and
-sell modified and unmodified copies of the Font Software, subject to the
-following conditions:
-
-1) Neither the Font Software nor any of its individual components, in Original
-or Modified Versions, may be sold by itself.
-
-2) Original or Modified Versions of the Font Software may be bundled,
-redistributed and/or sold with any software, provided that each copy contains
-the above copyright notice and this license. These can be included either as
-stand-alone text files, human-readable headers or in the appropriate machine-
-readable metadata fields within text or binary files as long as those fields
-can be easily viewed by the user.
-
-3) No Modified Version of the Font Software may use the Reserved Font Name(s)
-unless explicit written permission is granted by the corresponding Copyright
-Holder. This restriction only applies to the primary font name as presented to
-the users.
-
-4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software
-shall not be used to promote, endorse or advertise any Modified Version, except
-to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s)
-or with their explicit written permission.
-
-5) The Font Software, modified or unmodified, in part or in whole, must be
-distributed entirely under this license, and must not be distributed under any
-other license. The requirement for fonts to remain under this license does not
-apply to any document created using the Font Software.
-
-#### TERMINATION
-This license becomes null and void if any of the above conditions are not met.
-
-#### DISCLAIMER
-THE FONT SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT,
-TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR
-ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL,
-INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF
-CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE
-THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.

docs/fonts/stylesheet.css

@@ -1,62 +0,0 @@
-@font-face {
-	font-family: 'LibvirtOverpass';
-	src: url('overpass-regular.woff') format('woff');
-	font-weight: normal;
-	font-style: normal;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpass';
-	src: url('overpass-italic.woff') format('woff');
-	font-weight: normal;
-	font-style: italic;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpass';
-	src: url('overpass-bold.woff') format('woff');
-	font-weight: bold;
-	font-style: normal;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpass';
-	src: url('overpass-bold-italic.woff') format('woff');
-	font-weight: bold;
-	font-style: italic;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpassLight';
-	src: url('overpass-light.woff') format('woff');
-	font-weight: 300;
-	font-style: normal;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpassLight';
-	src: url('overpass-light-italic.woff') format('woff');
-	font-weight: 300;
-	font-style: italic;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpassMono';
-	src: url('overpass-mono-regular.woff') format('woff');
-	font-weight: normal;
-	font-style: normal;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpassMono';
-	src: url('overpass-mono-bold.woff') format('woff');
-	font-weight: bold;
-	font-style: normal;
-}
-
-@font-face {
-	font-family: 'LibvirtOverpassMonoLight';
-	src: url('overpass-mono-light.woff') format('woff');
-	font-weight: 300;
-	font-style: normal;
-}

docs/format.html.in

@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>XML Format</h1>
-
-
-    <p>
-      Objects in the libvirt API are configured using XML documents to allow
-      for ease of extension in future releases. Each XML document has an
-      associated Relax-NG schema that can be used to validate documents
-      prior to usage.
-    </p>
-
-
-    <ul>
-      <li><a href="formatdomain.html">Domains</a></li>
-      <li><a href="formatnetwork.html">Networks</a></li>
-      <li><a href="formatnwfilter.html">Network filtering</a></li>
-      <li><a href="formatnetworkport.html">Network ports</a></li>
-      <li><a href="formatstorage.html">Storage</a></li>
-      <li><a href="formatstorageencryption.html">Storage encryption</a></li>
-      <li><a href="formatcaps.html">Capabilities</a></li>
-      <li><a href="formatdomaincaps.html">Domain capabilities</a></li>
-      <li><a href="formatstoragecaps.html">Storage Pool capabilities</a></li>
-      <li><a href="formatnode.html">Node devices</a></li>
-      <li><a href="formatsecret.html">Secrets</a></li>
-      <li><a href="formatsnapshot.html">Snapshots</a></li>
-      <li><a href="formatcheckpoint.html">Checkpoints</a></li>
-      <li><a href="formatbackup.html">Backup jobs</a></li>
-    </ul>
-
-    <h2>Command line validation</h2>
-
-    <p>
-      The <code>virt-xml-validate</code> tool provides a simple command line
-      for validating XML documents prior to giving them to libvirt. It uses
-      the locally instaled RNG schema documents. It will auto-detect which
-      schema to use for validation based on the name of the top level element
-      in the input document. Thus it merely requires the XML document filename
-      to be passed on the command line
-    </p>
-
-    <pre>
-$ virt-xml-validate /path/to/XML/file</pre>
-
-  </body>
-</html>

docs/formatbackup.html.in

@@ -1,175 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Backup XML format</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="BackupAttributes">Backup XML</a></h2>
-
-    <p>
-      Creating a backup, whether full or incremental, is done
-      via <code>virDomainBackupBegin()</code>, which takes an XML
-      description of the actions to perform, as well as an optional
-      second XML document <a href="formatcheckpoint.html">describing a
-      checkpoint</a> to create at the same point in time. See
-      also <a href="domainstatecapture.html">a comparison</a> between
-      the various state capture APIs.
-    </p>
-    <p>
-      There are two general modes for backups: a push mode (where the
-      hypervisor writes out the data to the destination file, which
-      may be local or remote), and a pull mode (where the hypervisor
-      creates an NBD server that a third-party client can then read as
-      needed, and which requires the use of temporary storage,
-      typically local, until the backup is complete).
-    </p>
-    <p>
-      The instructions for beginning a backup job are provided as
-      attributes and elements of the
-      top-level <code>domainbackup</code> element. This element
-      includes an optional attribute <code>mode</code> which can be
-      either "push" or "pull" (default
-      push). <code>virDomainBackupGetXMLDesc()</code> can be used to
-      see the actual values selected for elements omitted during
-      creation (for example, learning which port the NBD server is
-      using in the pull model or what file names libvirt generated
-      when none were supplied). The following child elements and attributes
-      are supported:
-    </p>
-    <dl>
-      <dt><code>incremental</code></dt>
-      <dd>An optional element giving the name of an existing
-        checkpoint of the domain, which will be used to make this
-        backup an incremental one. In the push model, only changes
-        since the named checkpoint are written to the destination. In
-        the pull model, the NBD server uses the
-        NBD_OPT_SET_META_CONTEXT extension to advertise to the client
-        which portions of the export contain changes since the named
-        checkpoint. If omitted, a full backup is performed.
-      </dd>
-      <dt><code>server</code></dt>
-      <dd>Present only for a pull mode backup. Contains the same
-        attributes as
-        the <a href="formatdomain.html#elementsDisks"><code>protocol</code>
-        element of a disk</a> attached via NBD in the domain (such as
-        transport, socket, name, port, or tls), necessary to set up an
-        NBD server that exposes the content of each disk at the time
-        the backup is started.
-      </dd>
-      <dt><code>disks</code></dt>
-      <dd>An optional listing of instructions for disks participating
-        in the backup (if omitted, all disks participate and libvirt
-        attempts to generate filenames by appending the current
-        timestamp as a suffix). If the entire element was omitted on
-        input, then all disks participate in the backup, otherwise,
-        only the disks explicitly listed which do not also
-        use <code>backup='no'</code> will participate. On output, this
-        is the state of each of the domain's disk in relation to the
-        backup operation.
-        <dl>
-          <dt><code>disk</code></dt>
-          <dd>This sub-element describes the backup properties of a
-            specific disk, with the following attributes and child
-            elements:
-            <dl>
-              <dt><code>name</code></dt>
-              <dd>A mandatory attribute which must match
-                the <code>&lt;target dev='name'/&gt;</code>
-                of one of
-                the <a href="formatdomain.html#elementsDisks">disk
-                devices</a> specified for the domain at the time of
-                the checkpoint.</dd>
-              <dt><code>backup</code></dt>
-              <dd>Setting this attribute to <code>yes</code>(default) specifies
-                that the disk should take part in the backup and using
-                <code>no</code> excludes the disk from the backup.</dd>
-              <dt><code>type</code></dt>
-              <dd>A mandatory attribute to describe the type of the
-                disk, except when <code>backup='no'</code> is
-                used. Valid values include <code>file</code>,
-                <code>block</code>, or <code>network</code>.
-                Similar to a disk declaration for a domain, the choice of type
-                controls what additional sub-elements are needed to describe
-                the destination (such as <code>protocol</code> for a
-                network destination).</dd>
-              <dt><code>target</code></dt>
-              <dd>Valid only for push mode backups, this is the
-                primary sub-element that describes the file name of
-                the backup destination, similar to
-                the <code>source</code> sub-element of a domain
-                disk. An optional sub-element <code>driver</code> can
-                also be used, with an attribute <code>type</code> to
-                specify a destination format different from
-                qcow2. </dd>
-              <dt><code>scratch</code></dt>
-              <dd>Valid only for pull mode backups, this is the
-                primary sub-element that describes the file name of
-                the local scratch file to be used in facilitating the
-                backup, and is similar to the <code>source</code>
-                sub-element of a domain disk. Currently only <code>file</code>
-                and <code>block</code> scratch storage is supported. The
-                <code>file</code> scratch file is created and deleted by
-                libvirt in the given location. A <code>block</code> scratch
-                device must exist prior to starting the backup and is formatted.
-                The block device must have enough space for the corresponding
-                disk data including format overhead.
-
-                If <code>VIR_DOMAIN_BACKUP_BEGIN_REUSE_EXTERNAL</code> flag is
-                used the file for a scratch of <code>file</code> type must
-                exist with the correct format and size to hold the copy and is
-                used without modification. The file is not deleted after the
-                backup but the contents of the file don't make sense outside
-                of the backup. The same applies for the block device which
-                must be formatted appropriately.</dd>
-            </dl>
-          </dd>
-        </dl>
-      </dd>
-    </dl>
-
-    <h2><a id="example">Examples</a></h2>
-
-    <p>Use <code>virDomainBackupBegin()</code> to perform a full
-      backup using push mode. The example lets libvirt pick the
-      destination and format for 'vda', fully specifies that we want a
-      raw backup of 'vdb', and omits 'vdc' from the operation.
-    </p>
-    <pre>
-&lt;domainbackup&gt;
-  &lt;disks&gt;
-    &lt;disk name='vda' backup='yes'/&gt;
-    &lt;disk name='vdb' type='file'&gt;
-      &lt;target file='/path/to/vdb.backup'/&gt;
-      &lt;driver type='raw'/&gt;
-    &lt;/disk&gt;
-    &lt;disk name='vdc' backup='no'/&gt;
-  &lt;/disks&gt;
-&lt;/domainbackup&gt;
-    </pre>
-
-    <p>If the previous full backup also passed a parameter describing
-      <a href="formatcheckpoint.html">checkpoint XML</a> that resulted
-      in a checkpoint named <code>1525889631</code>, we can make
-      another call to <code>virDomainBackupBegin()</code> to perform
-      an incremental backup of just the data changed since that
-      checkpoint, this time using the following XML to start a pull
-      model export of the 'vda' and 'vdb' disks, where a third-party
-      NBD client connecting to '/path/to/server' completes the backup
-      (omitting 'vdc' from the explicit list has the same effect as
-      the backup='no' from the previous example):
-    </p>
-    <pre>
-&lt;domainbackup mode="pull"&gt;
-  &lt;incremental&gt;1525889631&lt;/incremental&gt;
-  &lt;server transport="unix" socket="/path/to/server"/&gt;
-  &lt;disks&gt;
-    &lt;disk name='vda' backup='yes' type='file'&gt;
-      &lt;scratch file='/path/to/file1.scratch'/&gt;
-    &lt;/disk&gt;
-  &lt;/disks&gt;
-&lt;/domainbackup&gt;
-    </pre>
-  </body>
-</html>

docs/formatcaps.html.in

@@ -1,219 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Driver capabilities XML format</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="elements">Element and attribute overview</a></h2>
-
-    <p>As new virtualization engine support gets added to libvirt, and to
-    handle cases like QEMU supporting a variety of emulations, a query
-    interface has been added in 0.2.1 allowing to list the set of supported
-    virtualization capabilities on the host:</p>
-
-    <pre>char * virConnectGetCapabilities (virConnectPtr conn);</pre>
-
-    <p>The value returned is an XML document listing the virtualization
-    capabilities of the host and virtualization engine to which
-    <code>@conn</code> is connected. One can test it using <code>virsh</code>
-    command line tool command '<code>capabilities</code>', it dumps the XML
-    associated to the current connection. </p>
-
-    <p>As can be seen in the <a href="#elementExamples">example</a>, the
-    capabilities XML consists of the <code>capabilities</code> element which
-    have exactly one <code>host</code> child element to report information on
-    host capabilities, and zero or more <code>guest</code> element to express
-    the set of architectures the host can run at the moment.</p>
-
-
-    <h3><a id="elementHost">Host capabilities</a></h3>
-
-    <p>The <code>&lt;host/&gt;</code> element consists of the following child
-    elements:</p>
-    <dl>
-      <dt><code>uuid</code></dt>
-      <dd>The host UUID.</dd>
-
-      <dt><code>cpu</code></dt>
-      <dd>The host CPU architecture and features.</dd>
-
-      <dt><code>power_management</code></dt>
-      <dd>whether host is capable of memory suspend, disk hibernation, or
-      hybrid suspend.</dd>
-
-      <dt><code>migration</code></dt>
-      <dd>This element exposes information on the hypervisor's migration
-      capabilities, like live migration, supported URI transports, and so
-      on.</dd>
-
-      <dt><code>topology</code></dt>
-      <dd>This element embodies the host internal topology. Management
-      applications may want to learn this information when orchestrating new
-      guests - e.g. due to reduce inter-NUMA node transfers.</dd>
-
-      <dt><code>secmodel</code></dt>
-      <dd>To find out default security labels for different security models you
-      need to parse this element. In contrast with the former elements, this is
-      repeated for each security model the libvirt daemon currently supports.
-      </dd>
-    </dl>
-
-
-    <h3><a id="elementGuest">Guest capabilities</a></h3>
-
-    <p>While the <a href="#elementHost">previous section</a> aims at host
-    capabilities, this one focuses on capabilities available to a guest
-    using a given hypervisor. The <code>&lt;guest/&gt;</code> element will
-    typically wrap up the following elements:</p>
-
-    <dl>
-        <dt><code>os_type</code></dt>
-        <dd>This expresses what kind of operating system the hypervisor
-        is able to run. Possible values are:
-        <dl>
-          <dt><code>xen</code></dt>
-          <dd>for XEN PV</dd>
-
-          <dt><code>linux</code></dt>
-          <dd>legacy alias for <code>xen</code></dd>
-
-          <dt><code>xenpvh</code></dt>
-          <dd>for XEN PVH</dd>
-
-          <dt><code>hvm</code></dt>
-          <dd>Unmodified operating system</dd>
-
-          <dt><code>exe</code></dt>
-          <dd>Container based virtualization</dd>
-        </dl>
-        </dd>
-
-        <dt><code>arch</code></dt>
-        <dd>This element brings some information on supported guest
-          architecture. Possible subelements are:
-          <dl>
-            <dt><code>wordsize</code></dt><dd>Size of CPU word in bits, for example 64.</dd>
-            <dt><code>emulator</code></dt><dd>Emulator (device model) path, for
-              use in <a href="formatdomain.html#elementEmulator">emulator</a>
-              element of domain XML.</dd>
-            <dt><code>loader</code></dt><dd>Loader path, for use in
-              <a href="formatdomain.html#elementLoader">loader</a> element of domain
-              XML.</dd>
-            <dt><code>machine</code></dt><dd>Machine type, for use in
-              <a href="formatdomain.html#attributeOSTypeMachine">machine</a>
-              attribute of os/type element in domain XML. For example Xen
-              supports <code>xenfv</code> for HVM, <code>xenpv</code> for
-              PV, or <code>xenpvh</code> for PVH.</dd>
-            <dt><code>domain</code></dt><dd>The <code>type</code> attribute of
-              this element specifies the type of hypervisor required to run the
-              domain. Use in <a href="formatdomain.html#attributeDomainType">type</a>
-              attribute of the domain root element.</dd>
-          </dl>
-        </dd>
-
-        <dt><code>features</code></dt>
-        <dd>This optional element encases possible features that can be used
-          with a guest of described type.  Possible subelements are:
-          <dl>
-            <dt><code>pae</code></dt><dd>If present, 32-bit guests can use PAE
-              address space extensions, <span class="since">since
-              0.4.1</span></dd>
-            <dt><code>nonpae</code></dt><dd>If present, 32-bit guests can be run
-              without requiring PAE, <span class="since">since
-              0.4.1</span></dd>
-            <dt><code>ia64_be</code></dt><dd>If present, IA64 guests can be run in
-              big-endian mode, <span class="since">since 0.4.1</span></dd>
-            <dt><code>acpi</code></dt><dd>If this element is present,
-              the <code>default</code> attribute describes whether the
-              hypervisor exposes ACPI to the guest by default, and
-              the <code>toggle</code> attribute describes whether the
-              user can override this
-              default. <span class="since">Since 0.4.1</span></dd>
-            <dt><code>apic</code></dt><dd>If this element is present,
-              the <code>default</code> attribute describes whether the
-              hypervisor exposes APIC to the guest by default, and
-              the <code>toggle</code> attribute describes whether the
-              user can override this
-              default. <span class="since">Since 0.4.1</span></dd>
-            <dt><code>cpuselection</code></dt><dd>If this element is present, the
-              hypervisor supports the <code>&lt;cpu&gt;</code> element
-              within a domain definition for fine-grained control over
-              the CPU presented to the
-              guest. <span class="since">Since 0.7.5</span></dd>
-            <dt><code>deviceboot</code></dt><dd>If this element is present,
-              the <code>&lt;boot order='...'/&gt;</code> element can
-              be used inside devices, rather than the older boot
-              specification by category. <span class="since">Since
-              0.8.8</span></dd>
-            <dt><code>disksnapshot</code></dt><dd>If this element is present,
-              the <code>default</code> attribute describes whether
-              external disk snapshots are supported.  If absent,
-              external snapshots may still be supported, but it
-              requires attempting the API and checking for an error to
-              find out for sure. <span class="since">Since
-              1.2.3</span></dd>
-          </dl>
-        </dd>
-    </dl>
-
-    <h3><a id="elementExamples">Examples</a></h3>
-
-    <p>For example, in the case of a 64-bit machine with hardware
-    virtualization capabilities enabled in the chip and
-    BIOS you will see:</p>
-
-    <pre>&lt;capabilities&gt;
-  <span style="color: #E50000">&lt;host&gt;
-    &lt;cpu&gt;
-      &lt;arch&gt;x86_64&lt;/arch&gt;
-      &lt;features&gt;
-        &lt;vmx/&gt;
-      &lt;/features&gt;
-      &lt;model&gt;core2duo&lt;/model&gt;
-      &lt;vendor&gt;Intel&lt;/vendor&gt;
-      &lt;topology sockets="1" cores="2" threads="1"/&gt;
-      &lt;feature name="lahf_lm"/&gt;
-      &lt;feature name='xtpr'/&gt;
-      ...
-    &lt;/cpu&gt;
-    &lt;power_management&gt;
-      &lt;suspend_mem/&gt;
-      &lt;suspend_disk/&gt;
-      &lt;suspend_hybrid/&gt;
-    &lt;/power_management&gt;
-  &lt;/host&gt;</span>
-
-  &lt;!-- xen-3.0-x86_64 --&gt;
-  <span style="color: #0000E5">&lt;guest&gt;
-    &lt;os_type&gt;xen&lt;/os_type&gt;
-    &lt;arch name="x86_64"&gt;
-      &lt;wordsize&gt;64&lt;/wordsize&gt;
-      &lt;domain type="xen"&gt;&lt;/domain&gt;
-      &lt;emulator&gt;/usr/lib64/xen/bin/qemu-dm&lt;/emulator&gt;
-    &lt;/arch&gt;
-    &lt;features&gt;
-    &lt;/features&gt;
-  &lt;/guest&gt;</span>
-
-  &lt;!-- hvm-3.0-x86_32 --&gt;
-  <span style="color: #00B200">&lt;guest&gt;
-    &lt;os_type&gt;hvm&lt;/os_type&gt;
-    &lt;arch name="i686"&gt;
-      &lt;wordsize&gt;32&lt;/wordsize&gt;
-      &lt;domain type="xen"&gt;&lt;/domain&gt;
-      &lt;emulator&gt;/usr/lib/xen/bin/qemu-dm&lt;/emulator&gt;
-      &lt;machine&gt;pc&lt;/machine&gt;
-      &lt;machine&gt;isapc&lt;/machine&gt;
-      &lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
-    &lt;/arch&gt;
-    &lt;features&gt;
-      &lt;cpuselection/&gt;
-      &lt;deviceboot/&gt;
-    &lt;/features&gt;
-  &lt;/guest&gt;</span>
-  ...
-&lt;/capabilities&gt;</pre>
-  </body>
-</html>