qemu: Let empty default VNC password work as documented

CVE-2016-5008 Setting an empty graphics password is documented as a way to disable VNC/SPICE access, but QEMU does not always behaves like that. VNC would happily accept the empty password. Let's enforce the behavior by setting password expiration to "now". https://bugzilla.redhat.com/show_bug.cgi?id=1180092 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> (cherry picked from commit bb848feec0) (cherry picked from commit d933f68ee6)
2025-09-19 01:44:56 +03:00 · 2016-07-04 10:13:23 +01:00
4980 changed files with 1424371 additions and 1973949 deletions
--- a/.ctags
+++ b/.ctags
@@ -1,5 +0,0 @@
--recurse
--exclude=*.orig
--exclude=*.html
--exclude=*.html.in
--langmap=c:+.h.in
--- a/.gitignore
+++ b/.gitignore
@@ -3,7 +3,6 @@
 *.a
 *.cov
 *.exe
-*.exe.manifest
 *.gcda
 *.gcno
 *.gcov
@@ -14,15 +13,12 @@
 *.loT
 *.o
 *.orig
-*.pem
 *.pyc
 *.rej
 *.s
-*.swp
 *~
 .#*
 .deps
-.dirstamp
 .gdb_history
 .git
 .git-module-status
@@ -32,6 +28,7 @@
 .sc-start-sc_*
 /ABOUT-NLS
 /AUTHORS
+/COPYING
 /ChangeLog
 /GNUmakefile
 /INSTALL
@@ -41,7 +38,6 @@
 /build-aux
 /build-aux/
 /build/
-/confdefs.h
 /config.cache
 /config.guess
 /config.h
@@ -52,7 +48,6 @@
 /config.sub
 /configure
 /configure.lineno
-/conftest.*
 /daemon/*_dispatch.h
 /daemon/libvirt_qemud
 /daemon/libvirtd
@@ -63,24 +58,18 @@
 /daemon/libvirtd.pod
 /daemon/libvirtd.policy
 /daemon/libvirtd.service
-/daemon/libvirtd.socket
 /daemon/test_libvirtd.aug
-/docs/aclperms.htmlinc
 /docs/apibuild.py.stamp
 /docs/devhelp/libvirt.devhelp
 /docs/hvsupport.html.in
-/docs/libvirt-admin-*.xml
 /docs/libvirt-api.xml
-/docs/libvirt-lxc-*.xml
 /docs/libvirt-qemu-*.xml
 /docs/libvirt-refs.xml
 /docs/search.php
 /docs/todo.html.in
-/examples/object-events/event-test
+/examples/domain-events/events-c/event-test
 /examples/dominfo/info1
 /examples/domsuspend/suspend
-/examples/dommigrate/dommigrate
-/examples/domtop/domtop
 /examples/hellolibvirt/hellolibvirt
 /examples/openauth/openauth
 /gnulib/lib/*
@@ -90,7 +79,7 @@
 /libtool
 /libvirt-*.tar.gz
 /libvirt-[0-9]*
-/libvirt*.pc
+/libvirt.pc
 /libvirt.spec
 /ltconfig
 /ltmain.sh
@@ -100,37 +89,25 @@
 /mkinstalldirs
 /po/*
 /proxy/
-/python/
+/python/generated.stamp
+/python/generator.py.stamp
+/python/libvirt-export.c
+/python/libvirt-qemu-export.c
+/python/libvirt-qemu.[ch]
+/python/libvirt.[ch]
+/python/libvirt.py
+/python/libvirt_qemu.py
 /run
 /sc_*
 /src/.*.stamp
-/src/*.pc
-/src/access/org.libvirt.api.policy
-/src/access/viraccessapicheck.c
-/src/access/viraccessapicheck.h
-/src/access/viraccessapichecklxc.c
-/src/access/viraccessapichecklxc.h
-/src/access/viraccessapicheckqemu.c
-/src/access/viraccessapicheckqemu.h
-/src/admin/admin_client.h
-/src/admin/admin_protocol.[ch]
 /src/esx/*.generated.*
 /src/hyperv/*.generated.*
 /src/libvirt*.def
 /src/libvirt.syms
-/src/libvirt_access.syms
-/src/libvirt_access.xml
-/src/libvirt_access_lxc.syms
-/src/libvirt_access_lxc.xml
-/src/libvirt_access_qemu.syms
-/src/libvirt_access_qemu.xml
-/src/libvirt_admin.syms
 /src/libvirt_*.stp
 /src/libvirt_*helper
 /src/libvirt_*probes.h
 /src/libvirt_lxc
-/src/locking/libxl-lockd.conf
-/src/locking/libxl-sanlock.conf
 /src/locking/lock_daemon_dispatch_stubs.h
 /src/locking/lock_protocol.[ch]
 /src/locking/qemu-lockd.conf
@@ -138,9 +115,8 @@
 /src/locking/test_libvirt_sanlock.aug
 /src/lxc/lxc_controller_dispatch.h
 /src/lxc/lxc_monitor_dispatch.h
-/src/lxc/lxc_monitor_protocol.c
-/src/lxc/lxc_monitor_protocol.h
-/src/lxc/lxc_protocol.[ch]
+/src/lxc/lxc_protocol.c
+/src/lxc/lxc_protocol.h
 /src/lxc/test_libvirtd_lxc.aug
 /src/qemu/test_libvirtd_qemu.aug
 /src/remote/*_client_bodies.h
@@ -148,41 +124,72 @@
 /src/rpc/virkeepaliveprotocol.[ch]
 /src/rpc/virnetprotocol.[ch]
 /src/test_libvirt*.aug
-/src/test_virtlockd.aug
 /src/util/virkeymaps.h
 /src/virt-aa-helper
 /src/virtlockd
-/src/virtlockd.8
-/src/virtlockd.8.in
 /src/virtlockd.init
 /tests/*.log
 /tests/*.pid
-/tests/*.trs
+/tests/*xml2*test
 /tests/commandhelper
-/tests/*test
-!/tests/*schematest
-!/tests/virt-aa-helper-test
-/tests/objectlocking
-/tests/objectlocking-files.txt
-/tests/objectlocking.cm[ix]
+/tests/commandtest
+/tests/conftest
+/tests/cputest
+/tests/domainsnapshotxml2xmltest
+/tests/esxutilstest
+/tests/eventtest
+/tests/hashtest
+/tests/jsontest
+/tests/libvirtdconftest
+/tests/networkxml2argvtest
+/tests/nodeinfotest
+/tests/nwfilterxml2xmltest
+/tests/object-locking
+/tests/object-locking-files.txt
+/tests/object-locking.cm[ix]
+/tests/openvzutilstest
+/tests/qemuargv2xmltest
+/tests/qemuhelptest
+/tests/qemumonitorjsontest
+/tests/qemumonitortest
+/tests/qemuxmlnstest
+/tests/qparamtest
 /tests/reconnect
+/tests/secaatest
+/tests/seclabeltest
+/tests/securityselinuxtest
+/tests/sexpr2xmltest
+/tests/shunloadtest
+/tests/sockettest
 /tests/ssh
-/tests/test_conf
+/tests/statstest
+/tests/storagebackendsheepdogtest
+/tests/utiltest
+/tests/viratomictest
+/tests/virauthconfigtest
+/tests/virbitmaptest
+/tests/virbuftest
+/tests/virdrivermoduletest
+/tests/virhashtest
+/tests/virkeyfiletest
+/tests/virlockspacetest
+/tests/virnet*test
+/tests/virshtest
+/tests/virstringtest
+/tests/virtimetest
+/tests/viruritest
+/tests/vmx2xmltest
+/tests/xencapstest
+/tests/xmconfigtest
 /tools/*.[18]
 /tools/libvirt-guests.init
 /tools/libvirt-guests.service
 /tools/libvirt-guests.sh
-/tools/virt-login-shell
 /tools/virsh
 /tools/virsh-*-edit.c
 /tools/virt-*-validate
 /tools/virt-sanlock-cleanup
-/tools/wireshark/src/plugin.c
-/tools/wireshark/src/libvirt
 /update.log
-GPATH
-GRTAGS
-GTAGS
 Makefile
 Makefile.in
 TAGS
--- a/.gnulib
+++ b/.gnulib
--- a/.mailmap
+++ b/.mailmap
@@ -5,10 +5,7 @@

 <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>
@@ -59,5 +56,3 @@ Philipp Hahn <hahn@univention.de>
 Marco Bozzolan <bozzolan@gmail.com>
 Marco Bozzolan <redshift@gmx.com>
 Pritesh Kothari <pritesh.kothari@sun.com>
-Wang Yufei (James) <james.wangyufei@huawei.com>
-Deepak C Shetty <dpkshetty@gmail.com>
--- a/AUTHORS.in
+++ b/AUTHORS.in
@@ -8,48 +8,38 @@ Daniel Veillard <veillard@redhat.com> or <daniel@veillard.com>
 The primary maintainers and people with commit access rights:

 Alex Jia <ajia@redhat.com>
-Cédric Bosdonnat <cbosdonnat@suse.com>
+Anthony Liguori <aliguori@us.ibm.com>
+Chris Lalancette <clalance@redhat.com>
 Christophe Fergeau <cfergeau@redhat.com>
-Claudio Bley <claudio.bley@gmail.com>
 Cole Robinson <crobinso@redhat.com>
 Daniel Berrange <berrange@redhat.com>
 Daniel Veillard <veillard@redhat.com>
-Dmitry Guryanov <dguryanov@parallels.com>
+Dave Allan <dallan@redhat.com>
 Doug Goldstein <cardoe@gentoo.org>
 Eric Blake <eblake@redhat.com>
-Erik Skultety <eskultet@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>
+Jim Meyering <meyering@redhat.com>
 Jiří Denemark <jdenemar@redhat.com>
-John Ferlan <jferlan@redhat.com>
+John Levon <john.levon@sun.com>
+Justin Clift <jclift@redhat.com>
 Laine Stump <laine@redhat.com>
 Mark McLoughlin <markmc@redhat.com>
 Martin Kletzander <mkletzan@redhat.com>
 Matthias Bolte <matthias.bolte@googlemail.com>
 Michal Prívozník <mprivozn@redhat.com>
-Pavel Hrdina <phrdina@redhat.com>
+Osier Yang <jyang@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>
-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:

--- a/339
+++ b/339
@@ -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.
--- a/COPYING.LESSER
+++ b/COPYING.LESSER
@@ -1,8 +1,9 @@
+
                  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
+     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

@@ -22,7 +23,8 @@ 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.
+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
@@ -55,7 +57,7 @@ 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.
-
+^L
  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
@@ -87,9 +89,9 @@ 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
+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.
@@ -111,7 +113,7 @@ 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.
-
+^L
                  GNU LESSER GENERAL PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

@@ -136,8 +138,8 @@ 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.
+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
@@ -216,7 +218,7 @@ 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.
-
+^L
  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.
@@ -267,7 +269,7 @@ Library will still fall under Section 6.)
 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.
-
+^L
  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
@@ -303,10 +305,10 @@ of these things:
    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.
+    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
@@ -329,7 +331,7 @@ 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.
-
+^L
  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
@@ -370,7 +372,7 @@ 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.
-
+^L
  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
@@ -384,9 +386,10 @@ 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.
+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
@@ -404,11 +407,11 @@ 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.
+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.
@@ -422,7 +425,7 @@ 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.
-
+^L
  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
@@ -456,19 +459,21 @@ SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
 DAMAGES.

                     END OF TERMS AND CONDITIONS
-
+^L
           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).
+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.

-  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>
@@ -485,16 +490,17 @@ convey the exclusion of warranty; and each file should have at least the

    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
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  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:
+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.
+  library `Frob' (a library for tweaking knobs) written by James
+  Random Hacker.

  <signature of Ty Coon>, 1 April 1990
  Ty Coon, President of Vice
--- a/14
+++ b/14
@@ -4286,7 +4286,7 @@ Wed Dec 17 21:45:39 GMT 2008 Daniel P. Berrange <berrange@redhat.com>

 Wed Dec 17 21:41:39 GMT 2008 Daniel P. Berrange <berrange@redhat.com>

-	* src/libvirt_sym.version.in: Remove non-existent symbols
+	* src/libvirt_sym.version.in: Remove non-existant symbols
 	(John Levon)

 Wed Dec 17 21:35:39 GMT 2008 Daniel P. Berrange <berrange@redhat.com>
@@ -5504,7 +5504,7 @@ Tue Nov 11 15:51:42 GMT 2008 Daniel P. Berrange <berrange@redhat.com>

 Mon Nov 10 12:05:42 GMT 2008 Daniel P. Berrange <berrange@redhat.com>

-	* src/openvz_conf.c: Read filesystem template name from config
+	* src/openvz_conf.c: Read filesytem template name from config
 	files. Increase buffer size when parsing vzctl version number

 Thu Nov  6 20:45:42 CET 2008 Jim Meyering <meyering@redhat.com>
@@ -12415,7 +12415,7 @@ Thu Jul 12 11:02:17 EST 2007 Daniel P. Berrange <berrange@redhat.com>

 Thu Jul 12 11:00:17 EST 2007 Daniel P. Berrange <berrange@redhat.com>

-	* qemud/qemud.c: Add explicit checks for existence of x509
+	* qemud/qemud.c: Add explicit checks for existance of x509
 	certificate & key files to get better error reporting than
 	GNU TLS offers when it can't load a file

@@ -13276,7 +13276,7 @@ Tue Apr 17 11:30:46 CEST 2007 Daniel Veillard <veillard@redhat.com>

 Mon Apr 16 09:11:04 EST 2007 Daniel P. Berrange <berrange@redhat.com>

-	* qemud/conf.c: Check for existence of QEMU binary path. Fix check
+	* qemud/conf.c: Check for existance of QEMU binary path. Fix check
 	for -no-kqemu flag to work with x86_64 on i386

 Mon Apr 16 09:09:04 EST 2007 Daniel P. Berrange <berrange@redhat.com>
@@ -13920,7 +13920,7 @@ Tue Feb 27 10:20:43 EST 2007 Daniel P. Berrange <berrange@redhat.com>

 	* src/xend_internal.c: Only hardcode port = 5900+domid if
 	running against old XenD < 3.0.3, because in newer XenD
-	port is guaranteed to be available in XenStore if the VNC
+	port is guarenteed to be available in XenStore if the VNC
 	server is running.

 Mon Feb 26 15:33:08 IST 2007 Mark McLoughlin <markmc@redhat.com>
@@ -15020,7 +15020,7 @@ Tue Nov  7 16:33:43 CET 2006 Daniel Veillard <veillard@redhat.com>
 Tue Oct 31 10:31:34 CET 2006 Daniel Veillard <veillard@redhat.com>

 	* src/xend_internal.c: when getting informations about a non
-	  existent domain, it is not a good idea to raise the HTTP
+	  existant domain, it is not a good idea to raise the HTTP
 	  404 GET error, the handling is better done somewhere up in
 	  the stack.

@@ -15228,7 +15228,7 @@ Sun Sep  3 12:34:23 EDT 2006 Daniel Berrange <berrange@redhat.com>
 	iterating over list of ids/names, because it is not neccessarily
 	the same as the value returned by virConnectNumOfDomains. Use qsort
 	to sort active domains by Id, and inactive domains by name, since
-	there is no guaranteed sort ordering when listing domains. For inactive
+	there is no guarenteed sort ordering when listing domains. For inactive
 	domains display a '-' instead of '-1' to make it clear they have no
 	sensible ID number.

--- a/374
+++ b/374
@@ -14,21 +14,7 @@ General tips for contributing patches
 (1) Discuss any large changes on the mailing list first. Post patches early and
 listen to feedback.

-(2) Official upstream repository is kept in git ("git://libvirt.org/libvirt.git")
-and is browsable along with other libvirt-related repositories (e.g.
-libvirt-python) online <http://libvirt.org/git/>.
-
-(3) Patches to translations are maintained via the zanata project
-<https://fedora.zanata.org/>. If you want to fix a translation in a .po file,
-join the appropriate language team. The libvirt release process automatically
-pulls the latest version of each translation file from zanata.
-
-(4) Post patches in unified diff format, with git rename detection enabled. You
-need a one-time setup of:
-
-  git config diff.renames true
-
-After that, a command similar to this should work:
+(2) Post patches in unified diff format. A command similar to this should work:

  diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch

@@ -36,17 +22,14 @@ or:

  git diff > libvirt-myfeature.patch

-Also, for code motion patches, you may find that "git diff --patience"
-provides an easier-to-read patch. However, the usual workflow of libvirt
-developer is:
+However, the usual workflow of libvirt developer is:

  git checkout master
  git pull
  git checkout -t origin -b workbranch
  Hack, committing any changes along the way

-More hints on compiling can be found here <compiling.html>. When you want to
-post your patches:
+Then, when you want to post your patches:

  git pull --rebase
  (fix any conflicts)
@@ -54,7 +37,7 @@ post your patches:
                 --to=libvir-list@redhat.com master

 (Note that the "git send-email" subcommand may not be in the main git package
-and using it may require installation of a separate package, for example the
+and using it may require installion of a separate package, for example the
 "git-email" package in Fedora.) For a single patch you can omit
 "--cover-letter", but a series of two or more patches needs a cover letter. If
 you get tired of typing "--to=libvir-list@redhat.com" designation you can set
@@ -66,28 +49,16 @@ Please follow this as close as you can, especially the rebase and git
 send-email part, as it makes life easier for other developers to review your
 patch set. One should avoid sending patches as attachments, but rather send
 them in email body along with commit message. If a developer is sending
-another version of the patch (e.g. to address review comments), they are
-advised to note differences to previous versions after the "---" line in the
-patch so that it helps reviewers but doesn't become part of git history.
-Moreover, such patch needs to be prefixed correctly with
-"--subject-prefix=PATCHv2" appended to "git send-email" (substitute "v2" with
-the correct version if needed though).
+another version of the patch (e.g. to address review comments), he is advised
+to note differences to previous versions after the "---" line in the patch so
+that it helps reviewers but doesn't become part of git history. Moreover, such
+patch needs to be prefixed correctly with "--subject-prefix=PATCHv2" appended
+to "git send-email" (substitute "v2" with the correct version if needed
+though).



-(5) In your commit message, make the summary line reasonably short (60 characters
-is typical), followed by a blank line, followed by any longer description of
-why your patch makes sense. If the patch fixes a regression, and you know what
-commit introduced the problem, mentioning that is useful. If the patch
-resolves a bugzilla report, mentioning the URL of the bug number is useful;
-but also summarize the issue rather than making all readers follow the link.
-You can use 'git shortlog -30' to get an idea of typical summary lines.
-Libvirt does not currently attach any meaning to Signed-off-by: lines, so it
-is up to you if you want to include or omit them in the commit message.
-
-
-
-(6) Split large changes into a series of smaller patches, self-contained if
+(3) Split large changes into a series of smaller patches, self-contained if
 possible, with an explanation of each patch and an explanation of how the
 sequence of patches fits together. Moreover, please keep in mind that it's
 required to be able to compile cleanly (*including* "make check" and "make
@@ -98,10 +69,10 @@ things).



-(7) Make sure your patches apply against libvirt GIT. Developers only follow GIT
+(4) Make sure your patches apply against libvirt GIT. Developers only follow GIT
 and don't care much about released versions.

-(8) Run the automated tests on your code before submitting any changes. In
+(5) Run the automated tests on your code before submitting any changes. In
 particular, configure with compile warnings set to -Werror. This is done
 automatically for a git checkout; from a tarball, use:

@@ -113,17 +84,7 @@ and run the tests:
  make syntax-check
  make -C tests valgrind

-Valgrind <http://valgrind.org/> is a test that checks for memory management
-issues, such as leaks or use of uninitialized variables.
-
-Some tests are skipped by default in a development environment, based on the
-time they take in comparison to the likelihood that those tests will turn up
-problems during incremental builds. These tests default to being run when
-building from a tarball or with the configure option --enable-expensive-tests;
-you can also force a one-time toggle of these tests by setting
-VIR_TEST_EXPENSIVE to 0 or 1 at make time, as in:
-
-  make check VIR_TEST_EXPENSIVE=1
+The latter test checks for memory leaks.

 If you encounter any failing tests, the VIR_TEST_DEBUG environment variable
 may provide extra information to debug the failures. Larger values of
@@ -132,112 +93,20 @@ VIR_TEST_DEBUG may provide larger amounts of information:
  VIR_TEST_DEBUG=1 make check    (or)
  VIR_TEST_DEBUG=2 make check

-When debugging failures during development, it is possible to focus in on just
-the failing subtests by using TESTS and VIR_TEST_RANGE:
-
-  make check VIR_TEST_DEBUG=1 VIR_TEST_RANGE=3-5 TESTS=qemuxml2argvtest
-
 Also, individual tests can be run from inside the "tests/" directory, like:

  ./qemuxml2xmltest

-If you are adding new test cases, or making changes that alter existing test
-output, you can use the environment variable VIR_TEST_REGENERATE_OUTPUT to
-quickly update the saved test data. Of course you still need to review the
-changes VERY CAREFULLY to ensure they are correct.
-
-  VIR_TEST_REGENERATE_OUTPUT=1 ./qemuxml2argvtest
-
-There is also a "./run" script at the top level, to make it easier to run
-programs that have not yet been installed, as well as to wrap invocations of
-various tests under gdb or Valgrind.
-
-
-
-(9) The Valgrind test should produce similar output to "make check". If the output
-has traces within libvirt API's, then investigation is required in order to
-determine the cause of the issue. Output such as the following indicates some
-sort of leak:
-
-==5414== 4 bytes in 1 blocks are definitely lost in loss record 3 of 89
-==5414==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
-==5414==    by 0x34DE0AAB85: xmlStrndup (in /usr/lib64/libxml2.so.2.7.8)
-==5414==    by 0x4CC97A6: virDomainVideoDefParseXML (domain_conf.c:7410)
-==5414==    by 0x4CD581D: virDomainDefParseXML (domain_conf.c:10188)
-==5414==    by 0x4CD8C73: virDomainDefParseNode (domain_conf.c:10640)
-==5414==    by 0x4CD8DDB: virDomainDefParse (domain_conf.c:10590)
-==5414==    by 0x41CB1D: testCompareXMLToArgvHelper (qemuxml2argvtest.c:100)
-==5414==    by 0x41E20F: virtTestRun (testutils.c:161)
-==5414==    by 0x41C7CB: mymain (qemuxml2argvtest.c:866)
-==5414==    by 0x41E84A: virtTestMain (testutils.c:723)
-==5414==    by 0x34D9021734: (below main) (in /usr/lib64/libc-2.15.so)
-
-In this example, the "virDomainDefParseXML()" had an error path where the
-"virDomainVideoDefPtr video" pointer was not properly disposed. By simply
-adding a "virDomainVideoDefFree(video);" in the error path, the issue was
-resolved.
-
-Another common mistake is calling a printing function, such as "VIR_DEBUG()"
-without initializing a variable to be printed. The following example involved
-a call which could return an error, but not set variables passed by reference
-to the call. The solution was to initialize the variables prior to the call.
-
-==4749== Use of uninitialised value of size 8
-==4749==    at 0x34D904650B: _itoa_word (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x34D9049118: vfprintf (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x34D9108F60: __vasprintf_chk (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x4CAEEF7: virVasprintf (stdio2.h:199)
-==4749==    by 0x4C8A55E: virLogVMessage (virlog.c:814)
-==4749==    by 0x4C8AA96: virLogMessage (virlog.c:751)
-==4749==    by 0x4DA0056: virNetTLSContextCheckCertKeyUsage (virnettlscontext.c:225)
-==4749==    by 0x4DA06DB: virNetTLSContextCheckCert (virnettlscontext.c:439)
-==4749==    by 0x4DA1620: virNetTLSContextNew (virnettlscontext.c:562)
-==4749==    by 0x4DA26FC: virNetTLSContextNewServer (virnettlscontext.c:927)
-==4749==    by 0x409C39: testTLSContextInit (virnettlscontexttest.c:467)
-==4749==    by 0x40AB8F: virtTestRun (testutils.c:161)
-
-Valgrind will also find some false positives or code paths which cannot be
-resolved by making changes to the libvirt code. For these paths, it is
-possible to add a filter to avoid the errors. For example:
-
-==4643== 7 bytes in 1 blocks are possibly lost in loss record 4 of 20
-==4643==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
-==4643==    by 0x34D90853F1: strdup (in /usr/lib64/libc-2.15.so)
-==4643==    by 0x34EEC2C08A: ??? (in /usr/lib64/libnl.so.1.1)
-==4643==    by 0x34EEC15B81: ??? (in /usr/lib64/libnl.so.1.1)
-==4643==    by 0x34D8C0EE15: call_init.part.0 (in /usr/lib64/ld-2.15.so)
-==4643==    by 0x34D8C0EECF: _dl_init (in /usr/lib64/ld-2.15.so)
-==4643==    by 0x34D8C01569: ??? (in /usr/lib64/ld-2.15.so)
-
-
-In this instance, it is acceptable to modify the "tests/.valgrind.supp" file
-in order to add a suppression filter. The filter should be unique enough to
-not suppress real leaks, but it should be generic enough to cover multiple
-code paths. The format of the entry can be found in the documentation found at
-the Valgrind home page <http://valgrind.org/>. The following trace was added
-to "tests/.valgrind.supp" in order to suppress the warning:
-
-{
-    dlInitMemoryLeak1
-    Memcheck:Leak
-    fun:?alloc
-    ...
-    fun:call_init.part.0
-    fun:_dl_init
-    ...
-    obj:*/lib*/ld-2.*so*
-}
-
-
-
-(10) Update tests and/or documentation, particularly if you are adding a new
+(6) Update tests and/or documentation, particularly if you are adding a new
 feature or changing the output of a program.



 There is more on this subject, including lots of links to background reading
-on the subject, on Richard Jones' guide to working with open source projects
-<http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/>.
+on the subject, on
+
+  Richard Jones' guide to working with open source projects
+  http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/


 Code indentation
@@ -248,9 +117,22 @@ but we do prefer that contributed code be formatted similarly. In short, use
 spaces-not-TABs for indentation, use 4 spaces for each indentation level, and
 other than that, follow the K&R style.

-If you use Emacs, the project includes a file .dir-locals.el that sets up the
-preferred indentation. If you use vim, append the following to your ~/.vimrc
-file:
+If you use Emacs, add the following to one of one of your start-up files
+(e.g., ~/.emacs), to help ensure that you get indentation right:
+
+  ;;; When editing C sources in libvirt, use this style.
+  (defun libvirt-c-mode ()
+    "C mode with adjusted defaults for use with libvirt."
+    (interactive)
+    (c-set-style "K&R")
+    (setq indent-tabs-mode nil) ; indent using spaces, not TABs
+    (setq c-indent-level 4)
+    (setq c-basic-offset 4))
+  (add-hook 'c-mode-hook
+            '(lambda () (if (string-match "/libvirt" (buffer-file-name))
+                            (libvirt-c-mode))))
+
+If you use vim, append the following to your ~/.vimrc file:

  set nocompatible
  filetype on
@@ -260,7 +142,7 @@ file:
  set tabstop=8
  set shiftwidth=4
  set expandtab
-  set cinoptions=(0,:0,l1,t0,L3
+  set cinoptions=(0,:0,l1,t0
  filetype plugin indent on
  au FileType make setlocal noexpandtab
  au BufRead,BufNewFile *.am setlocal noexpandtab
@@ -300,106 +182,47 @@ declare them at the beginning of a scope, rather than immediately before use.
 Bracket spacing
 ===============
 The keywords "if", "for", "while", and "switch" must have a single space
-following them before the opening bracket. E.g.
+following them before the opening bracket. eg

      if(foo)   // Bad
      if (foo)  // Good

-Function implementations mustnothave any whitespace between the function name and the opening bracket. E.g.
+Function implementations mustnothave any whitespace between the function name and the opening bracket. eg

      int foo (int wizz)  // Bad
      int foo(int wizz)   // Good

-Function calls mustnothave any whitespace between the function name and the opening bracket. E.g.
+Function calls mustnothave any whitespace between the function name and the opening bracket. eg

      bar = foo (wizz);  // Bad
      bar = foo(wizz);   // Good

 Function typedefs mustnothave any whitespace between the closing bracket of the function name and
-opening bracket of the arg list. E.g.
+opening bracket of the arg list. eg

      typedef int (*foo) (int wizz);  // Bad
      typedef int (*foo)(int wizz);   // Good

 There must not be any whitespace immediately following any opening bracket, or
-immediately prior to any closing bracket. E.g.
+immediately prior to any closing bracket

      int foo( int wizz );  // Bad
      int foo(int wizz);    // Good


-Commas
-======
-Commas should always be followed by a space or end of line, and never have
-leading space; this is enforced during 'make syntax-check'.
-
-      call(a,b ,c);// Bad
-      call(a, b, c); // Good
-
-When declaring an enum or using a struct initializer that occupies more than
-one line, use a trailing comma. That way, future edits to extend the list only
-have to add a line, rather than modify an existing line to add the
-intermediate comma. Any sentinel enumerator value with a name ending in _LAST
-is exempt, since you would extend such an enum before the _LAST element.
-Another reason to favor trailing commas is that it requires less effort to
-produce via code generators. Note that the syntax checker is unable to enforce
-a style of trailing commas, so there are counterexamples in existing code
-which do not use it; also, while C99 allows trailing commas, remember that
-JSON and XDR do not.
-
-      enum {
-          VALUE_ONE,
-          VALUE_TWO // Bad
-      };
-      enum {
-          VALUE_THREE,
-          VALUE_FOUR, // Good
-      };
-
-
-Semicolons
-==========
-Semicolons should never have a space beforehand. Inside the condition of a
-"for" loop, there should always be a space or line break after each semicolon,
-except for the special case of an infinite loop (although more infinite loops
-use "while"). While not enforced, loop counters generally use post-increment.
-
-      for (i = 0 ;i < limit ; ++i) { // Bad
-      for (i = 0; i < limit; i++) { // Good
-      for (;;) { // ok
-      while (1) { // Better
-
-Empty loop bodies are better represented with curly braces and a comment,
-although use of a semicolon is not currently rejected.
-
-      while ((rc = waitpid(pid, &st, 0) == -1) &&
-             errno == EINTR); // ok
-      while ((rc = waitpid(pid, &st, 0) == -1) &&
-             errno == EINTR) { // Better
-          /* nothing */
-      }
-
-
 Curly braces
 ============
-Omit the curly braces around an "if", "while", "for" etc. body only when both
-that body and the condition itself occupy a single line. In every other case
-we require the braces. This ensures that it is trivially easy to identify a
-single-'statement' loop: each has only one 'line' in its body.
+Omit the curly braces around an "if", "while", "for" etc. body only when that
+body occupies a single line. In every other case we require the braces. This
+ensures that it is trivially easy to identify a single-'statement' loop: each
+has only one 'line' in its body.

-  while (expr)             // single line body; {} is forbidden
+Omitting braces with a single-line body is fine:
+
+  while (expr) // one-line body -> omitting curly braces is ok
      single_line_stmt();

-  while (expr(arg1,
-              arg2))      // indentation makes it obvious it is single line,
-      single_line_stmt(); // {} is optional (not enforced either way)
-
-  while (expr1 &&
-         expr2) {         // multi-line, at same indentation, {} required
-      single_line_stmt();
-  }
-
-However, the moment your loop/if/else body extends on to a second line, for
+However, the moment your loop/if/else body extends onto a second line, for
 whatever reason (even if it's just an added comment), then you should add
 braces. Otherwise, it would be too easy to insert a statement just before that
 comment (without adding braces), thinking it is already a multi-statement loop:
@@ -484,41 +307,9 @@ But if negating a complex condition is too ugly, then at least add braces:
      x = y;
  }

-Use hanging braces for compound statements: the opening brace of a compound
-statement should be on the same line as the condition being tested. Only
-top-level function bodies, nested scopes, and compound structure declarations
-should ever have { on a line by itself.
-
-  void
-  foo(int a, int b)
-  {                          // correct - function body
-      int 2d[][] = {
-        {                    // correct - complex initialization
-          1, 2,
-        },
-      };
-      if (a)
-      {                      // BAD: compound brace on its own line
-          do_stuff();
-      }
-      {                      // correct - nested scope
-          int tmp;
-          if (a < b) {       // correct - hanging brace
-              tmp = b;
-              b = a;
-              a = tmp;
-          }
-      }
-  }
-

 Preprocessor
 ============
-Macros defined with an ALL_CAPS name should generally be assumed to be unsafe
-with regards to arguments with side-effects (that is, MAX(a++, b--) might
-increment a or decrement b too many or too few times). Exceptions to this rule
-are explicitly documented for macros in viralloc.h and virstring.h.
-
 For variadic macros, stick with C99 syntax:

  #define vshPrint(_ctl, ...) fprintf(stdout, __VA_ARGS__)
@@ -527,7 +318,7 @@ Use parenthesis when checking if a macro is defined, and use indentation to
 track nesting:

  #if defined(HAVE_POSIX_FALLOCATE) && !defined(HAVE_FALLOCATE)
-  # define fallocate(a, ignored, b, c) posix_fallocate(a, b, c)
+  # define fallocate(a,ignored,b,c) posix_fallocate(a,b,c)
  #endif


@@ -602,14 +393,16 @@ Low level memory management
 Use of the malloc/free/realloc/calloc APIs is deprecated in the libvirt
 codebase, because they encourage a number of serious coding bugs and do not
 enable compile time verification of checks for NULL. Instead of these
-routines, use the macros from viralloc.h.
+routines, use the macros from memory.h.

 - To allocate a single object:

  virDomainPtr domain;

-  if (VIR_ALLOC(domain) < 0)
+  if (VIR_ALLOC(domain) < 0) {
+      virReportOOMError();
      return NULL;
+  }



@@ -618,8 +411,10 @@ routines, use the macros from viralloc.h.
  virDomainPtr domains;
  size_t ndomains = 10;

-  if (VIR_ALLOC_N(domains, ndomains) < 0)
+  if (VIR_ALLOC_N(domains, ndomains) < 0) {
+      virReportOOMError();
      return NULL;
+  }



@@ -628,8 +423,10 @@ routines, use the macros from viralloc.h.
  virDomainPtr *domains;
  size_t ndomains = 10;

-  if (VIR_ALLOC_N(domains, ndomains) < 0)
+  if (VIR_ALLOC_N(domains, ndomains) < 0) {
+      virReportOOMError();
      return NULL;
+  }



@@ -640,8 +437,10 @@ recommended only for smaller arrays):
  virDomainPtr domains;
  size_t ndomains = 0;

-  if (VIR_EXPAND_N(domains, ndomains, 1) < 0)
+  if (VIR_EXPAND_N(domains, ndomains, 1) < 0) {
+      virReportOOMError();
      return NULL;
+  }
  domains[ndomains - 1] = domain;


@@ -653,8 +452,10 @@ scales better, but requires tracking allocation separately from usage)
  size_t ndomains = 0;
  size_t ndomains_max = 0;

-  if (VIR_RESIZE_N(domains, ndomains_max, ndomains, 1) < 0)
+  if (VIR_RESIZE_N(domains, ndomains_max, ndomains, 1) < 0) {
+      virReportOOMError();
      return NULL;
+  }
  domains[ndomains++] = domain;


@@ -810,23 +611,12 @@ sizeof(dest) returns something meaningful). Note that this is a macro, so
 arguments could be evaluated more than once. This is equivalent to
 virStrncpy(dest, src, strlen(src), sizeof(dest)).

-  VIR_STRDUP(char *dst, const char *src);
-  VIR_STRNDUP(char *dst, const char *src, size_t n);
-
-You should avoid using strdup or strndup directly as they do not report
-out-of-memory error, and do not allow a NULL source. Use VIR_STRDUP or
-VIR_STRNDUP macros instead, which return 0 for NULL source, 1 for successful
-copy, and -1 for allocation failure with the error already reported. In very
-specific cases, when you don't want to report the out-of-memory error, you can
-use VIR_STRDUP_QUIET or VIR_STRNDUP_QUIET, but such usage is very rare and
-usually considered a flaw.
-

 Variable length string buffer
 =============================
 If there is a need for complex string concatenations, avoid using the usual
 sequence of malloc/strcpy/strcat/snprintf functions and make use of the
-virBuffer API described in virbuffer.h
+virBuffer API described in buf.h

 Typical usage is as follows:

@@ -844,8 +634,11 @@ Typical usage is as follows:

     ...

-     if (virBufferCheckError(&buf) < 0)
+     if (virBufferError(&buf)) {
+         virBufferFreeAndReset(&buf);
+         virReportOOMError();
         return NULL;
+     }

     return virBufferContentAndReset(&buf);
  }
@@ -871,7 +664,7 @@ stick to the following general plan for all *.c source files:
  #include <string.h>
  #include <limits.h>

-  #if WITH_NUMACTL                Some system includes aren't supported
+  #if HAVE_NUMACTL                Some system includes aren't supported
  # include <numa.h>              everywhere so need these #if guards.
  #endif

@@ -885,12 +678,9 @@ stick to the following general plan for all *.c source files:
  {
      ...

-Of particular note: *Do not* include libvirt/libvirt.h, libvirt/virterror.h,
-libvirt/libvirt-qemu.h, or libvirt/libvirt-lxc.h. They are included by
-"internal.h" already and there are some special reasons why you cannot include
-these files explicitly. One of the special cases, "libvirt/libvirt.h" is
-included prior to "internal.h" in "remote_protocol.x", to avoid exposing
-*_LAST enum elements.
+Of particular note: *Do not* include libvirt/libvirt.h or libvirt/virterror.h.
+It is included by "internal.h" already and there are some special reasons why
+you cannot include these files explicitly.


 Printf-style functions
@@ -953,7 +743,9 @@ logic would be better pulled out into a helper function.

 Although libvirt does not encourage the Linux kernel wind/unwind style of
 multiple labels, there's a good general discussion of the issue archived at
-KernelTrap <http://kerneltrap.org/node/553/2131>
+
+  KernelTrap
+  http://kerneltrap.org/node/553/2131

 When using goto, please use one of these standard labels if it makes sense:

@@ -962,16 +754,6 @@ When using goto, please use one of these standard labels if it makes sense:
  no_memory: A path only taken upon return with an OOM error code
      retry: If needing to jump upwards (e.g., retry on EINTR)

-Top-level labels should be indented by one space (putting them on the
-beginning of the line confuses function context detection in git):
-
-int foo()
-{
-    /* ... do stuff ... */
- cleanup:
-    /* ... do other stuff ... */
-}
-

 Libvirt committer guidelines
 ============================
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,56 +1,38 @@
 ## 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/>.
+## Copyright (C) 2005-2012 Red Hat, Inc.
+## See COPYING.LIB for the License of this software

 LCOV = lcov
 GENHTML = genhtml

-SUBDIRS = . gnulib/lib include src daemon tools docs gnulib/tests \
-  tests po examples/object-events examples/hellolibvirt \
-  examples/dominfo examples/domsuspend examples/apparmor \
-  examples/xml/nwfilter examples/openauth examples/systemtap \
-  tools/wireshark examples/dommigrate \
-  examples/lxcconvert examples/domtop
+SUBDIRS = gnulib/lib include src daemon tools docs gnulib/tests \
+  python tests po examples/domain-events/events-c examples/hellolibvirt \
+  examples/dominfo examples/domsuspend examples/python examples/apparmor \
+  examples/xml/nwfilter examples/openauth examples/systemtap

-ACLOCAL_AMFLAGS = -I m4
+ACLOCAL_AMFLAGS = -I m4 -I gnulib/m4

 XML_EXAMPLES = \
  $(patsubst $(srcdir)/%,%,$(wildcard $(addprefix $(srcdir)/examples/xml/, \
 					test/*.xml storage/*.xml)))

 EXTRA_DIST = \
-  config-post.h \
  ChangeLog-old \
  libvirt.spec libvirt.spec.in \
  mingw-libvirt.spec.in \
  libvirt.pc.in \
-  libvirt-qemu.pc.in \
-  libvirt-lxc.pc.in \
-  libvirt-admin.pc.in \
  autobuild.sh \
  Makefile.nonreentrant \
  autogen.sh \
  cfg.mk \
+  examples/domain-events/events-python \
  run.in \
  AUTHORS.in \
  $(XML_EXAMPLES)

 pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = libvirt.pc libvirt-qemu.pc libvirt-lxc.pc
+pkgconfig_DATA = libvirt.pc

 NEWS: $(top_srcdir)/docs/news.xsl $(top_srcdir)/docs/news.html.in
 	$(AM_V_GEN)if [ -x $(XSLTPROC) ] ; then			\
@@ -60,13 +42,10 @@ NEWS: $(top_srcdir)/docs/news.xsl $(top_srcdir)/docs/news.html.in
 	   | perl -pe 's/[ \t]+$$//'				\
 	   > $@-t && mv $@-t $@ ; fi

-$(top_srcdir)/HACKING: $(top_srcdir)/docs/hacking1.xsl \
-			$(top_srcdir)/docs/hacking2.xsl \
-			$(top_srcdir)/docs/wrapstring.xsl \
-			$(top_srcdir)/docs/hacking.html.in
+$(top_srcdir)/HACKING: $(top_srcdir)/docs/hacking1.xsl $(top_srcdir)/docs/hacking2.xsl \
+                       $(top_srcdir)/docs/wrapstring.xsl $(top_srcdir)/docs/hacking.html.in
 	$(AM_V_GEN)if [ -x $(XSLTPROC) ] ; then \
-	   $(XSLTPROC) --nonet $(top_srcdir)/docs/hacking1.xsl \
-		$(top_srcdir)/docs/hacking.html.in | \
+	   $(XSLTPROC) --nonet $(top_srcdir)/docs/hacking1.xsl $(top_srcdir)/docs/hacking.html.in | \
 	   $(XSLTPROC) --nonet $(top_srcdir)/docs/hacking2.xsl - \
 	   | perl -0777 -pe 's/\n\n+$$/\n/' \
 	   > $@-t && mv $@-t $@ ; fi;
@@ -76,6 +55,11 @@ rpm: clean

 check-local: all tests

+tests:
+	@(cd docs/examples ; $(MAKE) MAKEFLAGS+=--silent tests)
+	@(if [ "$(pythondir)" != "" ] ; then cd python ; \
+	  $(MAKE) MAKEFLAGS+=--silent tests ; fi)
+
 cov: clean-cov
 	mkdir $(top_builddir)/coverage
 	$(LCOV) -c -o $(top_builddir)/coverage/libvirt.info.tmp \
@@ -111,9 +95,9 @@ gen-ChangeLog:

 .PHONY: gen-AUTHORS
 gen-AUTHORS:
-	$(AM_V_GEN)if test -d $(srcdir)/.git; then \
-	    out="`cd $(srcdir) && git log --pretty=format:'%aN <%aE>' | sort -u`" && \
-	    perl -p -e "s/#authorslist#// and print '$$out'" \
-	      < $(srcdir)/AUTHORS.in > $(distdir)/AUTHORS-tmp && \
+	$(AM_V_GEN)if test -d .git; then \
+	    out="`git log --pretty=format:'%aN <%aE>' | sort -u`" && \
+	    cat $(srcdir)/AUTHORS.in | perl -p -e "s/#authorslist#/$$out/" > \
+	      $(distdir)/AUTHORS-tmp && \
 	    mv -f $(distdir)/AUTHORS-tmp $(distdir)/AUTHORS ; \
 	fi
--- a/Makefile.nonreentrant
+++ b/Makefile.nonreentrant
@@ -1,18 +1,3 @@
-## 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 9:
--- a/2
+++ b/2
@@ -15,7 +15,7 @@ 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.
+Valgrind supports your architecture. See also README-valgrind.

 While building from a just-cloned source tree may require installing a
 few prerequisites, later, a plain `git pull && make' should be sufficient.
--- a/autobuild.sh
+++ b/autobuild.sh
@@ -8,13 +8,6 @@ set -v
 test -n "$1" && RESULTS=$1 || RESULTS=results.log
 : ${AUTOBUILD_INSTALL_ROOT=$HOME/builder}

-# If run under the autobuilder, we must use --nodeps with rpmbuild;
-# but this can lead to odd error diagnosis for normal development.
-nodeps=
-if test "${AUTOBUILD_COUNTER+set}"; then
-  nodeps=--nodeps
-fi
-
 test -f Makefile && make -k distclean || :
 rm -rf coverage

@@ -25,11 +18,9 @@ cd build
 # Run with options not normally exercised by the rpm build, for
 # more complete code coverage.
 ../autogen.sh --prefix="$AUTOBUILD_INSTALL_ROOT" \
-  --enable-expensive-tests \
  --enable-test-coverage \
  --disable-nls \
-  --enable-werror \
-  --enable-static
+  --enable-werror

 # If the MAKEFLAGS envvar does not yet include a -j option,
 # add -jN where N depends on the number of processors.
@@ -67,7 +58,7 @@ else
 fi

 if test -f /usr/bin/rpmbuild ; then
-  rpmbuild $nodeps \
+  rpmbuild --nodeps \
     --define "extra_release $EXTRA_RELEASE" \
     --define "_sourcedir `pwd`" \
     -ba --clean libvirt.spec
@@ -77,15 +68,15 @@ fi
 if test -x /usr/bin/i686-w64-mingw32-gcc ; then
  make distclean

-  PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig" \
  PKG_CONFIG_PATH="$AUTOBUILD_INSTALL_ROOT/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" \
  CC="i686-w64-mingw32-gcc" \
  ../configure \
    --build=$(uname -m)-w64-linux \
    --host=i686-w64-mingw32 \
    --prefix="$AUTOBUILD_INSTALL_ROOT/i686-w64-mingw32/sys-root/mingw" \
-    --enable-expensive-tests \
-    --enable-werror
+    --enable-werror \
+    --without-libvirtd \
+    --without-python

  make
  make install
@@ -96,15 +87,15 @@ fi
 if test -x /usr/bin/x86_64-w64-mingw32-gcc ; then
  make distclean

-  PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig" \
  PKG_CONFIG_PATH="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" \
  CC="x86_64-w64-mingw32-gcc" \
  ../configure \
    --build=$(uname -m)-w64-linux \
    --host=x86_64-w64-mingw32 \
    --prefix="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw" \
-    --enable-expensive-tests \
-    --enable-werror
+    --enable-werror \
+    --without-libvirtd \
+    --without-python

  make
  make install
@@ -114,7 +105,7 @@ fi

 if test -x /usr/bin/i686-w64-mingw32-gcc && test -x /usr/bin/x86_64-w64-mingw32-gcc ; then
  if test -f /usr/bin/rpmbuild ; then
-    rpmbuild $nodeps \
+    rpmbuild --nodeps \
       --define "extra_release $EXTRA_RELEASE" \
       --define "_sourcedir `pwd`" \
       -ba --clean mingw-libvirt.spec
--- a/autogen.sh
+++ b/autogen.sh
@@ -20,10 +20,6 @@ no_git=
 if test "x$1" = "x--no-git"; then
  no_git=" $1"
  shift
-  case "$1 $2" in
-    --gnulib-srcdir=*) no_git="$no_git $1"; shift ;;
-    --gnulib-srcdir\ *) no_git="$no_git $1=$2"; shift; shift;;
-  esac
 fi
 if test -z "$NOCONFIGURE" ; then
  if test "x$1" = "x--system"; then
@@ -39,7 +35,7 @@ if test -z "$NOCONFIGURE" ; then
    echo "Running ./configure with $EXTRA_ARGS $@"
  else
    if test -z "$*" && test ! -f "$THEDIR/config.status"; then
-        echo "I am going to run ./configure with no arguments - if you wish"
+        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."
    fi
  fi
@@ -53,10 +49,6 @@ fi
 # we rerun bootstrap to pull in those diffs.
 bootstrap_hash()
 {
-    if test "$no_git"; then
-        echo no-git
-        return
-    fi
    git submodule status | sed 's/^[ +-]//;s/ .*//'
    git hash-object bootstrap.conf
    git ls-tree -d HEAD gnulib/local | awk '{print $3}'
@@ -68,11 +60,9 @@ bootstrap_hash()
 # like to run 'git clean -x -f po' to fix it; but only ./bootstrap regenerates
 # the required file po/Makevars.
 # Only run bootstrap from a git checkout, never from a tarball.
-if test -d .git || test -f .git; then
+if test -d .git; then
    curr_status=.git-module-status t=
-    if test "$no_git"; then
-        t=no-git
-    elif test -d .gnulib; then
+    if test -d .gnulib; then
        t=$(bootstrap_hash; git diff .gnulib)
    fi
    case $t:${CLEAN_SUBMODULE+set} in
@@ -88,7 +78,7 @@ if test -d .git || test -f .git; then
        # good, it's up to date, all we need is autoreconf
        autoreconf -if
    else
-        if test -z "$no_git" && test ${CLEAN_SUBMODULE+set}; then
+        if test ${CLEAN_SUBMODULE+set}; then
            echo cleaning up submodules...
            git submodule foreach 'git clean -dfqx && git reset --hard'
        fi
--- a/208
+++ b/208
@@ -1,10 +1,10 @@
 #! /bin/sh
 # Print a version string.
-scriptversion=2014-12-08.12; # UTC
+scriptversion=2012-07-19.14; # UTC

 # Bootstrap this package from checked-out sources.

-# Copyright (C) 2003-2015 Free Software Foundation, Inc.
+# Copyright (C) 2003-2012 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
@@ -42,9 +42,6 @@ export LC_ALL

 local_gl_dir=gl

-# Honour $PERL, but work even if there is none
-PERL="${PERL-perl}"
-
 me=$0

 usage() {
@@ -143,21 +140,20 @@ po_download_command_format2=\
 "wget --mirror -nd -q -np -A.po -P '%s' \
 http://translationproject.org/latest/%s/"

-# Prefer a non-empty tarname (4th argument of AC_INIT if given), else
-# fall back to the package name (1st argument with munging)
 extract_package_name='
-  /^AC_INIT(\[*/{
-     s///
-     /^[^,]*,[^,]*,[^,]*,[ []*\([^][ ,)]\)/{
-       s//\1/
-       s/[],)].*//
+  /^AC_INIT(/{
+     /.*,.*,.*, */{
+       s///
+       s/[][]//g
+       s/)$//
       p
       q
     }
-     s/[],)].*//
+     s/AC_INIT(\[*//
+     s/]*,.*//
     s/^GNU //
     y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/
-     s/[^abcdefghijklmnopqrstuvwxyz0123456789_]/-/g
+     s/[^A-Za-z0-9_]/-/g
     p
  }
 '
@@ -212,26 +208,12 @@ bootstrap_sync=false
 # Use git to update gnulib sources
 use_git=true

-check_exists() {
-  if test "$1" = "--verbose"; then
-    ($2 --version </dev/null) >/dev/null 2>&1
-    if test $? -ge 126; then
-      # If not found, run with diagnostics as one may be
-      # presented with env variables to set to find the right version
-      ($2 --version </dev/null)
-    fi
-  else
-    ($1 --version </dev/null) >/dev/null 2>&1
-  fi
-
-  test $? -lt 126
-}
-
 # find_tool ENVVAR NAMES...
 # -------------------------
 # Search for a required program.  Use the value of ENVVAR, if set,
-# otherwise find the first of the NAMES that can be run.
-# If found, set ENVVAR to the program name, die otherwise.
+# otherwise find the first of the NAMES that can be run (i.e.,
+# supports --version).  If found, set ENVVAR to the program name,
+# die otherwise.
 #
 # FIXME: code duplication, see also gnu-web-doc-update.
 find_tool ()
@@ -241,21 +223,27 @@ find_tool ()
  find_tool_names=$@
  eval "find_tool_res=\$$find_tool_envvar"
  if test x"$find_tool_res" = x; then
-    for i; do
-      if check_exists $i; then
-        find_tool_res=$i
-        break
+    for i
+    do
+      if ($i --version </dev/null) >/dev/null 2>&1; then
+       find_tool_res=$i
+       break
      fi
    done
+  else
+    find_tool_error_prefix="\$$find_tool_envvar: "
  fi
-  if test x"$find_tool_res" = x; then
-    warn_ "one of these is required: $find_tool_names;"
-    die   "alternatively set $find_tool_envvar to a compatible tool"
-  fi
+  test x"$find_tool_res" != x \
+    || die "one of these is required: $find_tool_names"
+  ($find_tool_res --version </dev/null) >/dev/null 2>&1 \
+    || die "${find_tool_error_prefix}cannot run $find_tool_res --version"
  eval "$find_tool_envvar=\$find_tool_res"
  eval "export $find_tool_envvar"
 }

+# Find sha1sum, named gsha1sum on MacPorts, and shasum on Mac OS X 10.6.
+find_tool SHA1SUM sha1sum gsha1sum shasum
+
 # Override the default configuration, if necessary.
 # Make sure that bootstrap.conf is sourced from the current directory
 # if we were invoked as "sh bootstrap".
@@ -267,12 +255,12 @@ esac
 # Extra files from gnulib, which override files from other sources.
 test -z "${gnulib_extra_files}" && \
  gnulib_extra_files="
-        build-aux/install-sh
-        build-aux/mdate-sh
-        build-aux/texinfo.tex
-        build-aux/depcomp
-        build-aux/config.guess
-        build-aux/config.sub
+        $build_aux/install-sh
+        $build_aux/mdate-sh
+        $build_aux/texinfo.tex
+        $build_aux/depcomp
+        $build_aux/config.guess
+        $build_aux/config.sub
        doc/INSTALL
 "

@@ -318,34 +306,34 @@ if test -n "$checkout_only_file" && test ! -r "$checkout_only_file"; then
  die "Bootstrapping from a non-checked-out distribution is risky."
 fi

-# Strip blank and comment lines to leave significant entries.
-gitignore_entries() {
-  sed '/^#/d; /^$/d' "$@"
+# Ensure that lines starting with ! sort last, per gitignore conventions
+# for whitelisting exceptions after a more generic blacklist pattern.
+sort_patterns() {
+  sort -u "$@" | sed '/^!/ {
+    H
+    d
+  }
+  $ {
+    P
+    x
+    s/^\n//
+  }' | sed '/^$/d'
 }

-# If $STR is not already on a line by itself in $FILE, insert it at the start.
-# Entries are inserted at the start of the ignore list to ensure existing
-# entries starting with ! are not overridden.  Such entries support
-# whitelisting exceptions after a more generic blacklist pattern.
-insert_if_absent() {
+# If $STR is not already on a line by itself in $FILE, insert it,
+# sorting the new contents of the file and replacing $FILE with the result.
+insert_sorted_if_absent() {
  file=$1
  str=$2
  test -f $file || touch $file
-  test -r $file || die "Error: failed to read ignore file: $file"
-  duplicate_entries=$(gitignore_entries $file | sort | uniq -d)
-  if [ "$duplicate_entries" ] ; then
-    die "Error: Duplicate entries in $file: " $duplicate_entries
-  fi
-  linesold=$(gitignore_entries $file | wc -l)
-  linesnew=$( { echo "$str"; cat $file; } | gitignore_entries | sort -u | wc -l)
-  if [ $linesold != $linesnew ] ; then
-    { echo "$str" | cat - $file > $file.bak && mv $file.bak $file; } \
-      || die "insert_if_absent $file $str: failed"
-  fi
+  echo "$str" | sort_patterns - $file | cmp -s - $file > /dev/null \
+    || { echo "$str" | sort_patterns - $file > $file.bak \
+      && mv $file.bak $file; } \
+    || die "insert_sorted_if_absent $file $str: failed"
 }

 # Adjust $PATTERN for $VC_IGNORE_FILE and insert it with
-# insert_if_absent.
+# insert_sorted_if_absent.
 insert_vc_ignore() {
  vc_ignore_file="$1"
  pattern="$2"
@@ -356,7 +344,7 @@ insert_vc_ignore() {
    # .gitignore entry.
    pattern=$(echo "$pattern" | sed s,^,/,);;
  esac
-  insert_if_absent "$vc_ignore_file" "$pattern"
+  insert_sorted_if_absent "$vc_ignore_file" "$pattern"
 }

 # Die if there is no AC_CONFIG_AUX_DIR($build_aux) line in configure.ac.
@@ -421,7 +409,7 @@ sort_ver() { # sort -V is not generally available
 get_version() {
  app=$1

-  $app --version >/dev/null 2>&1 || { $app --version; return 1; }
+  $app --version >/dev/null 2>&1 || return 1

  $app --version 2>&1 |
  sed -n '# Move version to start of line.
@@ -459,7 +447,6 @@ check_versions() {
    test "$appvar" = TAR && appvar=AMTAR
    case $appvar in
        GZIP) ;; # Do not use $GZIP:  it contains gzip options.
-        PERL::*) ;; # Keep perl modules as-is
        *) eval "app=\${$appvar-$app}" ;;
    esac

@@ -477,22 +464,12 @@ check_versions() {
          ret=1
          continue
        } ;;
-      # Another check is for perl modules.  These can be written as
-      # e.g. perl::XML::XPath in case of XML::XPath module, etc.
-      perl::*)
-        # Extract module name
-        app="${app#perl::}"
-        if ! $PERL -m"$app" -e 'exit 0' >/dev/null 2>&1; then
-          warn_ "Error: perl module '$app' not found"
-          ret=1
-        fi
-        continue
-        ;;
    esac
    if [ "$req_ver" = "-" ]; then
      # Merely require app to exist; not all prereq apps are well-behaved
      # so we have to rely on $? rather than get_version.
-      if ! check_exists --verbose $app; then
+      $app --version >/dev/null 2>&1
+      if [ 126 -le $? ]; then
        warn_ "Error: '$app' not found"
        ret=1
      fi
@@ -525,12 +502,6 @@ print_versions() {
  # can't depend on column -t
 }

-# Find sha1sum, named gsha1sum on MacPorts, shasum on Mac OS X 10.6.
-# Also find the compatible sha1 utility on the BSDs
-if test x"$SKIP_PO" = x; then
-  find_tool SHA1SUM sha1sum gsha1sum shasum sha1
-fi
-
 use_libtool=0
 # We'd like to use grep -E, to see if any of LT_INIT,
 # AC_PROG_LIBTOOL, AM_PROG_LIBTOOL is used in configure.ac,
@@ -576,21 +547,13 @@ if ! printf "$buildreq" | check_versions; then
  fi
 fi

-# Warn the user if autom4te appears to be broken; this causes known
-# issues with at least gettext 0.18.3.
-probe=$(echo 'm4_quote([hi])' | autom4te -l M4sugar -t 'm4_quote:$%' -)
-if test "x$probe" != xhi; then
-  warn_ "WARNING: your autom4te wrapper eats stdin;"
-  warn_ "if bootstrap fails, consider upgrading your autotools"
-fi
-
 echo "$0: Bootstrapping from checked-out $package sources..."

 # See if we can use gnulib's git-merge-changelog merge driver.
-if $use_git && test -d .git && check_exists git; then
+if test -d .git && (git --version) >/dev/null 2>/dev/null ; then
  if git config merge.merge-changelog.driver >/dev/null ; then
    :
-  elif check_exists git-merge-changelog; then
+  elif (git-merge-changelog --version) >/dev/null 2>/dev/null ; then
    echo "$0: initializing git-merge-changelog driver"
    git config merge.merge-changelog.name 'GNU-style ChangeLog merge driver'
    git config merge.merge-changelog.driver 'git-merge-changelog %O %A %B'
@@ -610,21 +573,17 @@ git_modules_config () {
  test -f .gitmodules && git config --file .gitmodules "$@"
 }

-if $use_git; then
-  gnulib_path=$(git_modules_config submodule.gnulib.path)
-  test -z "$gnulib_path" && gnulib_path=gnulib
-fi
+gnulib_path=$(git_modules_config submodule.gnulib.path)
+test -z "$gnulib_path" && gnulib_path=gnulib

-# Get gnulib files.  Populate $GNULIB_SRCDIR, possibly updating a
-# submodule, for use in the rest of the script.
+# Get gnulib files.

 case ${GNULIB_SRCDIR--} in
 -)
-  # Note that $use_git is necessarily true in this case.
  if git_modules_config submodule.gnulib.url >/dev/null; then
    echo "$0: getting gnulib files..."
-    git submodule init -- "$gnulib_path" || exit $?
-    git submodule update -- "$gnulib_path" || exit $?
+    git submodule init || exit $?
+    git submodule update || exit $?

  elif [ ! -d "$gnulib_path" ]; then
    echo "$0: getting gnulib files..."
@@ -641,8 +600,8 @@ case ${GNULIB_SRCDIR--} in
  GNULIB_SRCDIR=$gnulib_path
  ;;
 *)
-  # Use GNULIB_SRCDIR directly or as a reference.
-  if $use_git && test -d "$GNULIB_SRCDIR"/.git && \
+  # Use GNULIB_SRCDIR as a reference.
+  if test -d "$GNULIB_SRCDIR"/.git && \
        git_modules_config submodule.gnulib.url >/dev/null; then
    echo "$0: getting gnulib files..."
    if git submodule -h|grep -- --reference > /dev/null; then
@@ -653,14 +612,13 @@ case ${GNULIB_SRCDIR--} in
      # This fallback allows at least git 1.5.5.
      if test -f "$gnulib_path"/gnulib-tool; then
        # Since file already exists, assume submodule init already complete.
-        git submodule update -- "$gnulib_path" || exit $?
+        git submodule update || exit $?
      else
        # Older git can't clone into an empty directory.
        rmdir "$gnulib_path" 2>/dev/null
        git clone --reference "$GNULIB_SRCDIR" \
          "$(git_modules_config submodule.gnulib.url)" "$gnulib_path" \
-          && git submodule init -- "$gnulib_path" \
-          && git submodule update -- "$gnulib_path" \
+          && git submodule init && git submodule update \
          || exit $?
      fi
    fi
@@ -669,19 +627,12 @@ case ${GNULIB_SRCDIR--} in
  ;;
 esac

-# $GNULIB_SRCDIR now points to the version of gnulib to use, and
-# we no longer need to use git or $gnulib_path below here.
-
 if $bootstrap_sync; then
  cmp -s "$0" "$GNULIB_SRCDIR/build-aux/bootstrap" || {
    echo "$0: updating bootstrap and restarting..."
-    case $(sh -c 'echo "$1"' -- a) in
-      a) ignored=--;;
-      *) ignored=ignored;;
-    esac
    exec sh -c \
      'cp "$1" "$2" && shift && exec "${CONFIG_SHELL-/bin/sh}" "$@"' \
-      $ignored "$GNULIB_SRCDIR/build-aux/bootstrap" \
+      -- "$GNULIB_SRCDIR/build-aux/bootstrap" \
      "$0" "$@" --no-bootstrap-sync
  }
 fi
@@ -729,10 +680,11 @@ update_po_files() {
    cksum_file="$ref_po_dir/$po.s1"
    if ! test -f "$cksum_file" ||
        ! test -f "$po_dir/$po.po" ||
-        ! $SHA1SUM -c "$cksum_file" < "$new_po" > /dev/null 2>&1; then
+        ! $SHA1SUM -c --status "$cksum_file" \
+            < "$new_po" > /dev/null; then
      echo "$me: updated $po_dir/$po.po..."
      cp "$new_po" "$po_dir/$po.po" \
-          && $SHA1SUM < "$new_po" > "$cksum_file" || return
+          && $SHA1SUM < "$new_po" > "$cksum_file"
    fi
  done
 }
@@ -915,8 +867,7 @@ if test $use_libtool = 1; then
  esac
 fi
 echo "$0: $gnulib_tool $gnulib_tool_options --import ..."
-$gnulib_tool $gnulib_tool_options --import $gnulib_modules \
-  || die "gnulib-tool failed"
+$gnulib_tool $gnulib_tool_options --import $gnulib_modules &&

 for file in $gnulib_files; do
  symlink_to_dir "$GNULIB_SRCDIR" $file \
@@ -938,21 +889,20 @@ find "$m4_base" "$source_base" \
  -depth \( -name '*.m4' -o -name '*.[ch]' \) \
  -type l -xtype l -delete > /dev/null 2>&1

-# Invoke autoreconf with --force --install to ensure upgrades of tools
-# such as ylwrap.
-AUTORECONFFLAGS="--verbose --install --force -I $m4_base $ACLOCAL_FLAGS"
-
 # Some systems (RHEL 5) are using ancient autotools, for which the
 # --no-recursive option had not been invented.  Detect that lack and
 # omit the option when it's not supported.  FIXME in 2017: remove this
 # hack when RHEL 5 autotools are updated, or when they become irrelevant.
+no_recursive=
 case $($AUTORECONF --help) in
-  *--no-recursive*) AUTORECONFFLAGS="$AUTORECONFFLAGS --no-recursive";;
+  *--no-recursive*) no_recursive=--no-recursive;;
 esac

 # Tell autoreconf not to invoke autopoint or libtoolize; they were run above.
-echo "running: AUTOPOINT=true LIBTOOLIZE=true $AUTORECONF $AUTORECONFFLAGS"
-AUTOPOINT=true LIBTOOLIZE=true $AUTORECONF $AUTORECONFFLAGS \
+echo "running: AUTOPOINT=true LIBTOOLIZE=true " \
+    "$AUTORECONF --verbose --install $no_recursive -I $m4_base $ACLOCAL_FLAGS"
+AUTOPOINT=true LIBTOOLIZE=true \
+    $AUTORECONF --verbose --install $no_recursive -I $m4_base $ACLOCAL_FLAGS \
  || die "autoreconf failed"

 # Get some extra files from gnulib, overriding existing files.
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -1,6 +1,6 @@
 # Bootstrap configuration.

-# Copyright (C) 2010-2014 Red Hat, Inc.
+# Copyright (C) 2010-2012 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
@@ -20,7 +20,6 @@
 gnulib_modules='
 accept
 areadlink
-autobuild
 base64
 bind
 bitrotate
@@ -35,7 +34,6 @@ clock-time
 close
 connect
 configmake
-count-leading-zeros
 count-one-bits
 crypto/md5
 crypto/sha256
@@ -72,8 +70,6 @@ listen
 localeconv
 maintainer-makefile
 manywarnings
-mgetgroups
-mkdtemp
 mkostemp
 mkostemps
 mktempd
@@ -94,9 +90,7 @@ recv
 regex
 random_r
 sched
-secure_getenv
 send
-setenv
 setsockopt
 sigaction
 sigpipe
@@ -177,11 +171,11 @@ fi
 # Tell gnulib to:
 #   require LGPLv2+
 #   apply any local diffs in gnulib/local/ dir
-#   put *.m4 files in m4/ dir
+#   put *.m4 files in new gnulib/m4/ dir
 #   put *.[ch] files in new gnulib/lib/ dir
 #   import gnulib tests in new gnulib/tests/ dir
 gnulib_name=libgnu
-m4_base=m4
+m4_base=gnulib/m4
 source_base=gnulib/lib
 tests_base=gnulib/tests
 gnulib_tool_option_extras="\
@@ -193,10 +187,18 @@ gnulib_tool_option_extras="\
 "
 local_gl_dir=gnulib/local

+# Convince bootstrap to use multiple m4 directories.
+: ${ACLOCAL=aclocal}
+ACLOCAL="$ACLOCAL -I m4"
+export ACLOCAL
+
 # 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.
+# required to run 'make dist' on a tarball.  As a special case, we want
+# to require the equivalent of the Fedora python-devel package, but
+# RHEL 5 lacks the witness python-config package; we hack around that
+# old environment below.
 buildreq="\
 autoconf   2.59
 automake   1.9.6
@@ -207,32 +209,40 @@ gzip       -
 libtool    -
 patch      -
 perl       5.5
-perl::XML::XPath -
 pkg-config -
+python-config -
 rpcgen     -
 tar        -
 xmllint	   -
 xsltproc   -
 "
+# Use rpm as a fallback to bypass the bootstrap probe for python-config,
+# for the sake of RHEL 5; without requiring it on newer systems that
+# have python-config to begin with.
+if `(${PYTHON_CONFIG-python-config} --version;
+     test $? -lt 126 || rpm -q python-devel) >/dev/null 2>&1`; then
+  PYTHON_CONFIG=true
+fi

 # Automake requires that ChangeLog and AUTHORS exist.
 touch AUTHORS ChangeLog || 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
+        $build_aux/install-sh
+        $build_aux/depcomp
+        $build_aux/config.guess
+        $build_aux/config.sub
        doc/INSTALL
 "


-bootstrap_post_import_hook()
+bootstrap_epilogue()
 {
  # Change paths in gnulib/tests/gnulib.mk from "../../.." to "../..",
-  # and make tests conditional by changing "TESTS" to "GNULIB_TESTS".
+  # then ensure that gnulib/tests/Makefile.in is up-to-date.
  m=gnulib/tests/gnulib.mk
-  sed 's,\.\./\.\./\.\.,../..,g; s/^TESTS /GNULIB_TESTS /' $m > $m-t
+  sed 's,\.\./\.\./\.\.,../..,g' $m > $m-t
  mv -f $m-t $m
+  ${AUTOMAKE-automake} gnulib/tests/Makefile
 }
--- a/build-aux/bracket-spacing.pl
+++ b/build-aux/bracket-spacing.pl
@@ -1,7 +1,6 @@
 #!/usr/bin/perl
 #
 # bracket-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
@@ -27,23 +26,13 @@ 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;
+        # Kill any quoted strongs
+        $data =~ s,".*?","XXX",g;

        # Kill any C++ style comments
        $data =~ s,//.*$,//,;
@@ -84,17 +73,13 @@ foreach my $file (@ARGV) {
        #
        #  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\((?!\*)/) {
+        while ($data =~ /(\w+)\s\((?!\*)/) {
            my $kw = $1;

            # Allow space after keywords only
            if ($kw =~ /^(if|for|while|switch|return)$/) {
-                $tmpdata =~ s/($kw\s\()/XXX(/;
+                $data =~ s/($kw\s\()/XXX(/;
            } else {
-                print "Whitespace after non-keyword:\n";
                print "$file:$.: $line";
                $ret = 1;
                last;
@@ -103,99 +88,26 @@ foreach my $file (@ARGV) {

        # Require whitespace immediately after keywords,
        # but none after the opening bracket
-        if ($data =~ /\b(if|for|while|switch|return)\(/ ||
-            $data =~ /\b(if|for|while|switch|return)\s+\(\s/) {
-            print "No whitespace after keyword:\n";
+        while ($data =~ /(if|for|while|switch|return)\(/ ||
+               $data =~ /(if|for|while|switch|return)\s+\(\s/) {
            print "$file:$.: $line";
            $ret = 1;
+            last;
        }

        # Forbid whitespace between )( of a function typedef
-        if ($data =~ /\(\*\w+\)\s+\(/) {
-            print "Whitespace between ')' and '(':\n";
+        while ($data =~ /\(\*\w+\)\s+\(/) {
            print "$file:$.: $line";
            $ret = 1;
+            last;
        }

        # Forbid whitespace following ( or prior to )
-        if ($data =~ /\S\s+\)/ ||
-            $data =~ /\(\s+\S/) {
-            print "Whitespace after '(' or before ')':\n";
+        while ($data =~ /\S\s+\)/ ||
+               $data =~ /\(\s+\S/) {
            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]\s+[;,]/) {
-            print "Whitespace before (semi)colon:\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 '=='
-        # with the exception of virAssertCmpInt()
-        $tmpdata = $data;
-        $tmpdata =~ s/(virAssertCmpInt\(.* ).?=,/$1op,/;
-        if ($tmpdata =~ /[^ ]\b[!<>&|\-+*\/%\^=]?=[^=]/ ||
-            $tmpdata =~ /=[^= \\\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 = "";
+            last;
        }
    }
    close FILE;
--- a/cfg.mk
+++ b/cfg.mk
@@ -1,5 +1,5 @@
 # Customize Makefile.maint.                           -*- makefile -*-
-# Copyright (C) 2008-2015 Red Hat, Inc.
+# Copyright (C) 2008-2012 Red Hat, Inc.
 # Copyright (C) 2003-2008 Free Software Foundation, Inc.

 # This program is free software: you can redistribute it and/or modify
@@ -33,9 +33,8 @@ gnulib_dir = $(srcdir)/.gnulib
 # This is all gnulib files, as well as generated files for RPC code.
 generated_files = \
  $(srcdir)/daemon/*_dispatch.h \
-  $(srcdir)/src/*/*_dispatch.h \
  $(srcdir)/src/remote/*_client_bodies.h \
-  $(srcdir)/src/*/*_protocol.[ch] \
+  $(srcdir)/src/remote/*_protocol.[ch] \
  $(srcdir)/gnulib/lib/*.[ch]

 # We haven't converted all scripts to using gnulib's init.sh yet.
@@ -90,19 +89,15 @@ endif

 # Files that should never cause syntax check failures.
 VC_LIST_ALWAYS_EXCLUDE_REGEX = \
-  (^(HACKING|docs/(news\.html\.in|.*\.patch))|\.(po|fig|gif|ico|png))$$
+  (^(HACKING|docs/(news\.html\.in|.*\.patch))|\.po)$$

 # Functions like free() that are no-ops on NULL arguments.
 useless_free_options =				\
-  --name=VBOX_UTF16_FREE			\
-  --name=VBOX_UTF8_FREE				\
-  --name=VBOX_COM_UNALLOC_MEM			\
  --name=VIR_FREE				\
  --name=qemuCapsFree				\
  --name=qemuMigrationCookieFree                \
  --name=qemuMigrationCookieGraphicsFree        \
  --name=sexpr_free				\
-  --name=usbFreeDevice                          \
  --name=virBandwidthDefFree			\
  --name=virBitmapFree                          \
  --name=virCPUDefFree				\
@@ -125,8 +120,9 @@ useless_free_options =				\
  --name=virDomainDeviceDefFree			\
  --name=virDomainDiskDefFree			\
  --name=virDomainEventCallbackListFree		\
-  --name=virObjectEventQueueFree		\
-  --name=virObjectEventStateFree		\
+  --name=virDomainEventFree			\
+  --name=virDomainEventQueueFree		\
+  --name=virDomainEventStateFree		\
  --name=virDomainFSDefFree			\
  --name=virDomainGraphicsDefFree		\
  --name=virDomainHostdevDefFree		\
@@ -160,11 +156,11 @@ useless_free_options =				\
  --name=virNWFilterRuleDefFree			\
  --name=virNWFilterRuleInstFree		\
  --name=virNetworkDefFree			\
+  --name=virNetworkObjFree			\
  --name=virNodeDeviceDefFree			\
  --name=virNodeDeviceObjFree			\
  --name=virObjectUnref                         \
  --name=virObjectFreeCallback                  \
-  --name=virPCIDeviceFree                       \
  --name=virSecretDefFree			\
  --name=virStorageEncryptionFree		\
  --name=virStorageEncryptionSecretFree		\
@@ -203,6 +199,7 @@ useless_free_options =				\
 # y virDomainDeviceDefFree
 # y virDomainDiskDefFree
 # y virDomainEventCallbackListFree
+# y virDomainEventFree
 # y virDomainEventQueueFree
 # y virDomainFSDefFree
 # n virDomainFree
@@ -248,6 +245,8 @@ useless_free_options =				\
 # y virNetworkDefFree
 # n virNetworkFree (returns int)
 # n virNetworkFreeName (returns int)
+# y virNetworkObjFree
+# n virNetworkObjListFree FIXME
 # n virNodeDevCapsDefFree FIXME
 # y virNodeDeviceDefFree
 # n virNodeDeviceFree (returns int)
@@ -300,11 +299,9 @@ sc_flags_debug:
 # than d).  The existence of long long, and of documentation about
 # flags, makes the regex in the third test slightly harder.
 sc_flags_usage:
-	@test "$$(cat $(srcdir)/include/libvirt/libvirt-domain.h	\
+	@test "$$(cat $(srcdir)/include/libvirt/libvirt.h.in		\
 	    $(srcdir)/include/libvirt/virterror.h			\
 	    $(srcdir)/include/libvirt/libvirt-qemu.h			\
-	    $(srcdir)/include/libvirt/libvirt-lxc.h			\
-	    $(srcdir)/include/libvirt/libvirt-admin.h			\
 	  | grep -c '\(long\|unsigned\) flags')" != 4 &&		\
 	  { echo '$(ME): new API should use "unsigned int flags"' 1>&2;	\
 	    exit 1; } || :
@@ -324,7 +321,7 @@ sc_prohibit_internal_functions:
 # Avoid raw malloc and free, except in documentation comments.
 sc_prohibit_raw_allocation:
 	@prohibit='^.[^*].*\<((m|c|re)alloc|free) *\([^)]'		\
-	halt='use VIR_ macros from viralloc.h instead of malloc/free'	\
+	halt='use VIR_ macros from memory.h instead of malloc/free'	\
 	  $(_sc_search_regexp)

 # Avoid functions that can lead to double-close bugs.
@@ -376,19 +373,10 @@ sc_prohibit_strtol:
 	  $(_sc_search_regexp)

 # Use virAsprintf rather than as'printf since *strp is undefined on error.
-# But for plain %s, virAsprintf is overkill compared to strdup.
 sc_prohibit_asprintf:
 	@prohibit='\<v?a[s]printf\>'					\
 	halt='use virAsprintf, not as'printf				\
 	  $(_sc_search_regexp)
-	@prohibit='virAsprintf.*, *"%s",'				\
-	halt='use VIR_STRDUP instead of virAsprintf with "%s"'		\
-	  $(_sc_search_regexp)
-
-sc_prohibit_strdup:
-	@prohibit='\<strn?dup\> *\('					\
-	halt='use VIR_STRDUP, not strdup'				\
-	  $(_sc_search_regexp)

 # Prefer virSetUIDGID.
 sc_prohibit_setuid:
@@ -396,12 +384,6 @@ sc_prohibit_setuid:
 	halt='use virSetUIDGID, not raw set*id'				\
 	  $(_sc_search_regexp)

-# Don't compare *id_t against raw -1.
-sc_prohibit_risky_id_promotion:
-	@prohibit='\b(user|group|[ug]id) *[=!]= *-'			\
-	halt='cast -1 to ([ug]id_t) before comparing against id'	\
-	  $(_sc_search_regexp)
-
 # Use snprintf rather than s'printf, even if buffer is provably large enough,
 # since gnulib has more guarantees for snprintf portability
 sc_prohibit_sprintf:
@@ -419,12 +401,6 @@ sc_prohibit_gethostname:
 	halt='use virGetHostname, not gethostname'			\
 	  $(_sc_search_regexp)

-sc_prohibit_readdir:
-	@prohibit='\breaddir *\('					\
-	exclude='exempt from syntax-check'				\
-	halt='use virDirRead, not readdir'				\
-	  $(_sc_search_regexp)
-
 sc_prohibit_gettext_noop:
 	@prohibit='gettext_noop *\('					\
 	halt='use N_, not gettext_noop'					\
@@ -453,11 +429,6 @@ sc_prohibit_nonreentrant:
 	done ; \
 	exit $$fail

-sc_prohibit_select:
-	@prohibit="\\<select *\\("					\
-	halt="use poll(), not se""lect()"				\
-	  $(_sc_search_regexp)
-
 # Prohibit the inclusion of <ctype.h>.
 sc_prohibit_ctype_h:
 	@prohibit='^# *include  *<ctype\.h>'				\
@@ -470,18 +441,6 @@ sc_correct_id_types:
 	halt="use pid_t for pid, uid_t for uid, gid_t for gid"		\
 	  $(_sc_search_regexp)

-# "const fooPtr a" is the same as "foo * const a", even though it is
-# usually desired to have "foo const *a".  It's easier to just prevent
-# the confusing mix of typedef vs. const placement.
-# Also requires that all 'fooPtr' typedefs are actually pointers.
-sc_forbid_const_pointer_typedef:
-	@prohibit='(^|[^"])const \w*Ptr'				\
-	halt='"const fooPtr var" does not declare what you meant'	\
-	  $(_sc_search_regexp)
-	@prohibit='typedef [^(]+ [^*]\w*Ptr\b'				\
-	halt='use correct style and type for Ptr typedefs'		\
-	  $(_sc_search_regexp)
-
 # Forbid sizeof foo or sizeof (foo), require sizeof(foo)
 sc_size_of_brackets:
 	@prohibit='sizeof\s'						\
@@ -516,16 +475,6 @@ sc_prohibit_virBufferAdd_with_string_literal:
 	halt='use virBufferAddLit, not virBufferAdd, with a string literal' \
 	  $(_sc_search_regexp)

-sc_prohibit_virBufferAsprintf_with_string_literal:
-	@prohibit='\<virBufferAsprintf *\([^,]+, *"([^%"\]|\\.|%%)*"\)'		\
-	halt='use virBufferAddLit, not virBufferAsprintf, with a string literal' \
-	  $(_sc_search_regexp)
-
-sc_forbid_manual_xml_indent:
-	@prohibit='virBuffer.*" +<'					      \
-	halt='use virBufferAdjustIndent instead of spaces when indenting xml' \
-	  $(_sc_search_regexp)
-
 # Not only do they fail to deal well with ipv6, but the gethostby*
 # functions are also not thread-safe.
 sc_prohibit_gethostby:
@@ -533,12 +482,6 @@ sc_prohibit_gethostby:
 	halt='use getaddrinfo, not gethostby*'				\
 	  $(_sc_search_regexp)

-# dirname and basename from <libgen.h> are not required to be thread-safe
-sc_prohibit_libgen:
-	@prohibit='( (base|dir)name *\(|include .libgen\.h)'		\
-	halt='use functions from gnulib "dirname.h", not <libgen.h>'	\
-	  $(_sc_search_regexp)
-
 # raw xmlGetProp requires some nasty casts
 sc_prohibit_xmlGetProp:
 	@prohibit='\<xmlGetProp *\('					\
@@ -565,34 +508,6 @@ sc_avoid_attribute_unused_in_header:
 	halt='use ATTRIBUTE_UNUSED in .c rather than .h files'		\
 	  $(_sc_search_regexp)

-sc_prohibit_int_index:
-	@prohibit='\<(int|unsigned)\s*\*?index\>(\s|,|;)'	\
-	halt='use different name than 'index' for declaration'	        \
-	  $(_sc_search_regexp)
-
-sc_prohibit_int_ijk:
-	@prohibit='\<(int|unsigned) ([^(=]* )*(i|j|k)\>(\s|,|;)'	\
-	halt='use size_t, not int/unsigned int for loop vars i, j, k'	\
-	  $(_sc_search_regexp)
-
-sc_prohibit_loop_iijjkk:
-	@prohibit='\<(int|unsigned) ([^=]+ )*(ii|jj|kk)\>(\s|,|;)'	\
-	halt='use i, j, k for loop iterators, not ii, jj, kk' 		\
-	  $(_sc_search_regexp)
-
-# RHEL 5 gcc can't grok "for (int i..."
-sc_prohibit_loop_var_decl:
-	@prohibit='\<for *\(\w+[ *]+\w+'				\
-	in_vc_files='\.[ch]$$'						\
-	halt='declare loop iterators outside the for statement'		\
-	  $(_sc_search_regexp)
-
-# Use 'bool', not 'int', when assigning true or false
-sc_prohibit_int_assign_bool:
-	@prohibit='\<int\>.*= *(true|false)'				\
-	halt='use bool type for boolean values'				\
-	  $(_sc_search_regexp)
-
 # Many of the function names below came from this filter:
 # git grep -B2 '\<_('|grep -E '\.c- *[[:alpha:]_][[:alnum:]_]* ?\(.*[,;]$' \
 # |sed 's/.*\.c-  *//'|perl -pe 's/ ?\(.*//'|sort -u \
@@ -605,6 +520,16 @@ msg_gen_function += regerror
 msg_gen_function += vah_error
 msg_gen_function += vah_warning
 msg_gen_function += virGenericReportError
+msg_gen_function += virLibConnError
+msg_gen_function += virLibDomainError
+msg_gen_function += virLibDomainSnapshotError
+msg_gen_function += virLibInterfaceError
+msg_gen_function += virLibNetworkError
+msg_gen_function += virLibNodeDeviceError
+msg_gen_function += virLibNWFilterError
+msg_gen_function += virLibSecretError
+msg_gen_function += virLibStoragePoolError
+msg_gen_function += virLibStorageVolError
 msg_gen_function += virRaiseError
 msg_gen_function += virReportError
 msg_gen_function += virReportErrorHelper
@@ -634,7 +559,7 @@ sc_libvirt_unmarked_diagnostics:
 	  $(_sc_search_regexp)
 	@{ grep     -nE '\<$(func_re) *\(.*;$$' $$($(VC_LIST_EXCEPT));   \
 	   grep -A1 -nE '\<$(func_re) *\(.*,$$' $$($(VC_LIST_EXCEPT)); } \
-	   | $(SED) 's/_("\([^\"]\|\\.\)\+"//;s/[	 ]"%s"//'		\
+	   | sed 's/_("\([^\"]\|\\.\)\+"//;s/[	 ]"%s"//'		\
 	   | grep '[	 ]"' &&						\
 	  { echo '$(ME): found unmarked diagnostic(s)' 1>&2;		\
 	    exit 1; } || :
@@ -659,7 +584,7 @@ sc_prohibit_newline_at_end_of_diagnostic:
 sc_prohibit_diagnostic_without_format:
 	@{ grep     -nE '\<$(func_re) *\(.*;$$' $$($(VC_LIST_EXCEPT));   \
 	   grep -A2 -nE '\<$(func_re) *\(.*,$$' $$($(VC_LIST_EXCEPT)); } \
-	   | $(SED) -rn -e ':l; /[,"]$$/ {N;b l;}'				 \
+	   | sed -rn -e ':l; /[,"]$$/ {N;b l;}'				 \
 		-e '/(xenapiSessionErrorHandler|vah_(error|warning))/d'	 \
 		-e '/\<$(func_re) *\([^"]*"([^%"]|"\n[^"]*")*"[,)]/p'	 \
           | grep -vE 'VIR_ERROR' &&					 \
@@ -681,7 +606,7 @@ sc_prohibit_useless_translation:
 # or \n on one side of the split.
 sc_require_whitespace_in_translation:
 	@grep -n -A1 '"$$' $$($(VC_LIST_EXCEPT))   			\
-	   | $(SED) -ne ':l; /"$$/ {N;b l;}; s/"\n[^"]*"/""/g; s/\\n/ /g'	\
+	   | sed -ne ':l; /"$$/ {N;b l;}; s/"\n[^"]*"/""/g; s/\\n/ /g'	\
 		-e '/_(.*[^\ ]""[^\ ]/p' | grep . &&			\
 	  { echo '$(ME): missing whitespace at line split' 1>&2;	\
 	    exit 1; } || :
@@ -689,51 +614,13 @@ sc_require_whitespace_in_translation:
 # Enforce recommended preprocessor indentation style.
 sc_preprocessor_indentation:
 	@if cppi --version >/dev/null 2>&1; then			\
-	  $(VC_LIST_EXCEPT) | grep -E '\.[ch](\.in)?$$' | xargs cppi -a -c	\
+	  $(VC_LIST_EXCEPT) | grep '\.[ch]$$' | xargs cppi -a -c	\
 	    || { echo '$(ME): incorrect preprocessor indentation' 1>&2;	\
 		exit 1; };						\
 	else								\
 	  echo '$(ME): skipping test $@: cppi not installed' 1>&2;	\
 	fi

-# Enforce similar spec file indentation style, by running cppi on a
-# (comment-only) C file that mirrors the same layout as the spec file.
-sc_spec_indentation:
-	@if cppi --version >/dev/null 2>&1; then			\
-	  for f in $$($(VC_LIST_EXCEPT) | grep '\.spec\.in$$'); do	\
-	    $(SED) -e 's|#|// #|; s|%ifn*\(arch\)* |#if a // |'		\
-		-e 's/%\(else\|endif\|define\)/#\1/'			\
-		-e 's/^\( *\)\1\1\1#/#\1/'				\
-		-e 's|^\( *[^#/ ]\)|// \1|; s|^\( */[^/]\)|// \1|' $$f	\
-	    | cppi -a -c 2>&1 | $(SED) "s|standard input|$$f|";		\
-	  done | { if grep . >&2; then false; else :; fi; }		\
-	    || { echo '$(ME): incorrect preprocessor indentation' 1>&2;	\
-		exit 1; };						\
-	else								\
-	  echo '$(ME): skipping test $@: cppi not installed' 1>&2;	\
-	fi
-
-# Nested conditionals are easier to understand if we enforce that endifs
-# can be paired back to the if
-sc_makefile_conditionals:
-	@prohibit='(else|endif)($$| *#)'				\
-	in_vc_files='Makefile\.am'					\
-	halt='match "if FOO" with "endif FOO" in Makefiles'		\
-	  $(_sc_search_regexp)
-
-# Long lines can be harder to diff; too long, and git send-email chokes.
-# For now, only enforce line length on files where we have intentionally
-# fixed things and don't want to regress.
-sc_prohibit_long_lines:
-	@prohibit='.{90}'						\
-	in_vc_files='\.arg[sv]'						\
-	halt='Wrap long lines in expected output files'			\
-	  $(_sc_search_regexp)
-	@prohibit='.{80}'						\
-	in_vc_files='Makefile\.am'					\
-	halt='Wrap long lines in Makefiles'				\
-	  $(_sc_search_regexp)
-
 sc_copyright_format:
 	@require='Copyright .*Red 'Hat', Inc\.'				\
 	containing='Copyright .*Red 'Hat				\
@@ -747,22 +634,11 @@ sc_copyright_format:
 	  $(_sc_search_regexp)

 # Prefer the new URL listing over the old street address listing when
-# calling out where to get a copy of the [L]GPL.  Also, while we have
-# to ship COPYING (GPL) alongside COPYING.LESSER (LGPL), we want any
-# source file that calls out a top-level file to call out the LGPL
-# version.  Note that our typical copyright boilerplate refers to the
-# license by name, not by reference to a top-level file.
-sc_copyright_usage:
+# calling out where to get a copy of the [L]GPL.
+sc_copyright_address:
 	@prohibit=Boston,' MA'						\
 	halt='Point to <http://www.gnu.org/licenses/>, not an address'	\
 	  $(_sc_search_regexp)
-	@require='COPYING\.LESSER'					\
-	containing='COPYING'						\
-	halt='Refer to COPYING.LESSER for LGPL'				\
-	  $(_sc_search_regexp)
-	@prohibit='COPYING\.LIB'					\
-	halt='Refer to COPYING.LESSER for LGPL'				\
-	  $(_sc_search_regexp)

 # Some functions/macros produce messages intended solely for developers
 # and maintainers.  Do not mark them for translation.
@@ -775,17 +651,16 @@ sc_prohibit_gettext_markup:
 # lower-level code must not include higher-level headers.
 cross_dirs=$(patsubst $(srcdir)/src/%.,%,$(wildcard $(srcdir)/src/*/.))
 cross_dirs_re=($(subst / ,/|,$(cross_dirs)))
-mid_dirs=access|conf|cpu|locking|network|node_device|rpc|security|storage
 sc_prohibit_cross_inclusion:
 	@for dir in $(cross_dirs); do					\
 	  case $$dir in							\
 	    util/) safe="util";;					\
-	    access/ | conf/) safe="($$dir|conf|util)";;			\
-	    locking/) safe="($$dir|util|conf|rpc)";;			\
-	    cpu/| network/| node_device/| rpc/| security/| storage/)	\
-	      safe="($$dir|util|conf|storage)";;			\
-	    xenapi/ | xenconfig/ ) safe="($$dir|util|conf|xen)";;	\
-	    *) safe="($$dir|$(mid_dirs)|util)";;			\
+	    locking/)							\
+	      safe="($$dir|util|conf|rpc)";;				\
+	    cpu/ | locking/ | network/ | rpc/ | security/)		\
+	      safe="($$dir|util|conf)";;				\
+	    xenapi/ | xenxs/ ) safe="($$dir|util|conf|xen)";;		\
+	    *) safe="($$dir|util|conf|cpu|network|locking|rpc|security)";; \
 	  esac;								\
 	  in_vc_files="^src/$$dir"					\
 	  prohibit='^# *include .$(cross_dirs_re)'			\
@@ -798,223 +673,16 @@ sc_prohibit_cross_inclusion:
 # elements added to the enum by using a _LAST marker.
 sc_require_enum_last_marker:
 	@grep -A1 -nE '^[^#]*VIR_ENUM_IMPL *\(' $$($(VC_LIST_EXCEPT))	\
-	   | $(SED) -ne '/VIR_ENUM_IMPL[^,]*,$$/N'				\
+	   | sed -ne '/VIR_ENUM_IMPL[^,]*,$$/N'				\
 	     -e '/VIR_ENUM_IMPL[^,]*,[^,]*[^_,][^L,][^A,][^S,][^T,],/p'	\
 	     -e '/VIR_ENUM_IMPL[^,]*,[^,]\{0,4\},/p'			\
 	   | grep . &&							\
 	  { echo '$(ME): enum impl needs to use _LAST marker' 1>&2;	\
 	    exit 1; } || :

-# In Python files we don't want to end lines with a semicolon like in C
-sc_prohibit_semicolon_at_eol_in_python:
-	@prohibit='^[^#].*\;$$'			                        \
-	in_vc_files='\.py$$'						\
-	halt="Don't use semicolon at eol in python files"		\
-	  $(_sc_search_regexp)
-
-# mymain() in test files should use return, not exit, for nicer output
-sc_prohibit_exit_in_tests:
-	@prohibit='\<exit *\('						\
-	in_vc_files='^tests/'						\
-	halt='use return, not exit(), in tests'				\
-	  $(_sc_search_regexp)
-
-# Don't include duplicate header in the source (either *.c or *.h)
-sc_prohibit_duplicate_header:
-	@fail=0; for i in $$($(VC_LIST_EXCEPT) | grep '\.[chx]$$'); do	\
-	  awk '/# *include.*\.h/ {					\
-	    match($$0, /[<"][^>"]*[">]/);				\
-	    arr[substr($$0, RSTART + 1, RLENGTH - 2)]++;		\
-	  }								\
-	  END {								\
-	    for (key in arr) {						\
-	      if (arr[key] > 1)	{					\
-		fail=1;							\
-		printf("%d %s are included\n", arr[key], key);		\
-	      }								\
-	    }								\
-	    if (fail == 1) {						\
-	      printf("duplicate header(s) in " FILENAME "\n");		\
-	      exit 1;							\
-	    }								\
-	  }' $$i || fail=1;						\
-	done;								\
-	if test $$fail -eq 1; then					\
-	  { echo '$(ME): avoid duplicate headers' 1>&2; exit 1; }	\
-	fi;
-
-# Don't include "libvirt/*.h" in "" form.
-sc_prohibit_include_public_headers_quote:
-	@prohibit='# *include *"libvirt/.*\.h"'				\
-	in_vc_files='\.[ch]$$'						\
-	halt='Do not include libvirt/*.h in internal source'		\
-	  $(_sc_search_regexp)
-
-# Don't include "libvirt/*.h" in <> form. Except for external tools,
-# e.g. Python binding, examples and tools subdirectories.
-sc_prohibit_include_public_headers_brackets:
-	@prohibit='# *include *<libvirt/.*\.h>'				\
-	in_vc_files='\.[ch]$$'						\
-	halt='Do not include libvirt/*.h in internal source'		\
-	  $(_sc_search_regexp)
-
-# <config.h> is only needed in .c files; .h files do not need it since
-# .c files must include config.h before any other .h.
-sc_prohibit_config_h_in_headers:
-	@prohibit='^# *include\>.*config\.h'				\
-	in_vc_files='\.h$$'						\
-	halt='headers should not include <config.h>'			\
-	  $(_sc_search_regexp)
-
-sc_prohibit_unbounded_arrays_in_rpc:
-	@prohibit='<>'							\
-	in_vc_files='\.x$$'						\
-	halt='Arrays in XDR must have a upper limit set for <NNN>'	\
-	  $(_sc_search_regexp)
-
-sc_prohibit_getenv:
-	@prohibit='\b(secure_)?getenv *\('				\
-	exclude='exempt from syntax-check'				\
-	halt='Use virGetEnv{Allow,Block}SUID instead of getenv'		\
-	  $(_sc_search_regexp)
-
-sc_prohibit_atoi:
-	@prohibit='\bato(i|f|l|ll|q) *\('	\
-	halt='Use virStrToLong* instead of atoi, atol, atof, atoq, atoll' \
-	  $(_sc_search_regexp)
-
-sc_prohibit_wrong_filename_in_comment:
-	@fail=0;                                                       \
-	awk 'BEGIN {                                                   \
-	  fail=0;                                                      \
-	} FNR < 3 {                                                    \
-	  n=match($$0, /[[:space:]][^[:space:]]*[.][ch][[:space:]:]/); \
-	  if (n > 0) {                                                 \
-	    A=substr($$0, RSTART+1, RLENGTH-2);                        \
-	    n=split(FILENAME, arr, "/");                               \
-	    if (A != arr[n]) {                                         \
-	      print "in " FILENAME ": " A " mentioned in comments ";   \
-	      fail=1;                                                  \
-	    }                                                          \
-	  }                                                            \
-	} END {                                                        \
-	  if (fail == 1) {                                             \
-	    exit 1;                                                    \
-	  }                                                            \
-	}' $$($(VC_LIST_EXCEPT) | grep '\.[ch]$$') || fail=1;          \
-	if test $$fail -eq 1; then                                     \
-	  { echo '$(ME): The file name in comments must match the'     \
-	    'actual file name' 1>&2; exit 1; }	                       \
-	fi;
-
-sc_prohibit_virConnectOpen_in_virsh:
-	@prohibit='\bvirConnectOpen[a-zA-Z]* *\('                      \
-	in_vc_files='^tools/virsh-.*\.[ch]$$'                          \
-	halt='Use vshConnect() in virsh instead of virConnectOpen*'    \
-	  $(_sc_search_regexp)
-
-sc_require_space_before_label:
-	@prohibit='^(   ?)?[_a-zA-Z0-9]+:$$'                           \
-	in_vc_files='\.[ch]$$'                                         \
-	halt="Top-level labels should be indented by one space"        \
-	  $(_sc_search_regexp)
-
-# Doesn't catch all cases of mismatched braces across if-else, but it helps
-sc_require_if_else_matching_braces:
-	@prohibit='(  else( if .*\))? {|} else( if .*\))?$$)'		\
-	in_vc_files='\.[chx]$$'						\
-	halt="if one side of if-else uses {}, both sides must use it"	\
-	  $(_sc_search_regexp)
-
-sc_curly_braces_style:
-	@files=$$($(VC_LIST_EXCEPT) | grep '\.[ch]$$');			\
-	if $(GREP) -nHP							\
-'^\s*(?!([a-zA-Z_]*for_?each[a-zA-Z_]*) ?\()([_a-zA-Z0-9]+( [_a-zA-Z0-9]+)* ?\()?(\*?[_a-zA-Z0-9]+(,? \*?[_a-zA-Z0-9\[\]]+)+|void)\) ?\{'		\
-	$$files; then							\
-	  echo '$(ME): Non-K&R style used for curly braces around'	\
-		'function body, see HACKING' 1>&2; exit 1;		\
-	fi;								\
-	if $(GREP) -A1 -En ' ((if|for|while|switch) \(|(else|do)\b)[^{]*$$'\
-	  $$files | $(GREP) '^[^ ]*- *{'; then				\
-	  echo '$(ME): Use hanging braces for compound statements,'	\
-		'see HACKING' 1>&2; exit 1;				\
-	fi
-
-sc_prohibit_windows_special_chars_in_filename:
-	@files=$$($(VC_LIST_EXCEPT) | grep '[:*?"<>|]');               \
-	test -n "$$files" && { echo '$(ME): Windows special chars'     \
-	  'in filename not allowed:' 1>&2; echo $$files 1>&2; exit 1; } || :
-
-sc_prohibit_mixed_case_abbreviations:
-	@prohibit='Pci|Usb|Scsi'			\
-	in_vc_files='\.[ch]$$'				\
-	halt='Use PCI, USB, SCSI, not Pci, Usb, Scsi'	\
-	  $(_sc_search_regexp)
-
-# Require #include <locale.h> in all files that call setlocale()
-sc_require_locale_h:
-	@require='include.*locale\.h'					\
-	containing='setlocale *('					\
-	halt='setlocale() requires <locale.h>'				\
-	  $(_sc_search_regexp)
-
-sc_prohibit_empty_first_line:
-	@awk 'BEGIN { fail=0; }						\
-	FNR == 1 { if ($$0 == "") { print FILENAME ":1:"; fail=1; } }	\
-	END { if (fail == 1) {						\
-	  print "$(ME): Prohibited empty first line" > "/dev/stderr";	\
-	} exit fail; }' $$($(VC_LIST_EXCEPT));
-
-sc_prohibit_paren_brace:
-	@prohibit='\)\{$$'						\
-	in_vc_files='\.[chx]$$'						\
-	halt='Put space between closing parenthesis and opening brace'	\
-	  $(_sc_search_regexp)
-
-# C guarantees that static variables are zero initialized, and some compilers
-# waste space by sticking explicit initializers in .data instead of .bss
-sc_prohibit_static_zero_init:
-	@prohibit='\bstatic\b.*= *(0[^xX0-9]|NULL|false)'		\
-	in_vc_files='\.[chx](\.in)?$$'					\
-	halt='static variables do not need explicit zero initialization'\
-	  $(_sc_search_regexp)
-
-# FreeBSD exports the "devname" symbol which produces a warning.
-sc_prohibit_devname:
-	@prohibit='\bdevname\b'	\
-	exclude='sc_prohibit_devname' \
-	halt='avoid using 'devname' as FreeBSD exports the symbol' \
-	  $(_sc_search_regexp)
-
-sc_prohibit_system_error_with_vir_err:
-	@prohibit='\bvirReportSystemError *\(VIR_ERR_' \
-	halt='do not use virReportSystemError with VIR_ERR_* error codes' \
-	  $(_sc_search_regexp)
-
-# Rule to prohibit usage of virXXXFree within library, daemon, remote, etc.
-# functions. There's a corresponding exclude to allow usage within tests,
-# docs, examples, tools, src/libvirt-*.c, and include/libvirt/libvirt-*.h
-sc_prohibit_virXXXFree:
-	@prohibit='\bvir(Domain|Network|NodeDevice|StorageVol|StoragePool|Stream|Secret|NWFilter|Interface|DomainSnapshot)Free\b'	\
-	exclude='sc_prohibit_virXXXFree' \
-	halt='avoid using 'virXXXFree', use 'virObjectUnref' instead' \
-	  $(_sc_search_regexp)
-
-sc_prohibit_sysconf_pagesize:
-	@prohibit='sysconf\(_SC_PAGESIZE' \
-	halt='use virGetSystemPageSize[KB] instead of sysconf(_SC_PAGESIZE)' \
-	  $(_sc_search_regexp)
-
-sc_prohibit_pthread_create:
-	@prohibit='\bpthread_create\b' \
-	exclude='sc_prohibit_pthread_create' \
-	halt="avoid using 'pthread_create', use 'virThreadCreate' instead" \
-	  $(_sc_search_regexp)
-
 # We don't use this feature of maint.mk.
 prev_version_file = /dev/null

-ifneq ($(_gl-Makefile),)
 ifeq (0,$(MAKELEVEL))
  _curr_status = .git-module-status
  # The sed filter accommodates those who check out on a commit from which
@@ -1027,13 +695,12 @@ ifeq (0,$(MAKELEVEL))
  # b653eda3ac4864de205419d9f41eec267cb89eeb
  #
  # Keep this logic in sync with autogen.sh.
-  _submodule_hash = $(SED) 's/^[ +-]//;s/ .*//'
+  _submodule_hash = sed 's/^[ +-]//;s/ .*//'
  _update_required := $(shell						\
      cd '$(srcdir)';							\
      test -d .git || { echo 0; exit; };				\
      test -f po/Makevars || { echo 1; exit; };				\
      test -f AUTHORS || { echo 1; exit; };				\
-      test "no-git" = "$$(cat $(_curr_status))" && { echo 0; exit; };	\
      actual=$$(git submodule status | $(_submodule_hash);		\
 		git hash-object bootstrap.conf;				\
 		git ls-tree -d HEAD gnulib/local | awk '{print $$3}';	\
@@ -1047,7 +714,6 @@ ifeq (0,$(MAKELEVEL))
 maint.mk Makefile: _autogen
  endif
 endif
-endif

 # It is necessary to call autogen any time gnulib changes.  Autogen
 # reruns configure, then we regenerate all Makefiles at once.
@@ -1057,49 +723,38 @@ _autogen:
 	./config.status

 # regenerate HACKING as part of the syntax-check
-ifneq ($(_gl-Makefile),)
 syntax-check: $(top_srcdir)/HACKING bracket-spacing-check
-endif

 bracket-spacing-check:
 	$(AM_V_GEN)files=`$(VC_LIST) | grep '\.c$$'`; \
 	$(PERL) $(top_srcdir)/build-aux/bracket-spacing.pl $$files || \
-	  { echo '$(ME): incorrect formatting, see HACKING for rules' 1>&2; \
-	    exit 1; }
+          (echo $(ME): incorrect whitespace around brackets, see HACKING for rules && exit 1)

 # sc_po_check can fail if generated files are not built first
 sc_po_check: \
 		$(srcdir)/daemon/remote_dispatch.h \
 		$(srcdir)/daemon/qemu_dispatch.h \
-		$(srcdir)/src/remote/remote_client_bodies.h \
-		$(srcdir)/daemon/admin_dispatch.h \
-		$(srcdir)/src/admin/admin_client.h
+		$(srcdir)/src/remote/remote_client_bodies.h
 $(srcdir)/daemon/remote_dispatch.h: $(srcdir)/src/remote/remote_protocol.x
 	$(MAKE) -C daemon remote_dispatch.h
 $(srcdir)/daemon/qemu_dispatch.h: $(srcdir)/src/remote/qemu_protocol.x
 	$(MAKE) -C daemon qemu_dispatch.h
 $(srcdir)/src/remote/remote_client_bodies.h: $(srcdir)/src/remote/remote_protocol.x
 	$(MAKE) -C src remote/remote_client_bodies.h
-$(srcdir)/daemon/admin_dispatch.h: $(srcdir)/src/admin/admin_protocol.x
-	$(MAKE) -C daemon admin_dispatch.h
-$(srcdir)/src/admin/admin_client.h: $(srcdir)/src/admin/admin_protocol.x
-	$(MAKE) -C src admin/admin_client.h

 # List all syntax-check exemptions:
-exclude_file_name_regexp--sc_avoid_strcase = ^tools/vsh\.h$$
+exclude_file_name_regexp--sc_avoid_strcase = ^tools/virsh\.h$$

-_src1=libvirt-stream|fdstream|qemu/qemu_monitor|util/(vircommand|virfile)|xen/xend_internal|rpc/virnetsocket|lxc/lxc_controller|locking/lock_daemon
-_test1=shunloadtest|virnettlscontexttest|virnettlssessiontest|vircgroupmock
+_src1=libvirt|fdstream|qemu/qemu_monitor|util/(command|util)|xen/xend_internal|rpc/virnetsocket|lxc/lxc_controller|locking/lock_daemon
 exclude_file_name_regexp--sc_avoid_write = \
-  ^(src/($(_src1))|daemon/libvirtd|tools/virsh-console|tests/($(_test1)))\.c$$
+  ^(src/($(_src1))|daemon/libvirtd|tools/console|tests/(shunload|virnettlscontext)test)\.c$$

 exclude_file_name_regexp--sc_bindtextdomain = ^(tests|examples)/

-exclude_file_name_regexp--sc_copyright_usage = \
-  ^COPYING(|\.LESSER)$$
+exclude_file_name_regexp--sc_copyright_address = \
+  ^COPYING\.LIB$$

-exclude_file_name_regexp--sc_flags_usage = \
-  ^(docs/|src/util/virnetdevtap\.c$$|tests/vir(cgroup|pci|usb)mock\.c$$)
+exclude_file_name_regexp--sc_flags_usage = ^(docs/|src/util/virnetdevtap\.c$$)

 exclude_file_name_regexp--sc_libvirt_unmarked_diagnostics = \
  ^(src/rpc/gendispatch\.pl$$|tests/)
@@ -1107,66 +762,66 @@ exclude_file_name_regexp--sc_libvirt_unmarked_diagnostics = \
 exclude_file_name_regexp--sc_po_check = ^(docs/|src/rpc/gendispatch\.pl$$)

 exclude_file_name_regexp--sc_prohibit_VIR_ERR_NO_MEMORY = \
-  ^(include/libvirt/virterror\.h|daemon/dispatch\.c|src/util/virerror\.c|docs/internals/oomtesting\.html\.in)$$
+  ^(include/libvirt/virterror\.h|daemon/dispatch\.c|src/util/virterror\.c)$$

-exclude_file_name_regexp--sc_prohibit_access_xok = ^src/util/virutil\.c$$
+exclude_file_name_regexp--sc_prohibit_access_xok = ^src/util/util\.c$$
+
+exclude_file_name_regexp--sc_prohibit_always_true_header_tests = \
+  ^python/(libvirt-(qemu-)?override|typewrappers)\.c$$

 exclude_file_name_regexp--sc_prohibit_asprintf = \
-  ^(bootstrap.conf$$|src/util/virstring\.[ch]$$|tests/vircgroupmock\.c$$)
-
-exclude_file_name_regexp--sc_prohibit_strdup = \
-  ^(docs/|examples/|src/util/virstring\.c|tests/vir(netserverclient|cgroup)mock.c$$)
+  ^(bootstrap.conf$$|src/util/util\.c$$|examples/domain-events/events-c/event-test\.c$$)

 exclude_file_name_regexp--sc_prohibit_close = \
-  (\.p[yl]$$|\.spec\.in$$|^docs/|^(src/util/virfile\.c|src/libvirt-stream\.c|tests/vir(cgroup|pci)mock\.c)$$)
+  (\.p[yl]$$|^docs/|^(src/util/virfile\.c|src/libvirt\.c)$$)

 exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF = \
-  (^tests/(qemuhelp|nodeinfo|virpcitest)data/|\.diff$$)
+  (^tests/(qemuhelp|nodeinfo)data/|\.(gif|ico|png|diff)$$)

-_src2=src/(util/vircommand|libvirt|lxc/lxc_controller|locking/lock_daemon)
+_src2=src/(util/command|libvirt|lxc/lxc_controller|locking/lock_daemon)
 exclude_file_name_regexp--sc_prohibit_fork_wrappers = \
  (^($(_src2)|tests/testutils|daemon/libvirtd)\.c$$)

-exclude_file_name_regexp--sc_prohibit_gethostname = ^src/util/virutil\.c$$
+exclude_file_name_regexp--sc_prohibit_gethostname = ^src/util/util\.c$$

 exclude_file_name_regexp--sc_prohibit_internal_functions = \
-  ^src/(util/(viralloc|virutil|virfile)\.[hc]|esx/esx_vi\.c)$$
+  ^src/(util/(memory|util|virfile)\.[hc]|esx/esx_vi\.c)$$

 exclude_file_name_regexp--sc_prohibit_newline_at_end_of_diagnostic = \
  ^src/rpc/gendispatch\.pl$$

 exclude_file_name_regexp--sc_prohibit_nonreentrant = \
-  ^((po|tests)/|docs/.*(py|html\.in)|run.in$$|tools/wireshark/util/genxdrstub\.pl$$)
+  ^((po|tests)/|docs/.*py|run.in$$)

 exclude_file_name_regexp--sc_prohibit_raw_allocation = \
-  ^(docs/hacking\.html\.in|src/util/viralloc\.[ch]|examples/.*|tests/(securityselinuxhelper|vircgroupmock)\.c|tools/wireshark/src/packet-libvirt\.c)$$
+  ^(src/util/memory\.[ch]|examples/.*)$$

 exclude_file_name_regexp--sc_prohibit_readlink = \
-  ^src/(util/virutil|lxc/lxc_container)\.c$$
+  ^src/(util/util|lxc/lxc_container)\.c$$

-exclude_file_name_regexp--sc_prohibit_setuid = ^src/util/virutil\.c$$
+exclude_file_name_regexp--sc_prohibit_setuid = ^src/util/util\.c$$

 exclude_file_name_regexp--sc_prohibit_sprintf = \
-  (^docs/hacking\.html\.in|\.stp|\.pl)$$
+  ^(docs/hacking\.html\.in)|(examples/systemtap/.*stp)|(src/dtrace2systemtap\.pl)|(src/rpc/gensystemtap\.pl)$$

-exclude_file_name_regexp--sc_prohibit_strncpy = ^src/util/virstring\.c$$
+exclude_file_name_regexp--sc_prohibit_strncpy = ^src/util/util\.c$$

-exclude_file_name_regexp--sc_prohibit_strtol = ^examples/dom.*/.*\.c$$
+exclude_file_name_regexp--sc_prohibit_strtol = \
+  ^src/(util/sexpr|(vbox|xen|xenxs)/.*)\.c$$

-exclude_file_name_regexp--sc_prohibit_xmlGetProp = ^src/util/virxml\.c$$
+exclude_file_name_regexp--sc_prohibit_xmlGetProp = ^src/util/xml\.c$$

 exclude_file_name_regexp--sc_prohibit_xmlURI = ^src/util/viruri\.c$$

 exclude_file_name_regexp--sc_prohibit_return_as_function = \.py$$

-exclude_file_name_regexp--sc_require_config_h = \
-	^(examples/|tools/virsh-edit\.c$$)
+_virsh_includes=(edit|domain-monitor|domain|volume|pool|network|interface|nwfilter|secret|snapshot|host|nodedev)
+exclude_file_name_regexp--sc_require_config_h = ^(examples/|tools/virsh-$(_virsh_includes)\.c$$)

-exclude_file_name_regexp--sc_require_config_h_first = \
-	^(examples/|tools/virsh-edit\.c$$)
+exclude_file_name_regexp--sc_require_config_h_first = ^(examples/|tools/virsh-$(_virsh_includes)\.c$$)

 exclude_file_name_regexp--sc_trailing_blank = \
-  /qemuhelpdata/|/sysinfodata/.*\.data|/nodeinfodata/.*\.cpuinfo$$
+  (/qemuhelpdata/|\.(fig|gif|ico|png)$$)

 exclude_file_name_regexp--sc_unmarked_diagnostics = \
  ^(docs/apibuild.py|tests/virt-aa-helper-test)$$
@@ -1175,41 +830,3 @@ exclude_file_name_regexp--sc_size_of_brackets = cfg.mk

 exclude_file_name_regexp--sc_correct_id_types = \
  (^src/locking/lock_protocol.x$$)
-
-exclude_file_name_regexp--sc_m4_quote_check = m4/virt-lib.m4
-
-exclude_file_name_regexp--sc_prohibit_include_public_headers_quote = \
-  ^(src/internal\.h$$|tools/wireshark/src/packet-libvirt.h$$)
-
-exclude_file_name_regexp--sc_prohibit_include_public_headers_brackets = \
-  ^(tools/|examples/|include/libvirt/(virterror|libvirt-(qemu|lxc))\.h$$)
-
-exclude_file_name_regexp--sc_prohibit_int_ijk = \
-  ^(src/remote_protocol-structs|src/remote/remote_protocol.x|cfg.mk|include/)$
-
-exclude_file_name_regexp--sc_prohibit_getenv = \
-  ^tests/.*\.[ch]$$
-
-exclude_file_name_regexp--sc_avoid_attribute_unused_in_header = \
-  ^(src/util/virlog\.h|src/network/bridge_driver\.h)$$
-
-exclude_file_name_regexp--sc_prohibit_mixed_case_abbreviations = \
-  ^src/(vbox/vbox_CAPI.*.h|esx/esx_vi.(c|h)|esx/esx_storage_backend_iscsi.c)$$
-
-exclude_file_name_regexp--sc_prohibit_empty_first_line = \
-  ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/(vmwarever|nodeinfo)data/.*)$$
-
-exclude_file_name_regexp--sc_prohibit_useless_translation = \
-  ^tests/virpolkittest.c
-
-exclude_file_name_regexp--sc_prohibit_devname = \
-  ^(tools/virsh.pod|cfg.mk|docs/.*)$$
-
-exclude_file_name_regexp--sc_prohibit_virXXXFree = \
-  ^(docs/|tests/|examples/|tools/|cfg.mk|src/test/test_driver.c|src/libvirt_public.syms|include/libvirt/libvirt-(domain|network|nodedev|storage|stream|secret|nwfilter|interface|domain-snapshot).h|src/libvirt-(domain|qemu|network|nodedev|storage|stream|secret|nwfilter|interface|domain-snapshot).c$$)
-
-exclude_file_name_regexp--sc_prohibit_sysconf_pagesize = \
-  ^(cfg\.mk|src/util/virutil\.c)$$
-
-exclude_file_name_regexp--sc_prohibit_pthread_create = \
-  ^(cfg\.mk|src/util/virthread\.c|tests/.*)$$
--- a/config-post.h
+++ b/config-post.h
@@ -1,45 +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/>.
- */
-
-/*
- * Since virt-login-shell will be setuid, we must do everything
- * we can to avoid linking to other libraries. Many of them do
- * unsafe things in functions marked __atttribute__((constructor)).
- * The only way avoid to avoid such deps is to re-compile the
- * functions with the code in question disabled, and for that we
- * must override the main config.h rules. Hence this file :-(
- */
-
-#ifdef LIBVIRT_SETUID_RPC_CLIENT
-# undef HAVE_LIBDEVMAPPER_H
-# undef HAVE_LIBNL
-# undef HAVE_LIBNL3
-# undef HAVE_LIBSASL2
-# undef WITH_CAPNG
-# undef WITH_CURL
-# undef WITH_DTRACE_PROBES
-# undef WITH_GNUTLS
-# undef WITH_GNUTLS_GCRYPT
-# undef WITH_MACVTAP
-# undef WITH_NUMACTL
-# undef WITH_SASL
-# undef WITH_SSH2
-# undef WITH_VIRTUALPORT
-# undef WITH_YAJL
-# undef WITH_YAJL2
-#endif
--- a/configure.ac
+++ b/configure.ac
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -1,152 +1,72 @@
 ## Process this file with automake to produce Makefile.in

-## Copyright (C) 2005-2015 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/>.
+## Copyright (C) 2005-2012 Red Hat, Inc.
+## See COPYING.LIB for the License of this software

 INCLUDES = \
 	-I$(top_builddir)/gnulib/lib -I$(top_srcdir)/gnulib/lib \
-	-I$(top_srcdir) \
 	-I$(top_builddir)/include -I$(top_srcdir)/include \
 	-I$(top_builddir)/src -I$(top_srcdir)/src \
 	-I$(top_srcdir)/src/util \
 	-I$(top_srcdir)/src/conf \
 	-I$(top_srcdir)/src/rpc \
 	-I$(top_srcdir)/src/remote \
-	-I$(top_srcdir)/src/admin \
-	-I$(top_srcdir)/src/access \
 	$(GETTEXT_CPPFLAGS)

 CLEANFILES =

-DAEMON_GENERATED =			\
-		remote_dispatch.h	\
-		lxc_dispatch.h		\
-		qemu_dispatch.h		\
-		admin_dispatch.h	\
-		$(NULL)
+DAEMON_GENERATED =					\
+		$(srcdir)/remote_dispatch.h		\
+		$(srcdir)/qemu_dispatch.h

 DAEMON_SOURCES =					\
 		libvirtd.c libvirtd.h			\
+		libvirtd-config.c libvirtd-config.h	\
 		remote.c remote.h			\
 		stream.c stream.h			\
+		../src/remote/remote_protocol.c		\
+		../src/remote/qemu_protocol.c		\
 		$(DAEMON_GENERATED)

-LIBVIRTD_CONF_SOURCES = libvirtd-config.c libvirtd-config.h
-
 DISTCLEANFILES =
 EXTRA_DIST =						\
 	remote_dispatch.h				\
-	lxc_dispatch.h					\
 	qemu_dispatch.h					\
-	admin_dispatch.h				\
 	libvirtd.conf					\
 	libvirtd.init.in				\
 	libvirtd.upstart				\
 	libvirtd.policy.in				\
-	libvirt.rules					\
 	libvirtd.sasl					\
-	libvirtd.service.in				\
-	libvirtd.socket.in				\
 	libvirtd.sysconf				\
 	libvirtd.sysctl					\
 	libvirtd.aug                                    \
 	libvirtd.logrotate.in                           \
 	libvirtd.qemu.logrotate.in                      \
 	libvirtd.lxc.logrotate.in                       \
-	libvirtd.libxl.logrotate.in                     \
 	libvirtd.uml.logrotate.in                       \
 	test_libvirtd.aug.in                             \
 	THREADS.txt					\
 	libvirtd.pod.in					\
 	libvirtd.8.in					\
-	$(DAEMON_SOURCES)				\
-	$(LIBVIRTD_CONF_SOURCES)			\
-	$(NULL)
+	$(DAEMON_SOURCES)

 BUILT_SOURCES =

 REMOTE_PROTOCOL = $(top_srcdir)/src/remote/remote_protocol.x
-LXC_PROTOCOL = $(top_srcdir)/src/remote/lxc_protocol.x
 QEMU_PROTOCOL = $(top_srcdir)/src/remote/qemu_protocol.x
-ADMIN_PROTOCOL = $(top_srcdir)/src/admin/admin_protocol.x

-remote_dispatch.h: $(top_srcdir)/src/rpc/gendispatch.pl \
+$(srcdir)/remote_dispatch.h: $(srcdir)/../src/rpc/gendispatch.pl \
 		$(REMOTE_PROTOCOL)
-	$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
-	  --mode=server remote REMOTE $(REMOTE_PROTOCOL) \
-	  > $(srcdir)/remote_dispatch.h
+	$(AM_V_GEN)$(PERL) -w $(srcdir)/../src/rpc/gendispatch.pl -b remote REMOTE \
+	  $(REMOTE_PROTOCOL) > $@

-lxc_dispatch.h: $(top_srcdir)/src/rpc/gendispatch.pl \
-		$(LXC_PROTOCOL)
-	$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
-	  --mode=server lxc LXC $(LXC_PROTOCOL) \
-	  > $(srcdir)/lxc_dispatch.h
-
-qemu_dispatch.h: $(top_srcdir)/src/rpc/gendispatch.pl \
+$(srcdir)/qemu_dispatch.h: $(srcdir)/../src/rpc/gendispatch.pl \
 		$(QEMU_PROTOCOL)
-	$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
-	  --mode=server qemu QEMU $(QEMU_PROTOCOL) \
-	  > $(srcdir)/qemu_dispatch.h
-
-admin_dispatch.h: $(top_srcdir)/src/rpc/gendispatch.pl \
-		$(ADMIN_PROTOCOL)
-	$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
-	  --mode=server admin ADMIN $(ADMIN_PROTOCOL) \
-	  > $(srcdir)/admin_dispatch.h
+	$(AM_V_GEN)$(PERL) -w $(srcdir)/../src/rpc/gendispatch.pl -b qemu QEMU \
+	  $(QEMU_PROTOCOL) > $@

 if WITH_LIBVIRTD

-# Build a convenience library, for reuse in tests/libvirtdconftest
-noinst_LTLIBRARIES = libvirtd_conf.la
-libvirtd_conf_la_SOURCES = $(LIBVIRTD_CONF_SOURCES)
-libvirtd_conf_la_CFLAGS = \
-	$(LIBXML_CFLAGS) \
-	$(XDR_CFLAGS) \
-	$(WARN_CFLAGS) $(PIE_CFLAGS) \
-	$(COVERAGE_CFLAGS) \
-	$(NULL)
-libvirtd_conf_la_LDFLAGS =				\
-	$(RELRO_LDFLAGS)				\
-	$(PIE_LDFLAGS)					\
-	$(COVERAGE_LDFLAGS)				\
-	$(NO_INDIRECT_LDFLAGS)				\
-	$(NULL)
-libvirtd_conf_la_LIBADD = $(LIBXML_LIBS)
-
-noinst_LTLIBRARIES += libvirtd_admin.la
-libvirtd_admin_la_SOURCES = \
-		admin_server.c admin_server.h
-
-libvirtd_admin_la_CFLAGS = \
-		$(AM_CFLAGS)		\
-		$(XDR_CFLAGS)		\
-		$(PIE_CFLAGS)		\
-		$(WARN_CFLAGS)		\
-		$(LIBXML_CFLAGS)	\
-		$(COVERAGE_CFLAGS)	\
-		$(NULL)
-libvirtd_admin_la_LDFLAGS = \
-		$(PIE_LDFLAGS)		\
-		$(RELRO_LDFLAGS)	\
-		$(COVERAGE_LDFLAGS)	\
-		$(NO_INDIRECT_LDFLAGS)  \
-		$(NULL)
-libvirtd_admin_la_LIBADD =	\
-		../src/libvirt-admin.la
-
 man8_MANS = libvirtd.8

 sbin_PROGRAMS = libvirtd
@@ -164,8 +84,8 @@ CLEANFILES += test_libvirtd.aug

 libvirtd.8: $(srcdir)/libvirtd.8.in
 	$(AM_V_GEN)sed \
-	    -e 's|[@]sysconfdir[@]|$(sysconfdir)|g' \
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g' \
+	    -e 's!SYSCONFDIR!$(sysconfdir)!g' \
+	    -e 's!LOCALSTATEDIR!$(localstatedir)!g' \
 	    < $< > $@-t && \
 	mv $@-t $@

@@ -174,186 +94,153 @@ libvirtd_SOURCES = $(DAEMON_SOURCES)
 #-D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_C_SOURCE=199506L
 libvirtd_CFLAGS = \
 	$(LIBXML_CFLAGS) $(GNUTLS_CFLAGS) $(SASL_CFLAGS) \
-	$(XDR_CFLAGS) $(DBUS_CFLAGS) $(LIBNL_CFLAGS) \
-	$(WARN_CFLAGS) $(PIE_CFLAGS) \
+	$(XDR_CFLAGS) $(POLKIT_CFLAGS) $(DBUS_CFLAGS) $(LIBNL_CFLAGS) \
+	$(WARN_CFLAGS) \
 	$(COVERAGE_CFLAGS) \
 	-DQEMUD_PID_FILE="\"$(QEMUD_PID_FILE)\""

 libvirtd_LDFLAGS =					\
-	$(RELRO_LDFLAGS)				\
-	$(PIE_LDFLAGS)					\
-	$(COVERAGE_LDFLAGS)				\
-	$(NO_INDIRECT_LDFLAGS)				\
-	$(NULL)
+	$(WARN_CFLAGS)					\
+	$(COVERAGE_LDFLAGS)

 libvirtd_LDADD =					\
 	$(LIBXML_LIBS)					\
 	$(GNUTLS_LIBS)					\
 	$(SASL_LIBS)					\
 	$(DBUS_LIBS)					\
+	$(POLKIT_LIBS)					\
 	$(LIBNL_LIBS)

 if WITH_DTRACE_PROBES
 libvirtd_LDADD += ../src/libvirt_probes.lo
-endif WITH_DTRACE_PROBES
+endif

 libvirtd_LDADD += \
-	libvirtd_conf.la \
-	libvirtd_admin.la \
-	../src/libvirt-lxc.la \
-	../src/libvirt-qemu.la \
-	../src/libvirt_driver_remote.la \
-	$(NULL)
+	../src/libvirt-qemu.la

 if ! WITH_DRIVER_MODULES
 if WITH_QEMU
    libvirtd_LDADD += ../src/libvirt_driver_qemu.la
 if WITH_DTRACE_PROBES
    libvirtd_LDADD += ../src/libvirt_qemu_probes.lo
-endif WITH_DTRACE_PROBES
-endif WITH_QEMU
+endif
+endif

 if WITH_LXC
    libvirtd_LDADD += ../src/libvirt_driver_lxc.la
-endif WITH_LXC
+endif

 if WITH_XEN
    libvirtd_LDADD += ../src/libvirt_driver_xen.la
-endif WITH_XEN
+endif

 if WITH_LIBXL
    libvirtd_LDADD += ../src/libvirt_driver_libxl.la
-endif WITH_LIBXL
+endif

 if WITH_UML
    libvirtd_LDADD += ../src/libvirt_driver_uml.la
-endif WITH_UML
-
-if WITH_VBOX
-    libvirtd_LDADD += ../src/libvirt_driver_vbox.la
-endif WITH_VBOX
+endif

 if WITH_STORAGE
    libvirtd_LDADD += ../src/libvirt_driver_storage.la
-endif WITH_STORAGE
+endif

 if WITH_NETWORK
    libvirtd_LDADD += ../src/libvirt_driver_network.la
-endif WITH_NETWORK
+endif

 if WITH_INTERFACE
    libvirtd_LDADD += ../src/libvirt_driver_interface.la
-endif WITH_INTERFACE
+endif

 if WITH_NODE_DEVICES
    libvirtd_LDADD += ../src/libvirt_driver_nodedev.la
-endif WITH_NODE_DEVICES
+endif

 if WITH_SECRETS
    libvirtd_LDADD += ../src/libvirt_driver_secret.la
-endif WITH_SECRETS
+endif

 if WITH_NWFILTER
    libvirtd_LDADD += ../src/libvirt_driver_nwfilter.la
-endif WITH_NWFILTER
-endif ! WITH_DRIVER_MODULES
+endif
+endif

 libvirtd_LDADD += ../src/libvirt.la

-if WITH_POLKIT
-if WITH_POLKIT0
+if HAVE_POLKIT
+if HAVE_POLKIT0
 policydir = $(datadir)/PolicyKit/policy
 policyauth = auth_admin_keep_session
-else ! WITH_POLKIT0
+else
 policydir = $(datadir)/polkit-1/actions
 policyauth = auth_admin_keep
-rulesdir = $(datadir)/polkit-1/rules.d
-rulesfile = libvirt.rules
-endif ! WITH_POLKIT0
-endif WITH_POLKIT
+endif
+endif

 libvirtd.policy: libvirtd.policy.in $(top_builddir)/config.status
 	$(AM_V_GEN) sed \
-	    -e 's|[@]authaction[@]|$(policyauth)|g' \
+	    -e 's![@]authaction[@]!$(policyauth)!g' \
 	    < $< > $@-t && \
 	mv $@-t $@
 BUILT_SOURCES += libvirtd.policy

-install-data-local: install-init-redhat install-init-systemd \
-		install-init-upstart \
+install-data-local: install-init-redhat install-init-systemd install-init-upstart \
 		install-data-sasl install-data-polkit \
 		install-logrotate install-sysctl
 	$(MKDIR_P) $(DESTDIR)$(localstatedir)/log/libvirt \
 		   $(DESTDIR)$(localstatedir)/run/libvirt \
 		   $(DESTDIR)$(localstatedir)/lib/libvirt

-uninstall-local:: uninstall-init-redhat uninstall-init-systemd \
-		uninstall-init-upstart \
+uninstall-local:: uninstall-init-redhat uninstall-init-systemd uninstall-init-upstart \
 		uninstall-data-sasl uninstall-data-polkit \
 		uninstall-logrotate uninstall-sysctl
 	rmdir $(DESTDIR)$(localstatedir)/log/libvirt || :
 	rmdir $(DESTDIR)$(localstatedir)/run/libvirt || :
 	rmdir $(DESTDIR)$(localstatedir)/lib/libvirt || :

-if WITH_POLKIT
+if HAVE_POLKIT
 install-data-polkit::
 	$(MKDIR_P) $(DESTDIR)$(policydir)
 	$(INSTALL_DATA) libvirtd.policy $(DESTDIR)$(policydir)/org.libvirt.unix.policy
-if ! WITH_POLKIT0
-	$(MKDIR_P) $(DESTDIR)$(rulesdir)
-	$(INSTALL_DATA) $(srcdir)/$(rulesfile) $(DESTDIR)$(rulesdir)/50-libvirt.rules
-endif ! WITH_POLKIT0
-
 uninstall-data-polkit::
 	rm -f $(DESTDIR)$(policydir)/org.libvirt.unix.policy
 	rmdir $(DESTDIR)$(policydir) || :
-if ! WITH_POLKIT0
-	rm -f $(DESTDIR)$(rulesdir)/50-libvirt.rules
-	rmdir $(DESTDIR)$(rulesdir) || :
-endif ! WITH_POLKIT0
-
-else ! WITH_POLKIT
+else
 install-data-polkit::
 uninstall-data-polkit::
-endif ! WITH_POLKIT
+endif

 remote.c: $(DAEMON_GENERATED)
 remote.h: $(DAEMON_GENERATED)
-admin_server.c: $(DAEMON_GENERATED)

 LOGROTATE_CONFS = libvirtd.qemu.logrotate libvirtd.lxc.logrotate \
-		  libvirtd.libxl.logrotate libvirtd.uml.logrotate \
-		  libvirtd.logrotate
+		  libvirtd.uml.logrotate libvirtd.logrotate

 BUILT_SOURCES += $(LOGROTATE_CONFS)

 libvirtd.logrotate: libvirtd.logrotate.in
 	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
+	    -e 's![@]localstatedir[@]!$(localstatedir)!g'	\
 	    < $< > $@-t && \
 	mv $@-t $@

 libvirtd.qemu.logrotate: libvirtd.qemu.logrotate.in
 	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
+	    -e 's![@]localstatedir[@]!$(localstatedir)!g'	\
 	    < $< > $@-t && \
 	mv $@-t $@

 libvirtd.lxc.logrotate: libvirtd.lxc.logrotate.in
 	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
-	    < $< > $@-t &&					\
-	    mv $@-t $@
-
-libvirtd.libxl.logrotate: libvirtd.libxl.logrotate.in
-	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
+	    -e 's![@]localstatedir[@]!$(localstatedir)!g'	\
 	    < $< > $@-t &&					\
 	    mv $@-t $@

 libvirtd.uml.logrotate: libvirtd.uml.logrotate.in
 	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
+	    -e 's![@]localstatedir[@]!$(localstatedir)!g'	\
 	    < $< > $@-t &&					\
 	    mv $@-t $@

@@ -362,22 +249,15 @@ install-logrotate: $(LOGROTATE_CONFS)
 		   $(DESTDIR)$(localstatedir)/log/libvirt/lxc/ \
 		   $(DESTDIR)$(localstatedir)/log/libvirt/uml/ \
 		   $(DESTDIR)$(sysconfdir)/logrotate.d/
-	$(INSTALL_DATA) libvirtd.logrotate \
-		$(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd
-	$(INSTALL_DATA) libvirtd.qemu.logrotate \
-		$(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.qemu
-	$(INSTALL_DATA) libvirtd.lxc.logrotate \
-		$(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.lxc
-	$(INSTALL_DATA) libvirtd.libxl.logrotate \
-		$(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.libxl
-	$(INSTALL_DATA) libvirtd.uml.logrotate \
-		$(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.uml
+	$(INSTALL_DATA) libvirtd.logrotate $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd
+	$(INSTALL_DATA) libvirtd.qemu.logrotate $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.qemu
+	$(INSTALL_DATA) libvirtd.lxc.logrotate $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.lxc
+	$(INSTALL_DATA) libvirtd.uml.logrotate $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.uml

 uninstall-logrotate:
 	rm -f $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd \
 	      $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.qemu \
 	      $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.lxc \
-	      $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.libxl \
 	      $(DESTDIR)$(sysconfdir)/logrotate.d/libvirtd.uml
 	rmdir $(DESTDIR)$(localstatedir)/log/libvirt/qemu || :
 	rmdir $(DESTDIR)$(localstatedir)/log/libvirt/lxc || :
@@ -393,20 +273,18 @@ uninstall-sysconfig:
 	rmdir $(DESTDIR)$(sysconfdir)/sysconfig || :

 if WITH_SYSCTL
-# Use $(prefix)/lib rather than $(libdir), since man sysctl.d insists on
-# /usr/lib/sysctl.d/ even when libdir is /usr/lib64
 install-sysctl:
-	$(MKDIR_P) $(DESTDIR)$(prefix)/lib/sysctl.d
+	$(MKDIR_P) $(DESTDIR)$(sysconfdir)/sysctl.d
 	$(INSTALL_DATA) $(srcdir)/libvirtd.sysctl \
-	  $(DESTDIR)$(prefix)/lib/sysctl.d/60-libvirtd.conf
+	  $(DESTDIR)$(sysconfdir)/sysctl.d/libvirtd

 uninstall-sysctl:
-	rm -f $(DESTDIR)$(prefix)/lib/sysctl.d/60-libvirtd.conf
-	rmdir $(DESTDIR)$(prefix)/lib/sysctl.d || :
-else ! WITH_SYSCTL
+	rm -f $(DESTDIR)$(sysconfdir)/sysctl.d/libvirtd
+	rmdir $(DESTDIR)$(sysconfdir)/sysctl.d || :
+else
 install-sysctl:
 uninstall-sysctl:
-endif ! WITH_SYSCTL
+endif

 if LIBVIRT_INIT_SCRIPT_RED_HAT

@@ -420,10 +298,10 @@ install-init-redhat: install-sysconfig libvirtd.init
 uninstall-init-redhat: uninstall-sysconfig
 	rm -f $(DESTDIR)$(sysconfdir)/rc.d/init.d/libvirtd
 	rmdir $(DESTDIR)$(sysconfdir)/rc.d/init.d || :
-else ! LIBVIRT_INIT_SCRIPT_RED_HAT
+else
 install-init-redhat:
 uninstall-init-redhat:
-endif ! LIBVIRT_INIT_SCRIPT_RED_HAT
+endif # LIBVIRT_INIT_SCRIPT_RED_HAT


 if LIBVIRT_INIT_SCRIPT_UPSTART
@@ -436,54 +314,47 @@ install-init-upstart: install-sysconfig
 uninstall-init-upstart: uninstall-sysconfig
 	rm -f $(DESTDIR)$(sysconfdir)/event.d/libvirtd
 	rmdir $(DESTDIR)$(sysconfdir)/event.d || :
-else ! LIBVIRT_INIT_SCRIPT_UPSTART
+else
 install-init-upstart:
 uninstall-init-upstart:
-endif ! LIBVIRT_INIT_SCRIPT_UPSTART
+endif # LIBVIRT_INIT_SCRIPT_UPSTART


+EXTRA_DIST += libvirtd.service.in
 if LIBVIRT_INIT_SCRIPT_SYSTEMD

-SYSTEMD_UNIT_DIR = $(prefix)/lib/systemd/system
-BUILT_SOURCES += libvirtd.service libvirtd.socket
+SYSTEMD_UNIT_DIR = /lib/systemd/system
+BUILT_SOURCES += libvirtd.service

-install-init-systemd: install-sysconfig libvirtd.service libvirtd.socket
+install-init-systemd: install-sysconfig libvirtd.service
 	$(MKDIR_P) $(DESTDIR)$(SYSTEMD_UNIT_DIR)
 	$(INSTALL_DATA) libvirtd.service \
 	  $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.service
-	$(INSTALL_DATA) libvirtd.socket \
-	  $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.socket

 uninstall-init-systemd: uninstall-sysconfig
 	rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.service
-	rm -f $(DESTDIR)$(SYSTEMD_UNIT_DIR)/libvirtd.socket
 	rmdir $(DESTDIR)$(SYSTEMD_UNIT_DIR) || :
-else ! LIBVIRT_INIT_SCRIPT_SYSTEMD
+else
 install-init-systemd:
 uninstall-init-systemd:
-endif ! LIBVIRT_INIT_SCRIPT_SYSTEMD
+endif # LIBVIRT_INIT_SCRIPT_SYSTEMD

 libvirtd.init: libvirtd.init.in $(top_builddir)/config.status
-	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
-	    -e 's|[@]sbindir[@]|$(sbindir)|g'			\
-	    -e 's|[@]sysconfdir[@]|$(sysconfdir)|g'		\
-	    < $< > $@-t &&					\
-	    chmod a+x $@-t &&					\
+	$(AM_V_GEN)sed					\
+	    -e s!\@localstatedir\@!$(localstatedir)!g	\
+	    -e s!\@sbindir\@!$(sbindir)!g		\
+	    -e s!\@sysconfdir\@!$(sysconfdir)!g		\
+	    < $< > $@-t &&				\
+	    chmod a+x $@-t &&				\
 	    mv $@-t $@

 libvirtd.service: libvirtd.service.in $(top_builddir)/config.status
-	$(AM_V_GEN)sed						\
-	    -e 's|[@]localstatedir[@]|$(localstatedir)|g'	\
-	    -e 's|[@]sbindir[@]|$(sbindir)|g'			\
-	    -e 's|[@]sysconfdir[@]|$(sysconfdir)|g'		\
-	    < $< > $@-t &&					\
-	    mv $@-t $@
-
-libvirtd.socket: libvirtd.socket.in $(top_builddir)/config.status
-	$(AM_V_GEN)sed						\
-	    -e 's|[@]runstatedir[@]|$(runstatedir)|g'		\
-	    < $< > $@-t &&					\
+	$(AM_V_GEN)sed					\
+	    -e s!\@localstatedir\@!$(localstatedir)!g	\
+	    -e s!\@sbindir\@!$(sbindir)!g		\
+	    -e s!\@sysconfdir\@!$(sysconfdir)!g		\
+	    < $< > $@-t &&				\
+	    chmod a+x $@-t &&				\
 	    mv $@-t $@


@@ -504,33 +375,32 @@ check-augeas: test_libvirtd.aug
 # are used by nearly every other library.
 libvirtd_LDADD += ../gnulib/lib/libgnu.la $(LIBSOCKET)

-else ! WITH_LIBVIRTD
+else # WITH_LIBVIRTD
 install-data-local: install-data-sasl
 uninstall-local:: uninstall-data-sasl
-endif ! WITH_LIBVIRTD
+endif # WITH_LIBVIRTD

 POD2MAN = pod2man -c "Virtualization Support" \
 			-r "$(PACKAGE)-$(VERSION)" -s 8

-$(srcdir)/libvirtd.8.in: libvirtd.pod.in $(top_srcdir)/configure.ac
+$(srcdir)/libvirtd.8.in: libvirtd.pod.in
 	$(AM_V_GEN)$(POD2MAN) --name LIBVIRTD $< $@ \
 	    && if grep 'POD ERROR' $@ ; then rm $@; exit 1; fi

 # This is needed for clients too, so can't wrap in
 # the WITH_LIBVIRTD conditional
-if WITH_SASL
+if HAVE_SASL
 install-data-sasl:
 	$(MKDIR_P) $(DESTDIR)$(sysconfdir)/sasl2/
-	$(INSTALL_DATA) $(srcdir)/libvirtd.sasl \
-		$(DESTDIR)$(sysconfdir)/sasl2/libvirt.conf
+	$(INSTALL_DATA) $(srcdir)/libvirtd.sasl $(DESTDIR)$(sysconfdir)/sasl2/libvirt.conf

 uninstall-data-sasl:
 	rm -f $(DESTDIR)$(sysconfdir)/sasl2/libvirt.conf
 	rmdir $(DESTDIR)$(sysconfdir)/sasl2/ || :
-else ! WITH_SASL
+else
 install-data-sasl:
 uninstall-data-sasl:
-endif ! WITH_SASL
+endif


 CLEANFILES += $(BUILT_SOURCES) $(man8_MANS)
--- a/daemon/THREADS.txt
+++ b/daemon/THREADS.txt
@@ -40,7 +40,7 @@ The server lock is used in conjunction with a condition variable
 to pass jobs from the event loop thread to the workers. The main
 event loop thread handles I/O from the client socket, and once a
 complete RPC message has been read off the wire (and optionally
-decrypted), it will be placed on the 'dx' job queue for the
+decrypted), it will be placed onto the 'dx' job queue for the
 associated client object. The job condition will be signalled and
 a worker will wakup and process it.

--- a/daemon/admin_server.c
+++ b/daemon/admin_server.c
@@ -1,117 +0,0 @@
-/*
- * admin_server.c:
- *
- * Copyright (C) 2014-2015 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/>.
- *
- * Author: Martin Kletzander <mkletzan@redhat.com>
- */
-
-#include <config.h>
-
-#include "internal.h"
-#include "libvirtd.h"
-#include "libvirt_internal.h"
-
-#include "admin_protocol.h"
-#include "admin_server.h"
-#include "datatypes.h"
-#include "viralloc.h"
-#include "virerror.h"
-#include "virlog.h"
-#include "virnetdaemon.h"
-#include "virnetserver.h"
-#include "virstring.h"
-#include "virthreadjob.h"
-
-#define VIR_FROM_THIS VIR_FROM_ADMIN
-
-VIR_LOG_INIT("daemon.admin");
-
-
-void
-remoteAdmClientFreeFunc(void *data)
-{
-    struct daemonAdmClientPrivate *priv = data;
-
-    virMutexDestroy(&priv->lock);
-    virObjectUnref(priv->dmn);
-    VIR_FREE(priv);
-}
-
-void *
-remoteAdmClientInitHook(virNetServerClientPtr client ATTRIBUTE_UNUSED,
-                        void *opaque)
-{
-    struct daemonAdmClientPrivate *priv;
-
-    if (VIR_ALLOC(priv) < 0)
-        return NULL;
-
-    if (virMutexInit(&priv->lock) < 0) {
-        VIR_FREE(priv);
-        virReportSystemError(errno, "%s", _("unable to init mutex"));
-        return NULL;
-    }
-
-    /*
-     * We don't necessarily need to ref this object right now as there
-     * must be one ref being held throughout the life of the daemon,
-     * but let's just be safe for future.
-     */
-    priv->dmn = virObjectRef(opaque);
-
-    return priv;
-}
-
-/* Functions */
-static int
-adminDispatchConnectOpen(virNetServerPtr server ATTRIBUTE_UNUSED,
-                         virNetServerClientPtr client,
-                         virNetMessagePtr msg ATTRIBUTE_UNUSED,
-                         virNetMessageErrorPtr rerr,
-                         struct admin_connect_open_args *args)
-{
-    unsigned int flags;
-    struct daemonAdmClientPrivate *priv =
-        virNetServerClientGetPrivateData(client);
-    int ret = -1;
-
-    VIR_DEBUG("priv=%p dmn=%p", priv, priv->dmn);
-    virMutexLock(&priv->lock);
-
-    flags = args->flags;
-    virCheckFlagsGoto(0, cleanup);
-
-    ret = 0;
- cleanup:
-    if (ret < 0)
-        virNetMessageSaveError(rerr);
-    virMutexUnlock(&priv->lock);
-    return ret;
-}
-
-static int
-adminDispatchConnectClose(virNetServerPtr server ATTRIBUTE_UNUSED,
-                          virNetServerClientPtr client,
-                          virNetMessagePtr msg ATTRIBUTE_UNUSED,
-                          virNetMessageErrorPtr rerr ATTRIBUTE_UNUSED)
-{
-    virNetServerClientDelayedClose(client);
-    return 0;
-}
-
-#include "admin_dispatch.h"
--- a/daemon/admin_server.h
+++ b/daemon/admin_server.h
@@ -1,36 +0,0 @@
-/*
- * admin_server.h
- *
- * Copyright (C) 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 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/>.
- *
- * Author: Martin Kletzander <mkletzan@redhat.com>
- */
-
-#ifndef __LIBVIRTD_ADMIN_H__
-# define __LIBVIRTD_ADMIN_H__
-
-# include "rpc/virnetserverprogram.h"
-# include "rpc/virnetserverclient.h"
-
-
-extern virNetServerProgramProc adminProcs[];
-extern size_t adminNProcs;
-
-void remoteAdmClientFreeFunc(void *data);
-void *remoteAdmClientInitHook(virNetServerClientPtr client, void *opaque);
-
-#endif /* __ADMIN_REMOTE_H__ */
--- a/daemon/libvirt.rules
+++ b/daemon/libvirt.rules
@@ -1,9 +0,0 @@
-// Allow any user in the 'libvirt' group to connect to system libvirtd
-// without entering a password.
-
-polkit.addRule(function(action, subject) {
-    if (action.id == "org.libvirt.unix.manage" &&
-        subject.isInGroup("libvirt")) {
-        return polkit.Result.YES;
-    }
-});
--- a/daemon/libvirtd-config.c
+++ b/daemon/libvirtd-config.c
@@ -1,7 +1,7 @@
 /*
- * libvirtd-config.c: daemon start of day, guest process & i/o management
+ * libvirtd.c: daemon start of day, guest process & i/o management
 *
- * Copyright (C) 2006-2012, 2014, 2015 Red Hat, Inc.
+ * Copyright (C) 2006-2012 Red Hat, Inc.
 * Copyright (C) 2006 Daniel P. Berrange
 *
 * This library is free software; you can redistribute it and/or
@@ -24,21 +24,17 @@
 #include <config.h>

 #include "libvirtd-config.h"
-#include "virconf.h"
-#include "viralloc.h"
-#include "virerror.h"
-#include "virlog.h"
+#include "conf.h"
+#include "memory.h"
+#include "virterror_internal.h"
+#include "logging.h"
 #include "rpc/virnetserver.h"
 #include "configmake.h"
 #include "remote/remote_protocol.h"
 #include "remote/remote_driver.h"
-#include "virstring.h"
-#include "virutil.h"

 #define VIR_FROM_THIS VIR_FROM_CONF

-VIR_LOG_INIT("daemon.libvirtd-config");
-
 /* Allocate an array of malloc'd strings from the config file, filename
 * (used only in diagnostics), using handle "conf".  Upon error, return -1
 * and free any allocated memory.  Otherwise, save the array in *list_arg
@@ -61,16 +57,19 @@ remoteConfigGetStringList(virConfPtr conf, const char *key, char ***list_arg,
                           key);
            return -1;
        }
-        if (VIR_STRDUP(list[0], p->str) < 0) {
+        list[0] = strdup(p->str);
+        list[1] = NULL;
+        if (list[0] == NULL) {
+            virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+                           _("failed to allocate memory for %s config list value"),
+                           key);
            VIR_FREE(list);
            return -1;
        }
-        list[1] = NULL;
        break;

    case VIR_CONF_LIST: {
-        int len = 0;
-        size_t i;
+        int i, len = 0;
        virConfValuePtr pp;
        for (pp = p->list; pp; pp = pp->next)
            len++;
@@ -89,11 +88,15 @@ remoteConfigGetStringList(virConfPtr conf, const char *key, char ***list_arg,
                VIR_FREE(list);
                return -1;
            }
-            if (VIR_STRDUP(list[i], pp->str) < 0) {
-                size_t j;
-                for (j = 0; j < i; j++)
+            list[i] = strdup(pp->str);
+            if (list[i] == NULL) {
+                int j;
+                for (j = 0 ; j < i ; j++)
                    VIR_FREE(list[j]);
                VIR_FREE(list);
+                virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+                               _("failed to allocate memory for %s config list value"),
+                               key);
                return -1;
            }

@@ -123,16 +126,16 @@ checkType(virConfValuePtr p, const char *filename,
        virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
                       _("remoteReadConfigFile: %s: %s: invalid type:"
                         " got %s; expected %s"), filename, key,
-                       virConfTypeToString(p->type),
-                       virConfTypeToString(required_type));
+                       virConfTypeName(p->type),
+                       virConfTypeName(required_type));
        return -1;
    }
    return 0;
 }

 /* If there is no config data for the key, #var_name, then do nothing.
-   If there is valid data of type VIR_CONF_STRING, and VIR_STRDUP succeeds,
-   store the result in var_name.  Otherwise, (i.e. invalid type, or VIR_STRDUP
+   If there is valid data of type VIR_CONF_STRING, and strdup succeeds,
+   store the result in var_name.  Otherwise, (i.e. invalid type, or strdup
   failure), give a diagnostic and "goto" the cleanup-and-fail label.  */
 #define GET_CONF_STR(conf, filename, var_name)                          \
    do {                                                                \
@@ -141,42 +144,26 @@ checkType(virConfValuePtr p, const char *filename,
            if (checkType(p, filename, #var_name, VIR_CONF_STRING) < 0) \
                goto error;                                             \
            VIR_FREE(data->var_name);                                   \
-            if (VIR_STRDUP(data->var_name, p->str) < 0)                 \
+            if (!(data->var_name = strdup(p->str))) {                   \
+                virReportOOMError();                                    \
                goto error;                                             \
+            }                                                           \
        }                                                               \
    } while (0)

-/* Like GET_CONF_STR, but for signed integral values.  */
+/* Like GET_CONF_STR, but for integral values.  */
 #define GET_CONF_INT(conf, filename, var_name)                          \
    do {                                                                \
        virConfValuePtr p = virConfGetValue(conf, #var_name);           \
        if (p) {                                                        \
-            if (p->type != VIR_CONF_ULONG &&                            \
-                checkType(p, filename, #var_name, VIR_CONF_LONG) < 0)   \
-                goto error;                                             \
-            data->var_name = p->l;                                      \
-        }                                                               \
-    } while (0)
-
-/* Like GET_CONF_STR, but for unsigned integral values.  */
-#define GET_CONF_UINT(conf, filename, var_name)                         \
-    do {                                                                \
-        virConfValuePtr p = virConfGetValue(conf, #var_name);           \
-        if (p) {                                                        \
-            if (checkType(p, filename, #var_name, VIR_CONF_ULONG) < 0)  \
+            if (checkType(p, filename, #var_name, VIR_CONF_LONG) < 0)   \
                goto error;                                             \
            data->var_name = p->l;                                      \
        }                                                               \
    } while (0)


-
-static int
-remoteConfigGetAuth(virConfPtr conf,
-                    const char *key,
-                    int *auth,
-                    const char *filename)
-{
+static int remoteConfigGetAuth(virConfPtr conf, const char *key, int *auth, const char *filename) {
    virConfValuePtr p;

    p = virConfGetValue(conf, key);
@@ -191,7 +178,7 @@ remoteConfigGetAuth(virConfPtr conf,

    if (STREQ(p->str, "none")) {
        *auth = VIR_NET_SERVER_SERVICE_AUTH_NONE;
-#if WITH_SASL
+#if HAVE_SASL
    } else if (STREQ(p->str, "sasl")) {
        *auth = VIR_NET_SERVER_SERVICE_AUTH_SASL;
 #endif
@@ -211,8 +198,8 @@ int
 daemonConfigFilePath(bool privileged, char **configfile)
 {
    if (privileged) {
-        if (VIR_STRDUP(*configfile, SYSCONFDIR "/libvirt/libvirtd.conf") < 0)
-            goto error;
+        if (!(*configfile = strdup(SYSCONFDIR "/libvirt/libvirtd.conf")))
+            goto no_memory;
    } else {
        char *configdir = NULL;

@@ -221,14 +208,16 @@ daemonConfigFilePath(bool privileged, char **configfile)

        if (virAsprintf(configfile, "%s/libvirtd.conf", configdir) < 0) {
            VIR_FREE(configdir);
-            goto error;
+            goto no_memory;
        }
        VIR_FREE(configdir);
    }

    return 0;

- error:
+no_memory:
+    virReportOOMError();
+error:
    return -1;
 }

@@ -239,18 +228,21 @@ daemonConfigNew(bool privileged ATTRIBUTE_UNUSED)
    char *localhost;
    int ret;

-    if (VIR_ALLOC(data) < 0)
+    if (VIR_ALLOC(data) < 0) {
+        virReportOOMError();
        return NULL;
+    }

    data->listen_tls = 1;
    data->listen_tcp = 0;

-    if (VIR_STRDUP(data->tls_port, LIBVIRTD_TLS_PORT) < 0 ||
-        VIR_STRDUP(data->tcp_port, LIBVIRTD_TCP_PORT) < 0)
-        goto error;
+    if (!(data->tls_port = strdup(LIBVIRTD_TLS_PORT)))
+        goto no_memory;
+    if (!(data->tcp_port = strdup(LIBVIRTD_TCP_PORT)))
+        goto no_memory;

    /* Only default to PolicyKit if running as root */
-#if WITH_POLKIT
+#if HAVE_POLKIT
    if (privileged) {
        data->auth_unix_rw = REMOTE_AUTH_POLKIT;
        data->auth_unix_ro = REMOTE_AUTH_POLKIT;
@@ -258,17 +250,20 @@ daemonConfigNew(bool privileged ATTRIBUTE_UNUSED)
 #endif
        data->auth_unix_rw = REMOTE_AUTH_NONE;
        data->auth_unix_ro = REMOTE_AUTH_NONE;
-#if WITH_POLKIT
+#if HAVE_POLKIT
    }
 #endif

-    if (VIR_STRDUP(data->unix_sock_rw_perms,
-                   data->auth_unix_rw == REMOTE_AUTH_POLKIT ? "0777" : "0700") < 0 ||
-        VIR_STRDUP(data->unix_sock_ro_perms, "0777") < 0 ||
-        VIR_STRDUP(data->unix_sock_admin_perms, "0700") < 0)
-        goto error;
+    if (data->auth_unix_rw == REMOTE_AUTH_POLKIT)
+        data->unix_sock_rw_perms = strdup("0777"); /* Allow world */
+    else
+        data->unix_sock_rw_perms = strdup("0700"); /* Allow user only */
+    data->unix_sock_ro_perms = strdup("0777"); /* Always allow world */
+    if (!data->unix_sock_ro_perms ||
+        !data->unix_sock_rw_perms)
+        goto no_memory;

-#if WITH_SASL
+#if HAVE_SASL
    data->auth_tcp = REMOTE_AUTH_SASL;
 #else
    data->auth_tcp = REMOTE_AUTH_NONE;
@@ -279,36 +274,29 @@ daemonConfigNew(bool privileged ATTRIBUTE_UNUSED)

    data->min_workers = 5;
    data->max_workers = 20;
-    data->max_clients = 5000;
-    data->max_anonymous_clients = 20;
+    data->max_clients = 20;

    data->prio_workers = 5;

    data->max_requests = 20;
    data->max_client_requests = 5;

+    data->log_buffer_size = 64;
+
    data->audit_level = 1;
    data->audit_logging = 0;

    data->keepalive_interval = 5;
    data->keepalive_count = 5;
+    data->keepalive_required = 0;

-    data->admin_min_workers = 5;
-    data->admin_max_workers = 20;
-    data->admin_max_clients = 5000;
-    data->admin_max_queued_clients = 20;
-    data->admin_max_client_requests = 5;
-
-    data->admin_keepalive_interval = 5;
-    data->admin_keepalive_count = 5;
-
-    localhost = virGetHostname();
+    localhost = virGetHostname(NULL);
    if (localhost == NULL) {
        /* we couldn't resolve the hostname; assume that we are
         * running in disconnected operation, and report a less
         * useful Avahi string
         */
-        ret = VIR_STRDUP(data->mdns_name, "Virtualization Host");
+        ret = virAsprintf(&data->mdns_name, "Virtualization Host");
    } else {
        char *tmp;
        /* Extract the host part of the potentially FQDN */
@@ -319,11 +307,12 @@ daemonConfigNew(bool privileged ATTRIBUTE_UNUSED)
    }
    VIR_FREE(localhost);
    if (ret < 0)
-        goto error;
+        goto no_memory;

    return data;

- error:
+no_memory:
+    virReportOOMError();
    daemonConfigFree(data);
    return NULL;
 }
@@ -339,14 +328,7 @@ daemonConfigFree(struct daemonConfig *data)
    VIR_FREE(data->listen_addr);
    VIR_FREE(data->tls_port);
    VIR_FREE(data->tcp_port);
-    tmp = data->access_drivers;
-    while (tmp && *tmp) {
-        VIR_FREE(*tmp);
-        tmp++;
-    }
-    VIR_FREE(data->access_drivers);

-    VIR_FREE(data->unix_sock_admin_perms);
    VIR_FREE(data->unix_sock_ro_perms);
    VIR_FREE(data->unix_sock_rw_perms);
    VIR_FREE(data->unix_sock_group);
@@ -384,22 +366,24 @@ daemonConfigLoadOptions(struct daemonConfig *data,
                        const char *filename,
                        virConfPtr conf)
 {
-    GET_CONF_UINT(conf, filename, listen_tcp);
-    GET_CONF_UINT(conf, filename, listen_tls);
+    GET_CONF_INT(conf, filename, listen_tcp);
+    GET_CONF_INT(conf, filename, listen_tls);
    GET_CONF_STR(conf, filename, tls_port);
    GET_CONF_STR(conf, filename, tcp_port);
    GET_CONF_STR(conf, filename, listen_addr);

    if (remoteConfigGetAuth(conf, "auth_unix_rw", &data->auth_unix_rw, filename) < 0)
        goto error;
-#if WITH_POLKIT
+#if HAVE_POLKIT
    /* Change default perms to be wide-open if PolicyKit is enabled.
     * Admin can always override in config file
     */
    if (data->auth_unix_rw == REMOTE_AUTH_POLKIT) {
        VIR_FREE(data->unix_sock_rw_perms);
-        if (VIR_STRDUP(data->unix_sock_rw_perms, "0777") < 0)
+        if (!(data->unix_sock_rw_perms = strdup("0777"))) {
+            virReportOOMError();
            goto error;
+        }
    }
 #endif
    if (remoteConfigGetAuth(conf, "auth_unix_ro", &data->auth_unix_ro, filename) < 0)
@@ -409,22 +393,17 @@ daemonConfigLoadOptions(struct daemonConfig *data,
    if (remoteConfigGetAuth(conf, "auth_tls", &data->auth_tls, filename) < 0)
        goto error;

-    if (remoteConfigGetStringList(conf, "access_drivers",
-                                  &data->access_drivers, filename) < 0)
-        goto error;
-
    GET_CONF_STR(conf, filename, unix_sock_group);
-    GET_CONF_STR(conf, filename, unix_sock_admin_perms);
    GET_CONF_STR(conf, filename, unix_sock_ro_perms);
    GET_CONF_STR(conf, filename, unix_sock_rw_perms);

    GET_CONF_STR(conf, filename, unix_sock_dir);

-    GET_CONF_UINT(conf, filename, mdns_adv);
+    GET_CONF_INT(conf, filename, mdns_adv);
    GET_CONF_STR(conf, filename, mdns_name);

-    GET_CONF_UINT(conf, filename, tls_no_sanity_certificate);
-    GET_CONF_UINT(conf, filename, tls_no_verify_certificate);
+    GET_CONF_INT(conf, filename, tls_no_sanity_certificate);
+    GET_CONF_INT(conf, filename, tls_no_verify_certificate);

    GET_CONF_STR(conf, filename, key_file);
    GET_CONF_STR(conf, filename, cert_file);
@@ -441,41 +420,32 @@ daemonConfigLoadOptions(struct daemonConfig *data,
        goto error;


-    GET_CONF_UINT(conf, filename, min_workers);
-    GET_CONF_UINT(conf, filename, max_workers);
-    GET_CONF_UINT(conf, filename, max_clients);
-    GET_CONF_UINT(conf, filename, max_queued_clients);
-    GET_CONF_UINT(conf, filename, max_anonymous_clients);
+    GET_CONF_INT(conf, filename, min_workers);
+    GET_CONF_INT(conf, filename, max_workers);
+    GET_CONF_INT(conf, filename, max_clients);

-    GET_CONF_UINT(conf, filename, prio_workers);
+    GET_CONF_INT(conf, filename, prio_workers);

    GET_CONF_INT(conf, filename, max_requests);
-    GET_CONF_UINT(conf, filename, max_client_requests);
+    GET_CONF_INT(conf, filename, max_client_requests);

-    GET_CONF_UINT(conf, filename, admin_min_workers);
-    GET_CONF_UINT(conf, filename, admin_max_workers);
-    GET_CONF_UINT(conf, filename, admin_max_clients);
-    GET_CONF_UINT(conf, filename, admin_max_queued_clients);
-    GET_CONF_UINT(conf, filename, admin_max_client_requests);
-
-    GET_CONF_UINT(conf, filename, audit_level);
-    GET_CONF_UINT(conf, filename, audit_logging);
+    GET_CONF_INT(conf, filename, audit_level);
+    GET_CONF_INT(conf, filename, audit_logging);

    GET_CONF_STR(conf, filename, host_uuid);

-    GET_CONF_UINT(conf, filename, log_level);
+    GET_CONF_INT(conf, filename, log_level);
    GET_CONF_STR(conf, filename, log_filters);
    GET_CONF_STR(conf, filename, log_outputs);
+    GET_CONF_INT(conf, filename, log_buffer_size);

    GET_CONF_INT(conf, filename, keepalive_interval);
-    GET_CONF_UINT(conf, filename, keepalive_count);
-
-    GET_CONF_INT(conf, filename, admin_keepalive_interval);
-    GET_CONF_UINT(conf, filename, admin_keepalive_count);
+    GET_CONF_INT(conf, filename, keepalive_count);
+    GET_CONF_INT(conf, filename, keepalive_required);

    return 0;

- error:
+error:
    return -1;
 }

--- a/daemon/libvirtd-config.h
+++ b/daemon/libvirtd-config.h
@@ -1,7 +1,7 @@
 /*
- * libvirtd-config.h: daemon start of day, guest process & i/o management
+ * libvirtd.c: daemon start of day, guest process & i/o management
 *
- * Copyright (C) 2006-2012, 2015 Red Hat, Inc.
+ * Copyright (C) 2006-2012 Red Hat, Inc.
 * Copyright (C) 2006 Daniel P. Berrange
 *
 * This library is free software; you can redistribute it and/or
@@ -35,7 +35,6 @@ struct daemonConfig {
    char *tls_port;
    char *tcp_port;

-    char *unix_sock_admin_perms;
    char *unix_sock_ro_perms;
    char *unix_sock_rw_perms;
    char *unix_sock_group;
@@ -46,8 +45,6 @@ struct daemonConfig {
    int auth_tcp;
    int auth_tls;

-    char **access_drivers;
-
    int mdns_adv;
    char *mdns_name;

@@ -64,8 +61,6 @@ struct daemonConfig {
    int min_workers;
    int max_workers;
    int max_clients;
-    int max_queued_clients;
-    int max_anonymous_clients;

    int prio_workers;

@@ -75,21 +70,14 @@ struct daemonConfig {
    int log_level;
    char *log_filters;
    char *log_outputs;
+    int log_buffer_size;

    int audit_level;
    int audit_logging;

    int keepalive_interval;
    unsigned int keepalive_count;
-
-    int admin_min_workers;
-    int admin_max_workers;
-    int admin_max_clients;
-    int admin_max_queued_clients;
-    int admin_max_client_requests;
-
-    int admin_keepalive_interval;
-    unsigned int admin_keepalive_count;
+    int keepalive_required;
 };


--- a/daemon/libvirtd.aug
+++ b/daemon/libvirtd.aug
@@ -35,7 +35,6 @@ module Libvirtd =
   let sock_acl_entry = str_entry "unix_sock_group"
                      | str_entry "unix_sock_ro_perms"
                      | str_entry "unix_sock_rw_perms"
-                      | str_entry "unix_sock_admin_perms"
                      | str_entry "unix_sock_dir"

   let authentication_entry = str_entry "auth_unix_ro"
@@ -52,23 +51,14 @@ module Libvirtd =
                           | bool_entry "tls_no_sanity_certificate"
                           | str_array_entry "tls_allowed_dn_list"
                           | str_array_entry "sasl_allowed_username_list"
-                           | str_array_entry "access_drivers"

   let processing_entry = int_entry "min_workers"
                        | int_entry "max_workers"
                        | int_entry "max_clients"
-                        | int_entry "max_queued_clients"
-                        | int_entry "max_anonymous_clients"
                        | int_entry "max_requests"
                        | int_entry "max_client_requests"
                        | int_entry "prio_workers"

-   let admin_processing_entry = int_entry "admin_min_workers"
-                              | int_entry "admin_max_workers"
-                              | int_entry "admin_max_clients"
-                              | int_entry "admin_max_queued_clients"
-                              | int_entry "admin_max_client_requests"
-
   let logging_entry = int_entry "log_level"
                     | str_entry "log_filters"
                     | str_entry "log_outputs"
@@ -81,10 +71,6 @@ module Libvirtd =
                       | int_entry "keepalive_count"
                       | bool_entry "keepalive_required"

-   let admin_keepalive_entry = int_entry "admin_keepalive_interval"
-                             | int_entry "admin_keepalive_count"
-                             | bool_entry "admin_keepalive_required"
-
   let misc_entry = str_entry "host_uuid"

   (* Each enty in the config is one of the following three ... *)
@@ -94,11 +80,9 @@ module Libvirtd =
             | certificate_entry
             | authorization_entry
             | processing_entry
-             | admin_processing_entry
             | logging_entry
             | auditing_entry
             | keepalive_entry
-             | admin_keepalive_entry
             | misc_entry
   let comment = [ label "#comment" . del /#[ \t]*/ "# " .  store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ]
   let empty = [ label "#empty" . eol ]
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
--- a/daemon/libvirtd.conf
+++ b/daemon/libvirtd.conf
@@ -48,10 +48,6 @@
 # Override the default configuration which binds to all network
 # interfaces. This can be a numeric IPv4/6 address, or hostname
 #
-# If the libvirtd service is started in parallel with network
-# startup (e.g. with systemd), binding to addresses other than
-# the wildcards (0.0.0.0/::) might not be available yet.
-#
 #listen_addr = "192.168.0.1"


@@ -67,7 +63,7 @@
 # unique on the immediate broadcast network.
 #
 # The default is "Virtualization Host HOSTNAME", where HOSTNAME
-# is substituted for the short hostname of the machine (without domain)
+# is subsituted for the short hostname of the machine (without domain)
 #
 #mdns_name = "Virtualization Host Joe Demo"

@@ -77,11 +73,6 @@
 # UNIX socket access controls
 #

-# Beware that if you are changing *any* of these options, and you use
-# socket activation with systemd, you need to adjust the settings in
-# the libvirtd.socket file as well since it could impose a security
-# risk if you rely on file permission checking only.
-
 # Set the UNIX domain socket group ownership. This can be used to
 # allow a 'trusted' set of users access to management capabilities
 # without becoming root.
@@ -92,8 +83,8 @@
 # Set the UNIX socket permissions for the R/O socket. This is used
 # for monitoring VM status only
 #
-# Default allows any user. If setting group ownership, you may want to
-# restrict this too.
+# Default allows any user. If setting group ownership may want to
+# restrict this to:
 #unix_sock_ro_perms = "0777"

 # Set the UNIX socket permissions for the R/W socket. This is used
@@ -103,20 +94,12 @@
 # the default will change to allow everyone (eg, 0777)
 #
 # If not using PolicyKit and setting group ownership for access
-# control, then you may want to relax this too.
+# control then you may want to relax this to:
 #unix_sock_rw_perms = "0770"

-# Set the UNIX socket permissions for the admin interface socket.
-#
-# Default allows only owner (root), do not change it unless you are
-# sure to whom you are exposing the access to.
-#unix_sock_admin_perms = "0700"
-
 # Set the name of the directory in which sockets will be found/created.
 #unix_sock_dir = "/var/run/libvirt"

-
-
 #################################################################
 #
 # Authentication.
@@ -130,7 +113,7 @@
 #  - sasl: use SASL infrastructure. The actual auth scheme is then
 #          controlled from /etc/sasl2/libvirt.conf. For the TCP
 #          socket only GSSAPI & DIGEST-MD5 mechanisms will be used.
-#          For non-TCP or TLS sockets, any scheme is allowed.
+#          For non-TCP or TLS sockets,  any scheme is allowed.
 #
 #  - polkit: use PolicyKit to authenticate. This is only suitable
 #            for use on the UNIX sockets. The default policy will
@@ -172,15 +155,6 @@
 #auth_tls = "none"


-# Change the API access control scheme
-#
-# By default an authenticated user is allowed access
-# to all APIs. Access drivers can place restrictions
-# on this. By default the 'nop' driver is enabled,
-# meaning no access control checks are done once a
-# client has authenticated with libvirtd
-#
-#access_drivers = [ "polkit" ]

 #################################################################
 #
@@ -233,7 +207,7 @@
 #tls_no_verify_certificate = 1


-# A whitelist of allowed x509 Distinguished Names
+# A whitelist of allowed x509  Distinguished Names
 # This list may contain wildcards such as
 #
 #    "C=GB,ST=London,L=London,O=Red Hat,CN=*"
@@ -272,18 +246,8 @@

 # The maximum number of concurrent client connections to allow
 # over all sockets combined.
-#max_clients = 5000
+#max_clients = 20

-# The maximum length of queue of connections waiting to be
-# accepted by the daemon. Note, that some protocols supporting
-# retransmission may obey this so that a later reattempt at
-# connection succeeds.
-#max_queued_clients = 1000
-
-# The maximum length of queue of accepted but not yet
-# authenticated clients. The default value is zero, meaning
-# the feature is disabled.
-#max_anonymous_clients = 20

 # The minimum limit sets the number of workers to start up
 # initially. If the number of active clients exceeds this,
@@ -295,13 +259,13 @@


 # The number of priority workers. If all workers from above
-# pool are stuck, some calls marked as high priority
+# pool will stuck, some calls marked as high priority
 # (notably domainDestroy) can be executed in this pool.
 #prio_workers = 5

 # Total global limit on concurrent RPC calls. Should be
 # at least as large as max_workers. Beyond this, RPC requests
-# will be read into memory and queued. This directly impacts
+# will be read into memory and queued. This directly impact
 # memory usage, currently each request requires 256 KB of
 # memory. So by default up to 5 MB of memory is used
 #
@@ -315,16 +279,6 @@
 # and max_workers parameter
 #max_client_requests = 5

-# Same processing controls, but this time for the admin interface.
-# For description of each option, be so kind to scroll few lines
-# upwards.
-
-#admin_min_workers = 1
-#admin_max_workers = 5
-#admin_max_clients = 5
-#admin_max_queued_clients = 5
-#admin_max_client_requests = 5
-
 #################################################################
 #
 # Logging controls
@@ -332,10 +286,6 @@

 # Logging level: 4 errors, 3 warnings, 2 information, 1 debug
 # basically 1 will log everything possible
-# Note: Journald may employ rate limiting of the messages logged
-# and thus lock up the libvirt daemon. To use the debug level with
-# journald you have to specify it explicitly in 'log_outputs', otherwise
-# only information level messages will be logged.
 #log_level = 3

 # Logging filters:
@@ -353,7 +303,7 @@
 #    3: WARNING
 #    4: ERROR
 #
-# Multiple filters can be defined in a single @filters, they just need to be
+# Multiple filter can be defined in a single @filters, they just need to be
 # separated by spaces.
 #
 # e.g. to only get warning or errors from the remote layer and only errors
@@ -369,24 +319,22 @@
 #      use syslog for the output and use the given name as the ident
 #    x:file:file_path
 #      output to a file, with the given filepath
-#    x:journald
-#      output to journald logging system
 # In all case the x prefix is the minimal level, acting as a filter
 #    1: DEBUG
 #    2: INFO
 #    3: WARNING
 #    4: ERROR
 #
-# Multiple outputs can be defined, they just need to be separated by spaces.
+# Multiple output can be defined, they just need to be separated by spaces.
 # e.g. to log all warnings and errors to syslog under the libvirtd ident:
 #log_outputs="3:syslog:libvirtd"
 #

-# Log debug buffer size:
-#
-# This configuration option is no longer used, since the global
-# log buffer functionality has been removed. Please configure
-# suitable log_outputs/log_filters settings to obtain logs.
+# Log debug buffer size: default 64
+# The daemon keeps an internal debug log buffer which will be dumped in case
+# of crash or upon receiving a SIGUSR2 signal. This setting allows to override
+# the default buffer size in kilobytes.
+# If value is 0 or less the debug log buffer is deactivated
 #log_buffer_size = 64


@@ -424,7 +372,7 @@
 ###################################################################
 # Keepalive protocol:
 # This allows libvirtd to detect broken client connections or even
-# dead clients.  A keepalive message is sent to a client after
+# dead client.  A keepalive message is sent to a client after
 # keepalive_interval seconds of inactivity to check if the client is
 # still responding; keepalive_count is a maximum number of keepalive
 # messages that are allowed to be sent to the client without getting
@@ -433,22 +381,15 @@
 # keepalive_interval * (keepalive_count + 1) seconds since the last
 # message received from the client.  If keepalive_interval is set to
 # -1, libvirtd will never send keepalive requests; however clients
-# can still send them and the daemon will send responses.  When
+# can still send them and the deamon will send responses.  When
 # keepalive_count is set to 0, connections will be automatically
 # closed after keepalive_interval seconds of inactivity without
 # sending any keepalive messages.
 #
 #keepalive_interval = 5
 #keepalive_count = 5
-
 #
-# These configuration options are no longer used.  There is no way to
-# restrict such clients from connecting since they first need to
-# connect in order to ask for keepalive.
+# If set to 1, libvirtd will refuse to talk to clients that do not
+# support keepalive protocol.  Defaults to 0.
 #
 #keepalive_required = 1
-#admin_keepalive_required = 1
-
-# Keepalive settings for the admin interface
-#admin_keepalive_interval = 5
-#admin_keepalive_count = 5
--- a/daemon/libvirtd.h
+++ b/daemon/libvirtd.h
@@ -1,7 +1,7 @@
 /*
 * libvirtd.h: daemon data structure definitions
 *
- * Copyright (C) 2006-2015 Red Hat, Inc.
+ * Copyright (C) 2006-2012 Red Hat, Inc.
 * Copyright (C) 2006 Daniel P. Berrange
 *
 * This library is free software; you can redistribute it and/or
@@ -27,15 +27,15 @@

 # define VIR_ENUM_SENTINELS

+# include <config.h>
+
 # include <rpc/types.h>
 # include <rpc/xdr.h>
 # include "remote_protocol.h"
-# include "admin_protocol.h"
-# include "lxc_protocol.h"
 # include "qemu_protocol.h"
-# include "virthread.h"
-
-# if WITH_SASL
+# include "logging.h"
+# include "threads.h"
+# if HAVE_SASL
 #  include "virnetsaslcontext.h"
 # endif
 # include "virnetserverprogram.h"
@@ -44,24 +44,15 @@ typedef struct daemonClientStream daemonClientStream;
 typedef daemonClientStream *daemonClientStreamPtr;
 typedef struct daemonClientPrivate daemonClientPrivate;
 typedef daemonClientPrivate *daemonClientPrivatePtr;
-typedef struct daemonAdmClientPrivate daemonAdmClientPrivate;
-typedef daemonAdmClientPrivate *daemonAdmClientPrivatePtr;
-typedef struct daemonClientEventCallback daemonClientEventCallback;
-typedef daemonClientEventCallback *daemonClientEventCallbackPtr;

 /* Stores the per-client connection state */
 struct daemonClientPrivate {
    /* Hold while accessing any data except conn */
    virMutex lock;

-    daemonClientEventCallbackPtr *domainEventCallbacks;
-    size_t ndomainEventCallbacks;
-    daemonClientEventCallbackPtr *networkEventCallbacks;
-    size_t nnetworkEventCallbacks;
-    daemonClientEventCallbackPtr *qemuEventCallbacks;
-    size_t nqemuEventCallbacks;
+    int domainEventCallbackID[VIR_DOMAIN_EVENT_ID_LAST];

-# if WITH_SASL
+# if HAVE_SASL
    virNetSASLSessionPtr sasl;
 # endif

@@ -72,17 +63,10 @@ struct daemonClientPrivate {
    virConnectPtr conn;

    daemonClientStreamPtr streams;
+    bool keepalive_supported;
 };

-/* Separate private data for admin connection */
-struct daemonAdmClientPrivate {
-    /* Just a placeholder, not that there is anything to be locked */
-    virMutex lock;
-
-    virNetDaemonPtr dmn;
-};
-
-# if WITH_SASL
+# if HAVE_SASL
 extern virNetSASLContextPtr saslCtxt;
 # endif
 extern virNetServerProgramPtr remoteProgram;
--- a/daemon/libvirtd.init.in
+++ b/daemon/libvirtd.init.in
@@ -9,11 +9,9 @@
 # Should-Start: $named
 # Should-Start: xend
 # Should-Start: avahi-daemon
-# Should-Start: virtlockd
 # Required-Stop: $network messagebus
 # Should-Stop: $named
 # Default-Start: 3 4 5
-# Default-Stop: 0 1 2 6
 # Short-Description: daemon for libvirt virtualization API
 # Description: This is a daemon for managing guest instances
 #              and libvirt virtual networks
--- a/daemon/libvirtd.libxl.logrotate.in
+++ b/daemon/libvirtd.libxl.logrotate.in
@@ -1,9 +0,0 @@
-@localstatedir@/log/libvirt/libxl/*.log {
-        weekly
-        missingok
-        rotate 4
-        compress
-        delaycompress
-        copytruncate
-        minsize 100k
-}
--- a/daemon/libvirtd.pod.in
+++ b/daemon/libvirtd.pod.in
@@ -36,10 +36,6 @@ from the configuration.

 =over

-=item B<-h, --help>
-
-Display command line help usage then exit.
-
 =item B<-d, --daemon>

 Run as a daemon & write PID file.
--- a/daemon/libvirtd.sasl
+++ b/daemon/libvirtd.sasl
@@ -27,5 +27,5 @@ mech_list: digest-md5

 # If using digest-md5 for username/passwds, then this is the file
 # containing the passwds. Use 'saslpasswd2 -a libvirt [username]'
-# to add entries, and 'sasldblistusers2 -f [sasldb_path]' to browse it
+# to add entries, and 'sasldblistusers2 -a libvirt' to browse it
 sasldb_path: /etc/libvirt/passwd.db
--- a/daemon/libvirtd.service.in
+++ b/daemon/libvirtd.service.in
@@ -1,22 +1,19 @@
+# NB we don't use socket activation. When libvirtd starts it will
+# spawn any virtual machines registered for autostart. We want this
+# to occur on every boot, regardless of whether any client connects
+# to a socket. Thus socket activation doesn't have any benefit
+
 [Unit]
 Description=Virtualization daemon
 Before=libvirt-guests.service
 After=network.target
 After=dbus.service
-After=iscsid.service
-After=apparmor.service
-After=local-fs.target
-After=remote-fs.target
-Documentation=man:libvirtd(8)
-Documentation=http://libvirt.org

 [Service]
-Type=notify
 EnvironmentFile=-/etc/sysconfig/libvirtd
 ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=process
-Restart=on-failure
 # Override the maximum number of opened files
 #LimitNOFILE=2048

--- a/daemon/libvirtd.socket.in
+++ b/daemon/libvirtd.socket.in
@@ -1,11 +0,0 @@
-[Socket]
-ListenStream=@runstatedir@/libvirt/libvirt-sock
-ListenStream=@runstatedir@/libvirt/libvirt-sock-ro
-
-; The following settings must match libvirtd.conf file in order to
-; work as expected because libvirtd can't change them later.
-; SocketMode=0777 is safe only if authentication on the socket is set
-; up.  For further information, please see the libvirtd.conf file.
-SocketMode=0777
-SocketUser=root
-SocketGroup=root
--- a/daemon/libvirtd.sysconf
+++ b/daemon/libvirtd.sysconf
@@ -20,14 +20,5 @@
 #
 #SDL_AUDIODRIVER=pulse

-# Override the maximum number of opened files.
-# This only works with traditional init scripts.
-# In the systemd world, the limit can only be changed by overriding
-# LimitNOFILE for libvirtd.service. To do that, just create a *.conf
-# file in /etc/systemd/system/libvirtd.service.d/ (for example
-# /etc/systemd/system/libvirtd.service.d/openfiles.conf) and write
-# the following two lines in it:
-#   [Service]
-#   LimitNOFILE=2048
-#
+# Override the maximum number of opened files
 #LIBVIRTD_NOFILES_LIMIT=2048
--- a/daemon/remote.c
+++ b/daemon/remote.c
--- a/daemon/remote.h
+++ b/daemon/remote.h
@@ -32,9 +32,6 @@
 extern virNetServerProgramProc remoteProcs[];
 extern size_t remoteNProcs;

-extern virNetServerProgramProc lxcProcs[];
-extern size_t lxcNProcs;
-
 extern virNetServerProgramProc qemuProcs[];
 extern size_t qemuNProcs;

--- a/daemon/stream.c
+++ b/daemon/stream.c
@@ -1,7 +1,7 @@
 /*
 * stream.c: APIs for managing client streams
 *
- * Copyright (C) 2009-2014 Red Hat, Inc.
+ * Copyright (C) 2009, 2011 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
@@ -25,15 +25,13 @@

 #include "stream.h"
 #include "remote.h"
-#include "viralloc.h"
-#include "virlog.h"
+#include "memory.h"
+#include "logging.h"
 #include "virnetserverclient.h"
-#include "virerror.h"
+#include "virterror_internal.h"

 #define VIR_FROM_THIS VIR_FROM_STREAMS

-VIR_LOG_INIT("daemon.stream");
-
 struct daemonClientStream {
    daemonClientPrivatePtr priv;
    int refs;
@@ -150,14 +148,6 @@ daemonStreamEvent(virStreamPtr st, int events, void *opaque)
            virNetServerClientClose(client);
            goto cleanup;
        }
-        /* If we detected EOF during read processing,
-         * then clear hangup/error conditions, since
-         * we want the client to see the EOF message
-         * we just sent them
-         */
-        if (stream->recvEOF)
-            events = events & ~(VIR_STREAM_EVENT_HANGUP |
-                                VIR_STREAM_EVENT_ERROR);
    }

    /* If we have a completion/abort message, always process it */
@@ -260,7 +250,7 @@ daemonStreamEvent(virStreamPtr st, int events, void *opaque)
        daemonStreamUpdateEvents(stream);
    }

- cleanup:
+cleanup:
    virMutexUnlock(&priv->lock);
 }

@@ -301,7 +291,7 @@ daemonStreamFilter(virNetServerClientPtr client ATTRIBUTE_UNUSED,
    daemonStreamUpdateEvents(stream);
    ret = 1;

- cleanup:
+cleanup:
    virMutexUnlock(&stream->priv->lock);
    return ret;
 }
@@ -327,8 +317,10 @@ daemonCreateClientStream(virNetServerClientPtr client,
    VIR_DEBUG("client=%p, proc=%d, serial=%d, st=%p",
              client, header->proc, header->serial, st);

-    if (VIR_ALLOC(stream) < 0)
+    if (VIR_ALLOC(stream) < 0) {
+        virReportOOMError();
        return NULL;
+    }

    stream->refs = 1;
    stream->priv = priv;
@@ -383,7 +375,7 @@ int daemonFreeClientStream(virNetServerClientPtr client,
        msg = tmp;
    }

-    virObjectUnref(stream->st);
+    virStreamFree(stream->st);
    VIR_FREE(stream);

    return ret;
@@ -612,10 +604,10 @@ daemonStreamHandleAbort(virNetServerClientPtr client,
    virStreamEventRemoveCallback(stream->st);
    virStreamAbort(stream->st);

-    if (msg->header.status == VIR_NET_ERROR) {
+    if (msg->header.status == VIR_NET_ERROR)
        virReportError(VIR_ERR_RPC,
                       "%s", _("stream aborted at client request"));
-    } else {
+    else {
        VIR_WARN("unexpected stream status %d", msg->header.status);
        virReportError(VIR_ERR_RPC,
                       _("stream aborted with unexpected status %d"),
@@ -710,7 +702,7 @@ daemonStreamHandleRead(virNetServerClientPtr client,
                       daemonClientStream *stream)
 {
    char *buffer;
-    size_t bufferLen = VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX;
+    size_t bufferLen = VIR_NET_MESSAGE_PAYLOAD_MAX;
    int ret;

    VIR_DEBUG("client=%p, stream=%p tx=%d closed=%d",
--- a/daemon/test_libvirtd.aug.in
+++ b/daemon/test_libvirtd.aug.in
@@ -12,15 +12,11 @@ module Test_libvirtd =
        { "unix_sock_group" = "libvirt" }
        { "unix_sock_ro_perms" = "0777" }
        { "unix_sock_rw_perms" = "0770" }
-        { "unix_sock_admin_perms" = "0700" }
        { "unix_sock_dir" = "/var/run/libvirt" }
        { "auth_unix_ro" = "none" }
        { "auth_unix_rw" = "none" }
        { "auth_tcp" = "sasl" }
        { "auth_tls" = "none" }
-        { "access_drivers"
-             { "1" = "polkit" }
-        }
        { "key_file" = "/etc/pki/libvirt/private/serverkey.pem" }
        { "cert_file" = "/etc/pki/libvirt/servercert.pem" }
        { "ca_file" = "/etc/pki/CA/cacert.pem" }
@@ -35,19 +31,12 @@ module Test_libvirtd =
             { "1" = "joe@EXAMPLE.COM" }
             { "2" = "fred@EXAMPLE.COM" }
        }
-        { "max_clients" = "5000" }
-        { "max_queued_clients" = "1000" }
-        { "max_anonymous_clients" = "20" }
+        { "max_clients" = "20" }
        { "min_workers" = "5" }
        { "max_workers" = "20" }
        { "prio_workers" = "5" }
        { "max_requests" = "20" }
        { "max_client_requests" = "5" }
-        { "admin_min_workers" = "1" }
-        { "admin_max_workers" = "5" }
-        { "admin_max_clients" = "5" }
-        { "admin_max_queued_clients" = "5" }
-        { "admin_max_client_requests" = "5" }
        { "log_level" = "3" }
        { "log_filters" = "3:remote 4:event" }
        { "log_outputs" = "3:syslog:libvirtd" }
@@ -58,6 +47,3 @@ module Test_libvirtd =
        { "keepalive_interval" = "5" }
        { "keepalive_count" = "5" }
        { "keepalive_required" = "1" }
-        { "admin_keepalive_required" = "1" }
-        { "admin_keepalive_interval" = "5" }
-        { "admin_keepalive_count" = "5" }
--- a/docs/404.html.in
+++ b/docs/404.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>404 page not found</h1>

--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -1,20 +1,7 @@
 ## Process this file with automake to produce Makefile.in

-## Copyright (C) 2005-2015 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/>.
+## Copyright (C) 2005-2012 Red Hat, Inc.
+## See COPYING.LIB for the License of this software

 SUBDIRS= schemas

@@ -25,22 +12,11 @@ DOC_SOURCE_DIR=../src

 DEVHELP_DIR=$(datadir)/gtk-doc/html/libvirt

-apihtml =					\
-  html/index.html				\
-  $(apihtml_generated)
+BUILT_SOURCES=hvsupport.html.in

-apihtml_generated = \
-  html/libvirt-libvirt-domain.html		\
-  html/libvirt-libvirt-domain-snapshot.html	\
-  html/libvirt-libvirt-event.html		\
-  html/libvirt-libvirt-host.html		\
-  html/libvirt-libvirt-interface.html		\
-  html/libvirt-libvirt-network.html		\
-  html/libvirt-libvirt-nodedev.html		\
-  html/libvirt-libvirt-nwfilter.html		\
-  html/libvirt-libvirt-secret.html		\
-  html/libvirt-libvirt-storage.html		\
-  html/libvirt-libvirt-stream.html		\
+apihtml =			\
+  html/index.html		\
+  html/libvirt-libvirt.html	\
  html/libvirt-virterror.html

 apipng =	\
@@ -53,6 +29,7 @@ devhelphtml =			\
  devhelp/libvirt.devhelp	\
  devhelp/index.html		\
  devhelp/general.html		\
+  devhelp/libvirt-libvirt.html	\
  devhelp/libvirt-virterror.html

 css =         \
@@ -99,12 +76,6 @@ internals_html_in = \
  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.html.in))
 internals_html = $(internals_html_in:%.html.in=%.html)

-# todo.html is special - it is shipped in the tarball, but we
-# have a dedicated 'todo' target to rebuild it from a proper
-# config file, all other users are able to build it locally.
-# For all other files, since we ship pre-built html in the
-# tarball, we must also ship the sources, even when those
-# sources are themselves generated.
 dot_html_in = $(notdir $(wildcard $(srcdir)/*.html.in)) \
  todo.html.in \
  hvsupport.html.in
@@ -124,19 +95,8 @@ qemu_xml = \
  libvirt-qemu-api.xml \
  libvirt-qemu-refs.xml

-lxc_xml = \
-  libvirt-lxc-api.xml \
-  libvirt-lxc-refs.xml
-
-admin_xml = \
-  libvirt-admin-api.xml \
-  libvirt-admin-refs.xml
-
 apidir = $(pkgdatadir)/api
-api_DATA = \
-       libvirt-api.xml \
-       libvirt-qemu-api.xml \
-       libvirt-lxc-api.xml
+api_DATA = libvirt-api.xml libvirt-qemu-api.xml

 fig = \
  libvirt-net-logical.fig \
@@ -151,37 +111,28 @@ fig = \
  migration-unmanaged-direct.fig

 EXTRA_DIST=					\
-  apibuild.py genaclperms.pl \
+  apibuild.py \
  site.xsl newapi.xsl news.xsl page.xsl \
  hacking1.xsl hacking2.xsl wrapstring.xsl \
  $(dot_html) $(dot_html_in) $(gif) $(apihtml) $(apipng) \
  $(devhelphtml) $(devhelppng) $(devhelpcss) $(devhelpxsl) \
-  $(xml) $(qemu_xml) $(lxc_xml) $(fig) $(png) $(css) \
+  $(xml) $(qemu_xml) $(fig) $(png) $(css) \
  $(patches) $(dot_php_in) $(dot_php_code_in) $(dot_php)\
  $(internals_html_in) $(internals_html) \
-  sitemap.html.in aclperms.htmlinc \
+  sitemap.html.in \
  todo.pl hvsupport.pl todo.cfg-example

-acl_generated = aclperms.htmlinc
-
-$(srcdir)/aclperms.htmlinc: $(top_srcdir)/src/access/viraccessperm.h \
-        $(srcdir)/genaclperms.pl Makefile.am
-	$(AM_V_GEN)$(PERL) $(srcdir)/genaclperms.pl $< > $@
-
 MAINTAINERCLEANFILES = \
  $(addprefix $(srcdir)/,$(dot_html)) \
  $(addprefix $(srcdir)/,$(apihtml)) \
  $(addprefix $(srcdir)/,$(devhelphtml)) \
  $(addprefix $(srcdir)/,$(internals_html)) \
-  $(addprefix $(srcdir)/,$(dot_php)) \
-  $(srcdir)/hvsupport.html.in $(srcdir)/aclperms.htmlinc
+  $(addprefix $(srcdir)/,$(dot_php))

 all-am: web

 api: $(srcdir)/libvirt-api.xml $(srcdir)/libvirt-refs.xml
 qemu_api: $(srcdir)/libvirt-qemu-api.xml $(srcdir)/libvirt-qemu-refs.xml
-lxc_api: $(srcdir)/libvirt-lxc-api.xml $(srcdir)/libvirt-lxc-refs.xml
-admin_api: $(srcdir)/libvirt-admin-api.xml $(srcdir)/libvirt-admin-refs.xml

 web: $(dot_html) $(internals_html) html/index.html devhelp/index.html \
  $(dot_php)
@@ -193,36 +144,36 @@ todo.html.in: todo.pl
 		|| { rm $@ && exit 1; }; \
 	else \
 		echo "Stubbing $@"; \
-		printf "%s\n" \
-		  "<html xmlns=\"http://www.w3.org/1999/xhtml\">" \
-		  "<body>" \
-		  "<h1>Todo list unavailable: no config file</h1>" \
-		  "</body></html>" > $@ ; \
+		echo "<html><body><h1>Todo list</h1></body></html>" > $@ ; \
 	fi

 todo:
 	rm -f todo.html.in
 	$(MAKE) todo.html

-hvsupport.html:: $(srcdir)/hvsupport.html.in
-
-$(srcdir)/hvsupport.html.in: $(srcdir)/hvsupport.pl $(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)$(PERL) $(srcdir)/hvsupport.pl $(top_srcdir)/src > $@ \
-		|| { rm $@ && exit 1; }
+hvsupport.html.in: $(srcdir)/hvsupport.pl $(srcdir)/../src/libvirt_public.syms \
+	 $(srcdir)/../src/libvirt_qemu.syms $(srcdir)/../src/driver.h
+	$(AM_V_GEN)$(PERL) $(srcdir)/hvsupport.pl $(srcdir)/../src > $@ || { rm $@ && exit 1; }

 .PHONY: todo

 %.png: %.fig
 	convert -rotate 90 $< $@

-%.html.tmp: %.html.in site.xsl page.xsl sitemap.html.in $(acl_generated)
+internals/%.html.tmp: internals/%.html.in subsite.xsl page.xsl sitemap.html.in
+	@if [ -x $(XSLTPROC) ] ; then \
+	  echo "Generating $@"; \
+	  $(MKDIR_P) internals; \
+	  name=`echo $@ | sed -e 's/.tmp//'`; \
+	  $(XSLTPROC) --stringparam pagename $$name --nonet --html \
+	    $(top_srcdir)/docs/subsite.xsl $< > $@ \
+	    || { rm $@ && exit 1; }; fi
+
+%.html.tmp: %.html.in site.xsl page.xsl sitemap.html.in
 	@if [ -x $(XSLTPROC) ] ; then \
 	  echo "Generating $@"; \
 	  name=`echo $@ | sed -e 's/.tmp//'`; \
-	  $(XSLTPROC) --stringparam pagename $$name --nonet \
+	  $(XSLTPROC) --stringparam pagename $$name --nonet --html \
 	    $(top_srcdir)/docs/site.xsl $< > $@ \
 	    || { rm $@ && exit 1; }; fi

@@ -234,35 +185,32 @@ $(srcdir)/hvsupport.html.in: $(srcdir)/hvsupport.pl $(api_DATA) \
 	  SGML_CATALOG_FILES='$(XML_CATALOG_FILE)' \
 	  $(XMLLINT) --catalogs --nonet --format --valid $< > $(srcdir)/$@ \
 	  || { rm $(srcdir)/$@ && exit 1; }; \
-	  else echo "missing XHTML1 DTD"; cat $< > $(srcdir)/$@ ; fi ; fi
+	  else echo "missing XHTML1 DTD" ; fi ; fi

 %.php.tmp: %.php.in site.xsl page.xsl sitemap.html.in
 	@if [ -x $(XSLTPROC) ] ; then \
 	  echo "Generating $@"; \
-	  $(XSLTPROC) --stringparam pagename $(@:.tmp=) --nonet \
+	  $(XSLTPROC) --stringparam pagename $(@:.tmp=) --nonet --html \
 	    $(top_srcdir)/docs/site.xsl $< > $@ \
 	    || { rm $@ && exit 1; }; fi

 %.php: %.php.tmp %.php.code.in
 	@if [ -x $(XSLTPROC) ] ; then \
 	  echo "Scripting $@"; \
-	    sed -e '/<span id="php_placeholder"><\/span>/r '"$(srcdir)/$@.code.in" \
+	    sed -e '/<a id="php_placeholder"><\/a>/r '"$(srcdir)/$@.code.in" \
 	    -e /php_placeholder/d < $@.tmp > $(srcdir)/$@ \
 	    || { rm $(srcdir)/$@ && exit 1; }; fi

-$(apihtml_generated): html/index.html
-
 html/index.html: libvirt-api.xml newapi.xsl page.xsl sitemap.html.in
 	$(AM_V_GEN)if [ -x $(XSLTPROC) ] ; then \
 	  $(XSLTPROC) --nonet -o $(srcdir)/ \
-	  --stringparam builddir '$(abs_top_builddir)' \
 	  $(srcdir)/newapi.xsl $(srcdir)/libvirt-api.xml ; fi && \
 	if test -x $(XMLLINT) && test -x $(XMLCATALOG) ; then \
 	  if $(XMLCATALOG) '$(XML_CATALOG_FILE)' "-//W3C//DTD XHTML 1.0 Strict//EN" \
 	    > /dev/null ; then \
 	  SGML_CATALOG_FILES='$(XML_CATALOG_FILE)' \
 	  $(XMLLINT) --catalogs --nonet --valid --noout $(srcdir)/html/*.html ; \
-	  else echo "missing XHTML1 DTD"; cat $< > $(srcdir)/$@ ; fi ; fi
+	  else echo "missing XHTML1 DTD" ; fi ; fi

 $(addprefix $(srcdir)/,$(devhelphtml)): $(srcdir)/libvirt-api.xml $(devhelpxsl)
 	$(AM_V_GEN)if [ -x $(XSLTPROC) ] ; then \
@@ -271,19 +219,13 @@ $(addprefix $(srcdir)/,$(devhelphtml)): $(srcdir)/libvirt-api.xml $(devhelpxsl)


 python_generated_files = \
-		$(srcdir)/html/libvirt-libvirt-lxc.html \
+		$(srcdir)/html/libvirt-libvirt.html \
 		$(srcdir)/html/libvirt-libvirt-qemu.html \
-		$(srcdir)/html/libvirt-libvirt-admin.html \
 		$(srcdir)/html/libvirt-virterror.html \
 		$(srcdir)/libvirt-api.xml \
 		$(srcdir)/libvirt-refs.xml \
-		$(srcdir)/libvirt-lxc-api.xml \
-		$(srcdir)/libvirt-lxc-refs.xml \
 		$(srcdir)/libvirt-qemu-api.xml \
-		$(srcdir)/libvirt-qemu-refs.xml \
-		$(srcdir)/libvirt-admin-api.xml \
-		$(srcdir)/libvirt-admin-refs.xml \
-		$(NULL)
+		$(srcdir)/libvirt-qemu-refs.xml

 APIBUILD=$(srcdir)/apibuild.py
 APIBUILD_STAMP=$(APIBUILD).stamp
@@ -292,48 +234,27 @@ EXTRA_DIST += $(APIBUILD_STAMP)
 $(python_generated_files): $(APIBUILD_STAMP)

 $(APIBUILD_STAMP): $(srcdir)/apibuild.py \
-		$(top_srcdir)/include/libvirt/libvirt.h.in \
-		$(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-lxc.c \
-		$(top_srcdir)/src/libvirt-qemu.c \
-		$(top_srcdir)/src/libvirt-admin.c \
-		$(top_srcdir)/src/util/virerror.c \
-		$(top_srcdir)/src/util/virevent.c \
-		$(top_srcdir)/src/util/virtypedparam.c
+		$(srcdir)/../include/libvirt/libvirt.h.in \
+		$(srcdir)/../include/libvirt/libvirt-qemu.h \
+		$(srcdir)/../include/libvirt/virterror.h \
+		$(srcdir)/../src/libvirt.c \
+		$(srcdir)/../src/libvirt-qemu.c \
+		$(srcdir)/../src/util/virterror.c
 	$(AM_V_GEN)srcdir=$(srcdir) $(PYTHON) $(APIBUILD)
 	touch $@


 check-local: all
-dist-local: all

 clean-local:
 	rm -f *~ *.bak *.hierarchy *.signals *-unused.txt *.html

 maintainer-clean-local: clean-local
-	rm -rf $(srcdir)/libvirt-api.xml $(srcdir)/libvirt-refs.xml \
-		todo.html.in
+	rm -rf $(srcdir)/libvirt-api.xml $(srcdir)/libvirt-refs.xml todo.html.in hvsupport.html.in
 	rm -rf $(srcdir)/libvirt-qemu-api.xml $(srcdir)/libvirt-qemu-refs.xml
-	rm -rf $(srcdir)/libvirt-lxc-api.xml $(srcdir)/libvirt-lxc-refs.xml
-	rm -rf $(srcdir)/libvirt-admin-api.xml $(srcdir)/libvirt-admin-refs.xml
 	rm -rf $(APIBUILD_STAMP)

-rebuild: api qemu_api lxc_api admin_api all
+rebuild: api qemu_api all

 install-data-local:
 	$(mkinstalldirs) $(DESTDIR)$(HTML_DIR)
@@ -351,7 +272,6 @@ install-data-local:
 	for file in $(devhelphtml) $(devhelppng) $(devhelpcss); do \
 	    $(INSTALL) -m 0644 $(srcdir)/$${file} $(DESTDIR)$(DEVHELP_DIR) ; \
 	done
-	$(INSTALL_DATA) $(srcdir)/libvirtLogo.png $(DESTDIR)$(pkgdatadir)

 uninstall-local:
 	for h in $(apihtml); do rm $(DESTDIR)$(HTML_DIR)/$$h; done
--- a/docs/acl.html.in
+++ b/docs/acl.html.in
@@ -1,100 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<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 name="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 name="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 name="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>
--- a/docs/aclpolkit.html.in
+++ b/docs/aclpolkit.html.in
@@ -1,408 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<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 name="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 name="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 name="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 name="object_connect">virConnectPtr</a></h3>
-    <table class="acl">
-      <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 name="object_domain">virDomainPtr</a></h3>
-    <table class="acl">
-      <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 name="object_interface">virInterfacePtr</a></h3>
-    <table class="acl">
-      <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 name="object_network">virNetworkPtr</a></h3>
-    <table class="acl">
-      <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 name="object_node_device">virNodeDevicePtr</a></h3>
-    <table class="acl">
-      <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 name="object_nwfilter">virNWFilterPtr</a></h3>
-    <table class="acl">
-      <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 name="object_secret">virSecretPtr</a></h3>
-    <table class="acl">
-      <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>
-      </tbody>
-    </table>
-
-    <h3><a name="object_storage_pool">virStoragePoolPtr</a></h3>
-    <table class="acl">
-      <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 name="object_storage_vol">virStorageVolPtr</a></h3>
-    <table class="acl">
-      <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 name="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 name="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>
-
-    <h3><a name="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 name="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 a 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>
--- a/docs/api.html.in
+++ b/docs/api.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>The libvirt API concepts</h1>

@@ -9,31 +8,26 @@

    <ul id="toc"></ul>

-    <h2><a name="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"
+    <h2><a name="Objects">Objects exposed</a></h2>
+    <p> As defined in the <a href="goals.html">goals section</a>, libvirt
+    API need to expose all the resources needed to manage the virtualization
+    support of recent operating systems. The first object manipulated though
+    the API is <code>virConnectPtr</code> which represent a connection to
+    an hypervisor. Any application using libvirt is likely to start using the
+    API by calling one of <a href="html/libvirt-libvirt.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
+    a name argument which is actually an URI to select the right hypervisor to
+    open, this 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
+    <p> Once the application obtained a <code class='docref'>virConnectPtr</code>
+    connection to the
+    hypervisor it can then use it to manage domains and related resources
+    available for virtualization like 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"
@@ -41,340 +35,92 @@
    </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
+      <li>virConnectPtr: represent a connection to an hypervisor.</li>
+      <li>virDomainPtr: represent one domain either active or defined (i.e.
+      existing as permanent config file and storage but not currently running
+      on that node). The function <code class='docref'>virConnectListDomains</code>
+      allows to list all the IDs for the domains active on this hypervisor.</li>
+      <li>virNetworkPtr: represent one network either active or defined (i.e.
+      existing as permanent config file and storage but not currently activated.
+      The function <code class='docref'>virConnectListNetworks</code>
+      allows to list all the virtualization networks activated on this node.</li>
+      <li>virStorageVolPtr: represent one storage volume, usually this is 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>
+      <code class="docref">virStorageVolLookupByPath</code> allows to find
+      the object based on its path on the node.</li>
+      <li>virStoragePoolPtr: represent a storage pool, i.e. a logical area
+      which can be used to allocate and store storage volumes. The function
+      <code class="docref">virStoragePoolLookupByVolume</code> allows to find
+      the storage pool containing a given storage volume.</li>
    </ul>
-    <p> Most objects manipulated by the library can also be represented using
+    <p> Most object 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>
+    <p> Domains, network 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>
+      thay can be activated dynamically in order to be used.</p>
+    <p> Most kind of object 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
+      <li>by their <code>name</code>, an user friendly identifier but
+      whose unicity cannot be guaranteed between two nodes.</li>
+      <li>by their <code>ID</code>, which is a runtime unique identifier
+      provided by the hypervisor for one given activation of the object,
+      but it becomes invalid once the resource is deactivated.</li >
+      <li>by their <code>UUID</code>, a 16 bytes 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>
+      set of nodes.</li>
    </ul>

-    <h2><a name="Functions">Functions and Naming Conventions</a></h2>
+    <h2><a name="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
+      made of 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
+    <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 an 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>
+      <li><b>Lookup</b>:...LookupByName,</li>
+      <li><b>Enumeration</b>:virConnectList... and virConnectNumOf...:
+        those are used to enumerate a set of object available to an given
+        hypervisor connection like:
+        <code class='docref'>virConnectListDomains</code>,
+        <code class='docref'>virConnectNumOfDomains</code>,
+        <code class='docref'>virConnectListNetworks</code>,
+        <code class='docref'>virConnectListStoragePools</code>, etc.</li>
+      <li><b>Description</b>: ...GetInfo: those are generic accessor providing
+        a set of informations about an object, they are
+        <code class='docref'>virNodeGetInfo</code>,
+        <code class='docref'>virDomainGetInfo</code>,
+        <code class='docref'>virStoragePoolGetInfo</code>,
+        <code class='docref'>virStorageVolGetInfo</code>.</li>
+      <li><b>Accessors</b>: ...Get... and ...Set...: those are more specific
+        accessors to query or modify the given object, like
+        <code class='docref'>virConnectGetType</code>,
+        <code class='docref'>virDomainGetMaxMemory</code>,
+        <code class='docref'>virDomainSetMemory</code>,
+        <code class='docref'>virDomainGetVcpus</code>,
+        <code class='docref'>virStoragePoolSetAutostart</code>,
+        <code class='docref'>virNetworkGetBridgeName</code>, etc.</li>
+      <li><b>Creation</b>: </li>
+      <li><b>Destruction</b>: ... </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 name="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>
+    <h2><a name="Driver">The libvirt drivers</a></h2>
+    <p></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 name="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,
-    Power VM (phyp), 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>
-
+    <h2><a name="Remote">Daemon and remote access</a></h2>
+    <p></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>
--- a/docs/api_extension.html.in
+++ b/docs/api_extension.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Implementing a new API in Libvirt</h1>

@@ -180,13 +178,12 @@
        being called and its parameters;</li>
      <li>MUST call virResetLastError();</li>
      <li>SHOULD confirm that the connection is valid with
-        virCheckConnectReturn() or virCheckConnectGoto();</li>
+        VIR_IS_CONNECT(conn);</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>
+          indicate that the connection is read-only;</strong></li>
      <li>SHOULD do basic validation of the parameters that are being
-        passed in, using helpers like virCheckNonNullArgGoto();</li>
+        passed in;</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>
--- a/docs/apibuild.py
+++ b/docs/apibuild.py
--- a/docs/apps.html.in
+++ b/docs/apps.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Applications using <strong>libvirt</strong></h1>

@@ -103,19 +101,6 @@
        in a virtual machine.  It prints out a list of facts about the
        virtual machine, derived from heuristics.
      </dd>
-      <dt><a href="http://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>
    </dl>

    <h2><a name="configmgmt">Configuration Management</a></h2>
@@ -163,21 +148,25 @@
    <h2><a name="conversion">Conversion</a></h2>

    <dl>
-      <dt><a href="http://libguestfs.org/virt-p2v.1.html">virt-p2v</a></dt>
+      <dt><a href="https://rwmj.wordpress.com/2009/10/13/poor-mans-p2v/">Poor mans 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)
+        A simple approach for converting a physical machine to a virtual
+        machine, using a rescue CD.
      </dd>
-      <dt><a href="http://libguestfs.org/virt-v2v.1.html">virt-v2v</a></dt>
+      <dt><a href="http://et.redhat.com/~rjones/virt-p2v/">virt-p2v</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
+        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>
+      <dt><a href="http://git.fedorahosted.org/git/?p=virt-v2v.git;a=summary">virt-v2v</a></dt>
+      <dd>
+        virt-v2v converts guests from a foreign hypervisor to run on KVM,
+        managed by libvirt.  It can currently convert Red Hat Enterprise
+        Linux (RHEL) and Fedora guests running on Xen and VMware ESX.  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
@@ -213,13 +202,6 @@
    <h2><a name="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="http://www.emotivecloud.net">EMOTIVE Cloud</a></dt>
      <dd>The EMOTIVE (Elastic Management Of Tasks In Virtualized
        Environments) middleware allows executing tasks and providing
@@ -253,15 +235,6 @@
        integrates libvirt for VM monitoring, live migration, and life-cycle
        management.
      </dd>
-
-      <dt><a href="http://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>
    </dl>

    <h2><a name="libraries">Libraries</a></h2>
@@ -279,24 +252,19 @@
        host, and there is a subproject to allow merging changes into the
        Windows Registry in Windows guests.
      </dd>
-
-      <dt><a href="http://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="http://libvirt.org/ruby">native ruby bindings</a>.
-      </dd>
    </dl>

+        <dl>
+            <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="http://libvirt.org/ruby">native ruby
+                bindings</a>.
+            </dd>
+        </dl>
    <h2><a name="livecd">LiveCD / Appliances</a></h2>

    <dl>
@@ -321,12 +289,6 @@
        For a full description, please refer to the libvirt section in the
        collectd.conf(5) manual page.
      </dd>
-      <dt><a href="http://host-sflow.sourceforge.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="http://honk.sigxcpu.org/projects/libvirt/#munin">Munin</a></dt>
      <dd>
        The plugins provided by Guido G&uuml;nther allow to monitor various things
@@ -378,7 +340,6 @@
          <li>Shows you Systems Inventory (based on Facter) and
          provides real time information about hosts status based on
          Puppet reports.</li>
-      </ul>
      </dd>
    </dl>

@@ -401,23 +362,6 @@
        with FreeIPA for Kerberos authentication, and in the future,
        certificate management.
      </dd>
-      <dt><a href="http://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="http://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>
    </dl>

    <h2><a name="mobile">Mobile applications</a></h2>
--- a/docs/archdomain.html.in
+++ b/docs/archdomain.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Domain management architecture</h1>
  </body>
--- a/docs/architecture.html.in
+++ b/docs/architecture.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1 >libvirt architecture</h1>

--- a/docs/archnetwork.html.in
+++ b/docs/archnetwork.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>Network management architecture</h1>

--- a/docs/archnode.html.in
+++ b/docs/archnode.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Node device management architecture</h1>
  </body>
--- a/docs/archstorage.html.in
+++ b/docs/archstorage.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Storage management architecture</h1>

--- a/docs/auditlog.html.in
+++ b/docs/auditlog.html.in
@@ -1,356 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Audit log</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a name="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 name="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 name="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>pid</dt>
-      <dd>Process ID of the libvirtd daemon generating the audit record.</dd>
-      <dt>uid</dt>
-      <dd>User ID of the libvirtd daemon process generating the audit record.</dd>
-      <dt>subj</dt>
-      <dd>Security context of the libvirtd daemon process generating the audit record.</dd>
-      <dt>msg</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>virt</dt>
-      <dd>Type of virtualization driver used. One of <code>qemu</code> or <code>lxc</code></dd>
-      <dt>vm</dt>
-      <dd>Host driver unique name of the guest</dd>
-      <dt>uuid</dt>
-      <dd>Globally unique identifier for the guest</dd>
-      <dt>exe</dt>
-      <dd>Path of the libvirtd daemon</dd>
-      <dt>hostname</dt>
-      <dd>Currently unused</dd>
-      <dt>addr</dt>
-      <dd>Currently unused</dd>
-      <dt>terminal</dt>
-      <dd>Currently unused</dd>
-      <dt>res</dt>
-      <dd>Result of the action, either <code>success</code> or <code>failed</code></dd>
-    </dl>
-
-    <h3><a name="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>op</dt>
-      <dd>Type of operation performed. One of <code>start</code>, <code>stop</code> or <code>init</code></dd>
-      <dt>reason</dt>
-      <dd>The reason which caused the operation to happen</dd>
-      <dt>vm-pid</dt>
-      <dd>ID of the primary/leading process associated with the guest</dd>
-      <dt>init-pid</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>pid-ns</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 name="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>model</dt>
-      <dd>The security driver type. One of <code>selinux</code> or <code>apparmor</code></dd>
-      <dt>vm-ctx</dt>
-      <dd>Security context for the guest process</dd>
-      <dt>img-ctx</dt>
-      <dd>Security context for the guest disk images and other assigned host resources</dd>
-    </dl>
-
-    <h3><a name="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 name="typeresourcevcpu">Virtual CPU</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>vcpu</code></dd>
-      <dt>old-vcpu</dt>
-      <dd>Original vCPU count, or 0</dd>
-      <dt>new-vcpu</dt>
-      <dd>Updated vCPU count</dd>
-    </dl>
-
-
-    <h4><a name="typeresourcemem">Memory</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>mem</code></dd>
-      <dt>old-mem</dt>
-      <dd>Original memory size in bytes, or 0</dd>
-      <dt>new-mem</dt>
-      <dd>Updated memory size in bytes</dd>
-    </dl>
-
-    <h4><a name="typeresourcedisk">Disk</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>disk</code></dd>
-      <dt>old-disk</dt>
-      <dd>Original host file or device path acting as the disk backing file</dd>
-      <dt>new-disk</dt>
-      <dd>Updated host file or device path acting as the disk backing file</dd>
-    </dl>
-
-    <h4><a name="typeresourcenic">Network interface</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>net</code></dd>
-      <dt>old-net</dt>
-      <dd>Original MAC address of the guest network interface</dd>
-      <dt>new-net</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>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>net</code></dd>
-      <dt>net</dt>
-      <dd>MAC address of the host network interface</dd>
-      <dt>rdev</dt>
-      <dd>Name of the host network interface</dd>
-    </dl>
-
-    <h4><a name="typeresourcefs">Filesystem</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>fs</code></dd>
-      <dt>old-fs</dt>
-      <dd>Original host directory, file or device path backing the filesystem </dd>
-      <dt>new-fs</dt>
-      <dd>Updated host directory, file or device path backing the filesystem</dd>
-    </dl>
-
-    <h4><a name="typeresourcehost">Host device</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>hostdev</code> or <code>dev</code></dd>
-      <dt>dev</dt>
-      <dd>The unique bus identifier of the USB, PCI or SCSI device, if <code>resrc=dev</code></dd>
-      <dt>disk</dt>
-      <dd>The path of the block device assigned to the guest, if <code>resrc=hostdev</code></dd>
-      <dt>chardev</dt>
-      <dd>The path of the character device assigned to the guest, if <code>resrc=hostdev</code></dd>
-    </dl>
-
-    <h4><a name="typeresourcetpm">TPM</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>tpm</code></dd>
-      <dt>device</dt>
-      <dd>The path of the host TPM device assigned to the guest</dd>
-    </dl>
-
-    <h4><a name="typeresourcerng">RNG</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>rng</code></dd>
-      <dt>old-rng</dt>
-      <dd>Original path of the host entropy source for the RNG</dd>
-      <dt>new-rng</dt>
-      <dd>Updated path of the host entropy source for the RNG</dd>
-    </dl>
-
-    <h4><a name="typeresourcechardev">console/serial/parallel/channel</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>chardev</code></dd>
-      <dt>old-chardev</dt>
-      <dd>Original path of the backing character device for given emulated device</dd>
-      <dt>new-chardev</dt>
-      <dd>Updated path of the backing character device for given emulated device</dd>
-    </dl>
-
-    <h4><a name="typeresourcesmartcard">smartcard</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>smartcard</code></dd>
-      <dt>old-smartcard</dt>
-      <dd>Original path of the backing character device, certificate store or
-          "nss-smartcard-device" for host smartcard passthrough.
-      </dd>
-      <dt>new-smartcard</dt>
-      <dd>Updated path of the backing character device, certificate store or
-          "nss-smartcard-device" for host smartcard passthrough.
-      </dd>
-    </dl>
-
-    <h4><a name="typeresourceredir">Redirected device</a></h4>
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>redir</code></dd>
-      <dt>bus</dt>
-      <dd>The bus type, only <code>usb</code> allowed</dd>
-      <dt>device</dt>
-      <dd>The device type, only <code>USB redir</code> allowed</dd>
-    </dl>
-
-    <h4><a name="typeresourcecgroup">Control group</a></h4>
-
-    <p>
-      The <code>msg</code> field will include the following sub-fields
-    </p>
-
-    <dl>
-      <dt>reason</dt>
-      <dd>The reason which caused the resource to be assigned to happen</dd>
-      <dt>resrc</dt>
-      <dd>The type of resource assigned. Set to <code>cgroup</code></dd>
-      <dt>cgroup</dt>
-      <dd>The name of the cgroup controller</dd>
-    </dl>
-
-  </body>
-</html>
--- a/docs/auth.html.in
+++ b/docs/auth.html.in
@@ -1,15 +1,12 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
-    <h1>Connection authentication</h1>
+    <h1 >Authentication &amp; access control</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.
+      of applications using libvirt.
    </p>

    <ul id="toc"></ul>
@@ -256,15 +253,13 @@ Plugin "gssapiv2" [loaded],     API version: 4
        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>
+Next it is necessary for the administrator of the Kerberos realm to issue a principle
+for the libvirt server. There needs to be one principle per host running the libvirt
+daemon. The principle 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 principles.
+Once created, the principle 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
@@ -286,7 +281,7 @@ kadmin.local: quit
 </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
+merely needs to run <code>kinit</code> to gain a user principle. This may well
 be done automatically when a user logs into a desktop session, if PAM is setup
 to authenticate against Kerberos.
 </p>
--- a/docs/bindings.html.in
+++ b/docs/bindings.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1 >Bindings for other languages</h1>

@@ -44,10 +43,8 @@
      </li>
      <li>
        <p>
-          <strong>Python</strong>: Libvirt's python bindings are split to a
-          separate <a href="http://libvirt.org/git/?p=libvirt-python.git">package</a>
-          since version 1.2.0, older versions came with direct support for the
-          Python language.
+          <strong>Python</strong>: Libvirt comes with direct support for
+          the Python language.
        </p>
        <p>
          If your libvirt is installed as packages, rather than compiled
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -1,24 +1,11 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>

    <h1>Bug reporting</h1>

    <ul id="toc"></ul>

-    <h2><a name="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 name="bugzilla">Bug Tracking</a></h2>

    <p>
@@ -132,7 +119,7 @@
      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
+      data to be really useful libvirt debug informations 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>
@@ -147,11 +134,11 @@
      <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
+.... some informations about gdb and loading debug data
+(gdb) attach $the_damon_process_id
 ....
 (gdb) thread apply all bt
-.... information to attach to the bug
+.... informations to attach to the bug
 (gdb)
 </pre>

--- a/docs/cgroups.html.in
+++ b/docs/cgroups.html.in
@@ -1,417 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<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 name="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>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 name="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 name="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 name="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 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-demo</code> which when escaped is
-      <code>lxc\x2ddemo</code>. So the complete scope name is <code>machine-lxc\x2ddemo.scope</code>.
-      The scope names map directly to the cgroup directory names.
-    </p>
-
-    <h4><a name="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 name="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\x2dvm1.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-qemu\x2dvm2.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-qemu\x2dvm3.scope
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- machine-engineering.slice
-      |   |
-      |   +- machine-engineering-testing.slice
-      |   |   |
-      |   |   +- machine-lxc\x2dcontainer1.scope
-      |   |
-      |   +- machine-engineering-production.slice
-      |       |
-      |       +- machine-lxc\x2dcontainer2.scope
-      |
-      +- machine-marketing.slice
-          |
-          +- machine-lxc\x2dcontainer3.scope
-    </pre>
-
-    <h3><a name="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
-      are the three top level default partitions, named <code>/system</code> (for
-      system services), <code>/user</code> (for user login sessions) and
-      <code>/machine</code> (for virtual machines and containers). By default
-      every consumer will of course be associated with the <code>/machine</code>
-      partition.
-    </p>
-
-    <p>
-      Given this, a possible systemd cgroups layout involving 3 qemu guests,
-      3 lxc containers and 2 custom child slices, would be:
-    </p>
-
-    <pre>
-$ROOT
-  |
-  +- system
-  |   |
-  |   +- libvirtd.service
-  |
-  +- machine
-      |
-      +- vm1.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- vm2.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- vm3.libvirt-qemu
-      |   |
-      |   +- emulator
-      |   +- vcpu0
-      |   +- vcpu1
-      |
-      +- engineering.partition
-      |   |
-      |   +- testing.partition
-      |   |   |
-      |   |   +- container1.libvirt-lxc
-      |   |
-      |   +- production.partition
-      |       |
-      |       +- container2.libvirt-lxc
-      |
-      +- marketing.partition
-          |
-          +- container3.libvirt-lxc
-    </pre>
-
-    <h2><a name="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 name="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 name="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 name="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 name="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>
--- a/docs/compiling.html.in
+++ b/docs/compiling.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1><a name="installation">libvirt Installation</a></h1>

@@ -65,36 +64,8 @@
      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
+      will turn on -Werror for builds. This can be disabled with --disable-werror,
+      but this is not recommended. To build &amp; install libvirt to your home
      directory the following commands can be run:
    </p>

--- a/docs/contact.html.in
+++ b/docs/contact.html.in
@@ -1,23 +1,10 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>Contacting the development team</h1>

    <ul id="toc"></ul>

-    <h2><a name="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 name="email">Mailing lists</a></h2>

    <p>
--- a/docs/csharp.html.in
+++ b/docs/csharp.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>C# API bindings</h1>

--- a/docs/deployment.html.in
+++ b/docs/deployment.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Deployment</h1>

--- a/docs/devguide.html.in
+++ b/docs/devguide.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>libvirt Application Development Guide</h1>

--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Documentation</h1>
  </body>
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>Downloads</h1>

@@ -22,9 +21,7 @@
    <p>
      Once an hour, an automated snapshot is made from the git server
      source tree. These snapshots should be usable, but we make no guarantees
-      about their stability; furthermore, they should NOT be
-      considered formal releases, and they may have transient security
-      problems that will not be assigned a CVE.
+      about their stability:
    </p>

    <ul>
@@ -32,28 +29,6 @@
      <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li>
    </ul>

-    <h2><a name="maintenance">Maintenance releases</a></h2>
-    <p>
-      In the git repository are several stable maintenance branches,
-      matching the
-      pattern <code>v<i>major</i>.<i>minor</i>.<i>micro</i>-maint</code>;
-      these branches are forked off the corresponding
-      <code>v<i>major</i>.<i>minor</i>.<i>micro</i></code> formal
-      release, and may have further releases of the
-      form <code>v<i>major</i>.<i>minor</i>.<i>micro</i>.<i>rel</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.
-    </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 name="git">GIT source repository</a></h2>

    <p>
@@ -71,20 +46,6 @@
    <pre>
      <a href="http://libvirt.org/git/?p=libvirt.git;a=summary">http://libvirt.org/git/?p=libvirt.git;a=summary</a></pre>

-    <p>
-      In addition to this 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/libvirt">https://github.com/libvirt/libvirt</a>
-      <a href="http://repo.or.cz/w/libvirt.git">http://repo.or.cz/w/libvirt.git</a>
-      <a href="https://gitlab.com/libvirt/libvirt">https://gitlab.com/libvirt/libvirt</a></pre>
-
    <br />

    <h1>libvirt Application Development Guide</h1>
--- a/docs/drivers.html.in
+++ b/docs/drivers.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Internal drivers</h1>

@@ -32,8 +30,6 @@
      <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="drvphyp.html">IBM PowerVM (phyp)</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>

    <h2><a name="storage">Storage drivers</a></h2>
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve.html.in
@@ -1,282 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<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.
-</p>
-
-<p>
-Additional information on bhyve could be obtained on <a href="http://bhyve.org/">bhyve.org</a>.
-</p>
-
-<h2><a name="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 name="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>
-
-<h2><a name="usage">Guest usage / management</a></h2>
-
-<h3><a name="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> An 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 name="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 name="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 name="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 name="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>
-
-  </body>
-</html>
--- a/docs/drvesx.html.in
+++ b/docs/drvesx.html.in
@@ -1,7 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
+<html><body>
    <h1>VMware ESX hypervisor driver</h1>
    <ul id="toc"></ul>
    <p>
@@ -148,7 +145,7 @@ vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
            </td>
            <td>
                If set to 1, this disables libcurl client checks of the server's
-                SSL certificate. The default value is 0. See the
+                SSL certificate. The default value it 0. See the
                <a href="#certificates">Certificates for HTTPS</a> section for
                details.
            </td>
@@ -164,7 +161,7 @@ vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
                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>.
+                value it 0. <span class="since">Since 0.7.5</span>.
            </td>
        </tr>
        <tr>
--- a/docs/drvhyperv.html.in
+++ b/docs/drvhyperv.html.in
@@ -1,7 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
+<html><body>
    <h1>Microsoft Hyper-V hypervisor driver</h1>
    <ul id="toc"></ul>
    <p>
--- a/docs/drvlxc.html.in
+++ b/docs/drvlxc.html.in
@@ -1,100 +1,49 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <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.
+The libvirt LXC driver manages "Linux Containers".  Containers are sets of processes
+with private namespaces which can (but don't always) look like separate machines, but
+do not have their own OS.  Here are two example configurations.  The first is a very
+light-weight "application container" which does not have its own root image.
 </p>

-<h2><a name="cgroups">Control groups Requirements</a></h2>
+    <h2><a name="project">Project Links</a></h2>
+
+    <ul>
+      <li>
+        The <a href="http://lxc.sourceforge.net/">LXC</a> Linux
+        container system
+      </li>
+    </ul>
+
+<h2>Cgroups Requirements</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 name="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 name="init">Default container setup</a></h2>
-
-<h3><a name="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
+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'. The /etc/cgconfig.conf &amp; cgconfig
+init service used to mount cgroups at host boot time. To manually
+mount them use:
 </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;
+ # mount -t cgroup cgroup /dev/cgroup -o cpuacct,memory,devices,cpu,freezer,blkio
 </pre>

-<h3><a name="envvars">Environment variables</a></h3>
+<p>
+NB, the blkio controller in some kernels will not allow creation of nested
+sub-directories which will prevent correct operation of the libvirt LXC
+driver. On such kernels, it may be necessary to unmount the blkio controller.
+</p>
+
+
+<h2>Environment setup for the container init</h2>

 <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>container</dt>
-<dd>The fixed string <code>libvirt-lxc</code> to identify libvirt as the creator</dd>
-<dt>container_uuid</dt>
-<dd>The UUID assigned to the container by libvirt</dd>
-<dt>PATH</dt>
-<dd>The fixed string <code>/bin:/usr/bin</code></dd>
-<dt>TERM</dt>
-<dd>The fixed string <code>linux</code></dd>
-<dt>HOME</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
+environment variables.
 </p>

 <dl>
@@ -103,381 +52,9 @@ environment variables are also provided
 <dt>LIBVIRT_LXC_UUID</dt>
 <dd>The UUID assigned to the container by libvirt</dd>
 <dt>LIBVIRT_LXC_CMDLINE</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>
+<dd>The unparsed command line arguments specified in the container configuration</dd>
 </dl>

-<h3><a name="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 name="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 name="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 name="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 name="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 name="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 name="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:/// start --pass-fds 3 mycontainer
-ExecStop=/usr/bin/virsh -c lxc:/// 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 an 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 name="exconfig">Example configurations</a></h2>

 <h3>Example config version 1</h3>
 <p></p>
@@ -542,267 +119,21 @@ debootstrap, whatever) under /opt/vm-1-root:
 &lt;/domain&gt;
 </pre>

-<h2><a name="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:
+In both cases, you can define and start a container using:</p>
+<pre>
+virsh --connect lxc:/// define v1.xml
+virsh --connect lxc:/// start vm1
+</pre>
+and then get a console  using:
+<pre>
+virsh --connect lxc:/// console vm1
+</pre>
+<p>Now doing 'ps -ef' will only show processes in the container, for
+instance.  You can undefine it using
 </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;
-...
+virsh --connect lxc:/// undefine vm1
 </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 name="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>
-
-<h2><a name="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:///</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:///</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 name="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:/// define myguest.xml
-</pre>
-
-<h3><a name="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:/// dumpxml myguest
-</pre>
-
-<h3><a name="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:/// 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:/// create myguest.xml
-</pre>
-
-
-<h3><a name="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:/// 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:/// destroy myguest
-</pre>
-
-
-<h3><a name="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:/// reboot myguest
-</pre>
-
-<h3><a name="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:/// undefine myguest
-</pre>
-
-<h3><a name="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:/// 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:/// console myguest --devname console1
-</pre>
-
-<h3><a name="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:/// lxc-enter-namespace myguest -- /bin/ls -al /dev
-</pre>
-
-<h3><a name="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:///
-</pre>
-
-<h3><a name="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:/// 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>
--- a/docs/drvopenvz.html.in
+++ b/docs/drvopenvz.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html> <!-- -*- html -*- -->
  <body>
    <h1>OpenVZ container driver</h1>

--- a/docs/drvparallels.html.in
+++ b/docs/drvparallels.html.in
@@ -1,44 +1,41 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Virtuozzo driver</h1>
+<html><body>
+    <h1>Parallels Cloud Server driver</h1>
    <ul id="toc"></ul>
    <p>
-        The libvirt vz driver can manage Virtuozzo starting from version 6.0.
+        The libvirt Parallels driver can manage Parallels Cloud Server starting from version 6.0.
    </p>


    <h2><a name="project">Project Links</a></h2>
    <ul>
      <li>
-        The <a href="http://www.odin.com/products/virtuozzo/">Virtuozzo</a> Solution.
+        The <a href="http://www.parallels.com/products/server/baremetal/sp/">Parallels Cloud Server</a> Virtualization Solution.
      </li>
    </ul>


-    <h2><a name="uri">Connections to the Virtuozzo driver</a></h2>
+    <h2><a name="uri">Connections to the Parallels Cloud Server 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:
+        The libvirt Parallels driver is a single-instance privileged driver, with a driver name of 'parallels'. 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)
+parallels:///system                     (local access)
+parallels+unix:///system                (local access)
+parallels://example.com/system          (remote access, TLS/x509)
+parallels+tcp://example.com/system      (remote access, SASl/Kerberos)
+parallels+ssh://root@example.com/system (remote access, SSH tunnelled)
 </pre>

    <h2><a name="example">Example guest domain XML configuration</a></h2>

    <p>
-    Virtuozzo driver require at least one hard disk for new domains
+    Parallels 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;domain type='parallels'&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;
--- a/docs/drvphyp.html.in
+++ b/docs/drvphyp.html.in
@@ -1,7 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
+<html><body>
    <h1>IBM PowerVM hypervisor driver (phyp)</h1>
    <ul id="toc"></ul>
    <p>
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>KVM/QEMU hypervisor driver</h1>

@@ -19,7 +17,6 @@
      <li>
        The <a href="http://www.linux-kvm.org/">KVM</a> Linux
        hypervisor
-      </li>
      <li>
        The <a href="http://wiki.qemu.org/Index.html">QEMU</a> emulator
      </li>
@@ -560,7 +557,6 @@ $ virsh domxml-to-native qemu-argv demo.xml
      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
@@ -573,6 +569,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
          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;
--- a/docs/drvremote.html.in
+++ b/docs/drvremote.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Remote management driver</h1>
  </body>
--- a/docs/drvtest.html.in
+++ b/docs/drvtest.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Test "mock" driver</h1>

--- a/docs/drvuml.html.in
+++ b/docs/drvuml.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>User Mode Linux driver</h1>

@@ -65,7 +63,7 @@ uml+ssh://root@example.com/system    (remote access, SSH tunnelled)
    </p>

    <p>
-      Once booted the primary console is connected to a PTY, and
+      Once booted the primary console is connected toa PTY, and
      thus accessible with "virsh console" or equivalent tools
    </p>

--- a/docs/drvvbox.html.in
+++ b/docs/drvvbox.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
    <body>
        <h1>VirtualBox hypervisor driver</h1>
        <p>
@@ -31,18 +29,6 @@ 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 name="xmlconfig">Example domain XML config</a></h2>

 <pre>
--- a/docs/drvvmware.html.in
+++ b/docs/drvvmware.html.in
@@ -1,12 +1,9 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
    <body>
-        <h1>VMware Workstation / Player / Fusion hypervisors driver</h1>
+        <h1>VMware Workstation / Player 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
+        The libvirt VMware Workstation driver should be able to manage any Workstation and
+        Player 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>
@@ -22,22 +19,17 @@
        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:
+    Two 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:
@@ -46,7 +38,6 @@
 <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>
--- a/docs/drvxen.html.in
+++ b/docs/drvxen.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Xen hypervisor driver</h1>

--- a/docs/errors.html.in
+++ b/docs/errors.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1 >Handling of errors</h1>
    <p>The main goals of libvirt when it comes to error handling are:</p>
@@ -46,9 +45,9 @@ following fields:</p>
      <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>
+      <li>conn: if available a pointer to the <a href="html/libvirt-libvirt.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
+      <li>dom: if available a pointer to the <a href="html/libvirt-libvirt.html#virDomainPtr">virDomainPtr</a> domain
    targeted in the operation</li>
    </ul>
    <p>and then extra raw information about the error which may be initialized
--- a/docs/firewall.html.in
+++ b/docs/firewall.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1 >Firewall and network filtering in libvirt</h1>
    <p>There are three pieces of libvirt functionality which do network
@@ -142,7 +141,7 @@ MASQUERADE all  --  *      *       192.168.122.0/24    !192.168.122.0/24</pre>
    <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
+       that requires their functionality, instead tieing 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
@@ -199,7 +198,7 @@ using an XML format. At a high level the format looks like this:
    </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.:
+       optional priority. eg:
    </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
@@ -272,7 +271,7 @@ f5c78134-9da4-0c60-a9f0-fb37bc21ac1f  no-other-rarp-traffic
       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
+    <p>To associate the clean-trafffic 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
--- a/docs/format.html.in
+++ b/docs/format.html.in
@@ -1,5 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<?xml version="1.0"?>
 <html xmlns="http://www.w3.org/1999/xhtml">
  <body>
    <h1 >XML Format</h1>
--- a/docs/formatcaps.html.in
+++ b/docs/formatcaps.html.in
@@ -1,150 +1,20 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Driver capabilities XML format</h1>

-    <ul id="toc"></ul>
-
-    <h2><a name="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 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 name="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 name="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>xen</dt>
-          <dd>for XEN</dd>
-
-          <dt>linux</dt>
-          <dd>legacy alias for <code>xen</code></dd>
-
-          <dt>hvm</dt>
-          <dd>Unmodified operating system</dd>
-
-          <dt>exe</dt>
-          <dd>Container based virtualization</dd>
-
-          <dt>uml</dt>
-          <dd>User Mode Linux</dd>
-        </dl>
-        </dd>
-
-        <dt><code>arch</code></dt>
-        <dd>This element brings some information on supported guest architecture.</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>pae</dt><dd>If present, 32-bit guests can use PAE
-              address space extensions, <span class="since">since
-              0.4.1</span></dd>
-            <dt>nonpae</dt><dd>If present, 32-bit guests can be run
-              without requiring PAE, <span class="since">since
-              0.4.1</span></dd>
-            <dt>ia64_be</dt><dd>If present, IA64 guests can be run in
-              big-endian mode, <span class="since">since 0.4.1</span></dd>
-            <dt>acpi</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>apic</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>cpuselection</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>deviceboot</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>disksnapshot</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 name="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;
+        <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. For example in the case of a 64 bits
+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;
@@ -195,5 +65,30 @@
  &lt;/guest&gt;</span>
  ...
 &lt;/capabilities&gt;</pre>
+        <p>The first block (in red) indicates the host hardware
+          capabilities, such as CPU properties and the power
+          management features of the host platform.  CPU models are
+          shown as additional features relative to the closest base
+          model, within a feature block (the block is similar to what
+          you will find in a Xen fully virtualized domain
+          description). Further, the power management features
+          supported by the host are shown, such as Suspend-to-RAM (S3),
+          Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3
+          and S4). In case the host does not support
+          any such feature, then an empty &lt;power_management/&gt;
+          tag will be shown. </p>
+        <p>The second block (in blue) indicates the paravirtualization
+          support of the Xen support, you will see the os_type of xen
+          to indicate a paravirtual kernel, then architecture
+          information and potential features.</p>
+        <p>The third block (in green) gives similar information but
+          when running a 32 bit OS fully virtualized with Xen using
+          the hvm support.</p>
+        <p>This section is likely to be updated and augmented in the
+          future,
+          see <a href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the
+          discussion</a> which led to the capabilities format in the
+          mailing-list archives.</p>
+
  </body>
 </html>
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
--- a/docs/formatdomaincaps.html.in
+++ b/docs/formatdomaincaps.html.in
@@ -1,281 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Domain capabilities XML format</h1>
-
-    <ul id="toc"></ul>
-
-    <h2><a name="Overview">Overview</a></h2>
-
-    <p>Sometimes, when a new domain is to be created it may come handy to know
-    the capabilities of the hypervisor so the correct combination of devices and
-    drivers is used. For example, when management application is considering the
-    mode for a host device's passthrough there are several options depending not
-    only on host, but on hypervisor in question too. If the hypervisor is qemu
-    then it needs to be more recent to support VFIO, while legacy KVM is
-    achievable just fine with older qemus.</p>
-
-    <p>The main difference between
-      <a href="/html/libvirt-libvirt-host.html#virConnectGetCapabilities">
-        <code>virConnectGetCapabilities</code>
-      </a>
-    and the emulator capabilities API is, the former one aims more on
-    the host capabilities (e.g.  NUMA topology, security models in
-    effect, etc.) while the latter one specializes on the hypervisor
-    capabilities.</p>
-
-    <p>While the <a href="formatcaps.html">Driver Capabilities</a> provides the
-    host capabilities (e.g NUMA topology, security models in effect, etc.), the
-    Domain Capabilities provides the hypervisor specific capabilities for
-    Management Applications to query and make decisions regarding what to
-    utilize.</p>
-
-    <p>The Domain Capabilities can provide information such as the correct
-    combination of devices and drivers that are supported. Knowing which host
-    and hypervisor specific options are available or supported would allow the
-    management application to choose an appropriate mode for a pass-through
-    host device as well as which adapter to utilize.</p>
-
-    <h2><a name="elements">Element and attribute overview</a></h2>
-
-    <p> A new query interface was added to the virConnect API's to retrieve the
-    XML listing of the set of domain capabilities (<span class="since">Since
-    1.2.7</span>):</p>
-
-<pre>
-<a href="/html/libvirt-libvirt-domain.html#virConnectGetDomainCapabilities">virConnectGetDomainCapabilities</a>
-</pre>
-
-    <p>The root element that emulator capability XML document starts with has
-    name <code>domainCapabilities</code>. It contains at least four direct
-    child elements:</p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  &lt;path&gt;/usr/bin/qemu-system-x86_64&lt;/path&gt;
-  &lt;domain&gt;kvm&lt;/domain&gt;
-  &lt;machine&gt;pc-i440fx-2.1&lt;/machine&gt;
-  &lt;arch&gt;x86_64&lt;/arch&gt;
-  ...
-&lt;/domainCapabilities&gt;
-</pre>
-    <dl>
-      <dt>path</dt>
-      <dd>The full path to the emulator binary.</dd>
-
-      <dt>domain</dt>
-      <dd>Describes the <a href="formatdomain.html#elements">virtualization
-          type</a> (or so called domain type).</dd>
-
-      <dt>machine</dt>
-      <dd>The domain's <a href="formatdomain.html#elementsOSBIOS">machine
-          type</a>.</dd>
-
-      <dt>arch</dt>
-      <dd>The domain's <a href="formatdomain.html#elementsOSBIOS">
-          architecture</a>.</dd>
-
-    </dl>
-
-    <h3><a name="elementsCPUAllocation">CPU Allocation</a></h3>
-
-    <p>Before any devices capability occurs, there might be a info on domain
-    wide capabilities, e.g. virtual CPUs:</p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  ...
-  &lt;vcpu max='255'/&gt;
-  ...
-&lt;/domainCapabilities&gt;
-</pre>
-
-    <dl>
-      <dt>vcpu</dt>
-      <dd>The maximum number of supported virtual CPUs</dd>
-    </dl>
-
-    <h3><a name="elementsOSBIOS">BIOS bootloader</a></h3>
-
-    <p>Sometimes users might want to tweak some BIOS knobs or use
-    UEFI. For cases like that, <a
-    href="formatdomain.html#elementsOSBIOS"><code>os</code></a>
-    element exposes what values can be passed to its children.</p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  ...
-  &lt;os supported='yes'&gt;
-    &lt;loader supported='yes'&gt;
-      &lt;value&gt;/usr/share/OVMF/OVMF_CODE.fd&lt;/value&gt;
-      &lt;enum name='type'&gt;
-        &lt;value&gt;rom&lt;/value&gt;
-        &lt;value&gt;pflash&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='readonly'&gt;
-        &lt;value&gt;yes&lt;/value&gt;
-        &lt;value&gt;no&lt;/value&gt;
-      &lt;/enum&gt;
-    &lt;/loader&gt;
-  &lt;/os&gt;
-  ...
-&lt;domainCapabilities&gt;
-</pre>
-
-    <p>For the <code>loader</code> element, the following can occur:</p>
-
-    <dl>
-      <dt>value</dt>
-      <dd>List of known loader paths. Currently this is only used
-      to advertise known locations of OVMF binaries for qemu. Binaries
-      will only be listed if they actually exist on disk.</dd>
-
-      <dt>type</dt>
-      <dd>Whether loader is a typical BIOS (<code>rom</code>) or
-      an UEFI binary (<code>pflash</code>). This refers to
-      <code>type</code> attribute of the &lt;loader/&gt;
-      element.</dd>
-
-      <dt>readonly</dt>
-      <dd>Options for the <code>readonly</code> attribute of the
-      &lt;loader/&gt; element.</dd>
-    </dl>
-
-    <h3><a name="elementsDevices">Devices</a></h3>
-
-    <p>
-      The final set of XML elements describe the supported devices and their
-      capabilities. All devices occur as children of the main
-      <code>devices</code> element.
-    </p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  ...
-  &lt;devices&gt;
-    &lt;disk supported='yes'&gt;
-      &lt;enum name='diskDevice'&gt;
-        &lt;value&gt;disk&lt;/value&gt;
-        &lt;value&gt;cdrom&lt;/value&gt;
-        &lt;value&gt;floppy&lt;/value&gt;
-        &lt;value&gt;lun&lt;/value&gt;
-      &lt;/enum&gt;
-      ...
-    &lt;/disk&gt;
-    &lt;hostdev supported='no'/&gt;
-  &lt;/devices&gt;
-&lt;/domainCapabilities&gt;
-</pre>
-
-    <p>Reported capabilities are expressed as an enumerated list of available
-    options for each of the element or attribute.  For example, the
-    &lt;disk/&gt; element has an attribute <code>device</code> which can
-    support the values <code>disk</code>, <code>cdrom</code>,
-    <code>floppy</code>, or <code>lun</code>.</p>
-
-    <h4><a name="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
-    <p>Disk capabilities are exposed under <code>disk</code> element. For
-    instance:</p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  ...
-  &lt;devices&gt;
-    &lt;disk supported='yes'&gt;
-      &lt;enum name='diskDevice'&gt;
-        &lt;value&gt;disk&lt;/value&gt;
-        &lt;value&gt;cdrom&lt;/value&gt;
-        &lt;value&gt;floppy&lt;/value&gt;
-        &lt;value&gt;lun&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='bus'&gt;
-        &lt;value&gt;ide&lt;/value&gt;
-        &lt;value&gt;fdc&lt;/value&gt;
-        &lt;value&gt;scsi&lt;/value&gt;
-        &lt;value&gt;virtio&lt;/value&gt;
-        &lt;value&gt;xen&lt;/value&gt;
-        &lt;value&gt;usb&lt;/value&gt;
-        &lt;value&gt;uml&lt;/value&gt;
-        &lt;value&gt;sata&lt;/value&gt;
-        &lt;value&gt;sd&lt;/value&gt;
-      &lt;/enum&gt;
-    &lt;/disk&gt;
-    ...
-  &lt;/devices&gt;
-&lt;/domainCapabilities&gt;
-</pre>
-
-    <dl>
-      <dt>diskDevice</dt>
-      <dd>Options for the <code>device</code> attribute of the &lt;disk/&gt;
-      element.</dd>
-
-      <dt>bus</dt>
-      <dd>Options for the <code>bus</code> attribute of the &lt;target/&gt;
-      element for a &lt;disk/&gt;.</dd>
-    </dl>
-
-    <h4><a name="elementsHostDev">Host device assignment</a></h4>
-    <p>Some host devices can be passed through to a guest (e.g. USB, PCI and
-    SCSI). Well, only if the following is enabled:</p>
-
-<pre>
-&lt;domainCapabilities&gt;
-  ...
-  &lt;devices&gt;
-    &lt;hostdev supported='yes'&gt;
-      &lt;enum name='mode'&gt;
-        &lt;value&gt;subsystem&lt;/value&gt;
-        &lt;value&gt;capabilities&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='startupPolicy'&gt;
-        &lt;value&gt;default&lt;/value&gt;
-        &lt;value&gt;mandatory&lt;/value&gt;
-        &lt;value&gt;requisite&lt;/value&gt;
-        &lt;value&gt;optional&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='subsysType'&gt;
-        &lt;value&gt;usb&lt;/value&gt;
-        &lt;value&gt;pci&lt;/value&gt;
-        &lt;value&gt;scsi&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='capsType'&gt;
-        &lt;value&gt;storage&lt;/value&gt;
-        &lt;value&gt;misc&lt;/value&gt;
-        &lt;value&gt;net&lt;/value&gt;
-      &lt;/enum&gt;
-      &lt;enum name='pciBackend'&gt;
-        &lt;value&gt;default&lt;/value&gt;
-        &lt;value&gt;kvm&lt;/value&gt;
-        &lt;value&gt;vfio&lt;/value&gt;
-        &lt;value&gt;xen&lt;/value&gt;
-      &lt;/enum&gt;
-    &lt;/hostdev&gt;
-  &lt;/devices&gt;
-&lt;/domainCapabilities&gt;
-</pre>
-
-    <dl>
-      <dt>mode</dt>
-      <dd>Options for the <code>mode</code> attribute of the &lt;hostdev/&gt;
-      element.</dd>
-
-      <dt>startupPolicy</dt>
-      <dd>Options for the <code>startupPolicy</code> attribute of the
-      &lt;hostdev/&gt; element.</dd>
-
-      <dt>subsysType</dt>
-      <dd>Options for the <code>type</code> attribute of the &lt;hostdev/&gt;
-      element in case of <code>mode="subsystem"</code>.</dd>
-
-      <dt>capsType</dt>
-      <dd>Options for the <code>type</code> attribute of the &lt;hostdev/&gt;
-      element in case of <code>mode="capabilities"</code>.</dd>
-
-      <dt>pciBackend</dt>
-      <dd>Options for the <code>name</code> attribute of the &lt;driver/&gt;
-      element.</dd>
-    </dl>
-  </body>
-</html>
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Network XML format</h1>

@@ -35,7 +33,7 @@
    </p>

    <pre>
-      &lt;network ipv6='yes' trustGuestRxFilters='no'&gt;
+      &lt;network ipv6='yes'&gt;
        &lt;name&gt;default&lt;/name&gt;
        &lt;uuid&gt;3e3fce45-4f53-4fa7-bb32-11f34168b82b&lt;/uuid&gt;
        ...</pre>
@@ -60,16 +58,6 @@
        to have guest-to-guest communications.  For further information,
        see the example below for the example with no gateway addresses.
        <span class="since">Since 1.0.1</span></dd>
-      <dt><code>trustGuestRxFilters='yes'</code></dt>
-      <dd>The optional parameter <code>trustGuestRxFilters</code> can
-        be used to set that attribute of the same name for each domain
-        interface connected to this network (<span class="since">since
-        1.2.10</span>). See
-        the <a href="formatdomain.html#elementSNICS">Network
-        interfaces</a> section of the domain XML documentation for
-        more details. Note that an explicit setting of this attribute
-        in a portgroup or the individual domain interface will
-        override the setting in the network.</dd>
    </dl>

    <h3><a name="elementsConnect">Connectivity</a></h3>
@@ -81,8 +69,8 @@

    <pre>
        ...
-        &lt;bridge name="virbr0" stp="on" delay="5" macTableManager="libvirt"/&gt;
-        &lt;domain name="example.com" localOnly="no"/&gt;
+        &lt;bridge name="virbr0" stp="on" delay="5"/&gt;
+        &lt;domain name="example.com"/&gt;
        &lt;forward mode="nat" dev="eth0"/&gt;
        ...</pre>

@@ -92,56 +80,18 @@
        defines the name of a bridge device which will be used to construct
        the virtual network. The virtual machines will be connected to this
        bridge device allowing them to talk to each other. The bridge device
-        may also be connected to the LAN. When defining
+        may also be connected to the LAN. It is recommended that bridge
+        device names started with the prefix <code>vir</code>, but the name
+        <code>virbr0</code> is reserved for the "default" virtual
+        network.  This element should always be provided when defining
        a new network with a <code>&lt;forward&gt;</code> mode of
-
        "nat" or "route" (or an isolated network with
-        no <code>&lt;forward&gt;</code> element), libvirt will
-        automatically generate a unique name for the bridge device if
-        none is given, and this name will be permanently stored in the
-        network configuration so that that the same name will be used
-        every time the network is started. For these types of networks
-        (nat, routed, and isolated), a bridge name beginning with the
-        prefix "virbr" is recommended (and that is what is
-        auto-generated), but not enforced.
+        no <code>&lt;forward&gt;</code> element).
        Attribute <code>stp</code> specifies if Spanning Tree Protocol
        is 'on' or 'off' (default is
        'on'). Attribute <code>delay</code> sets the bridge's forward
        delay value in seconds (default is 0).
        <span class="since">Since 0.3.0</span>
-
-        <p>
-          The <code>macTableManager</code> attribute of the bridge
-          element is used to tell libvirt how the bridge's MAC address
-          table (used to determine the correct egress port for packets
-          based on destination MAC address) will be managed. In the
-          default <code>kernel</code> setting, the kernel
-          automatically adds and removes entries, typically using
-          learning, flooding, and promiscuous mode on the bridge's
-          ports in order to determine the proper egress port for
-          packets.  When <code>macTableManager</code> is set
-          to <code>libvirt</code>, libvirt disables kernel management
-          of the MAC table (in the case of the Linux host bridge, this
-          means enabling vlan_filtering on the bridge, and disabling
-          learning and unicast_filter for all bridge ports), and
-          explicitly adds/removes entries to the table according to
-          the MAC addresses in the domain interface configurations.
-          Allowing libvirt to manage the MAC table can improve
-          performance - with a Linux host bridge, for example, turning
-          off learning and unicast_flood on ports has its own
-          performance advantage, and can also lead to an additional
-          boost by permitting the kernel to automatically turn off
-          promiscuous mode on some ports of the bridge (in particular,
-          the port attaching the bridge to the physical
-          network). However, it can also cause some networking setups
-          to stop working (e.g. vlan tagging, multicast,
-          guest-initiated changes to MAC address) and is not supported
-          by older kernels.
-          <span class="since">Since 1.2.11, requires kernel 3.17 or
-          newer</span>
-        </p>
-
-
      </dd>
      <dt><code>domain</code></dt>
      <dd>
@@ -151,16 +101,6 @@
        a <code>&lt;forward&gt;</code> mode of "nat" or "route" (or an
        isolated network with no <code>&lt;forward&gt;</code>
        element). <span class="since">Since 0.4.5</span>
-
-        <p>
-          If the optional <code>localOnly</code> attribute on the
-          <code>domain</code> element is "yes", then DNS requests under
-          this domain will only be resolved by the virtual network's own
-          DNS server - they will not be forwarded to the host's upstream
-          DNS server.  If <code>localOnly</code> is "no", and by
-          default, unresolved requests <b>will</b> be forwarded.
-          <span class="since">Since 1.2.12</span>
-        </p>
      </dd>
      <dt><code>forward</code></dt>
      <dd>Inclusion of the <code>forward</code> element indicates that
@@ -196,41 +136,6 @@
            network, and to/from the host to the guests, are
            unrestricted and not NATed.<span class="since">Since
            0.4.2</span>
-
-            <p><span class="since">Since 1.0.3</span> it is possible to
-            specify a public IPv4 address and port range to be used for
-            the NAT by using the <code>&lt;nat&gt;</code> subelement.
-            Note that all addresses from the range are used, not just those
-            that are in use on the host.
-            The address range is set with the <code>&lt;address&gt;</code>
-            subelements and <code>start</code> and <code>stop</code>
-            attributes:
-            </p>
-            <pre>
-...
-  &lt;forward mode='nat'&gt;
-    &lt;nat&gt;
-      &lt;address start='1.2.3.4' end='1.2.3.10'/&gt;
-    &lt;/nat&gt;
-  &lt;/forward&gt;
-...</pre>
-            <p>
-            A single IPv4 address can be set by setting
-            <code>start</code> and <code>end</code> attributes to
-            the same value.
-            </p>
-            <p>
-            The port range to be used for the <code>&lt;nat&gt;</code> can
-            be set via the subelement <code>&lt;port&gt;</code>:
-            </p>
-            <pre>
-...
-  &lt;forward mode='nat'&gt;
-    &lt;nat&gt;
-      &lt;port start='500' end='1000'/&gt;
-    &lt;/nat&gt;
-  &lt;/forward&gt;
-...</pre>
          </dd>

          <dt><code>route</code></dt>
@@ -338,33 +243,14 @@
            (Single Root I/O Virtualization) virtual function (VF)
            devices can be assigned in this manner; to assign a
            standard single-port PCI or PCIe ethernet card to a guest,
-            use the traditional <code>&lt;hostdev&gt;</code> device
+            use the traditional <code>&lt; hostdev&gt;</code> device
            definition. <span class="since"> Since 0.10.0</span>

-            <p>
-              To force use of a particular type of device assignment,
-              a &lt;forward type='hostdev'&gt; interface can have an
-              optional <code>driver</code> sub-element with
-              a <code>name</code> attribute set to either "vfio" (VFIO
-              is a new method of device assignment that is compatible
-              with UEFI Secure Boot) or "kvm" (the legacy device
-              assignment handled directly by the KVM kernel module)
-              <span class="since">Since 1.0.5 (QEMU and KVM only,
-              requires kernel 3.6 or newer)</span>. When specified,
-              device assignment will fail if the requested method of
-              device assignment isn't available on the host. When not
-              specified, the default is "vfio" on systems where the
-              VFIO driver is available and loaded, and "kvm" on older
-              systems, or those where the VFIO driver hasn't been
-              loaded <span class="since">Since 1.1.3</span> (prior to
-              that the default was always "kvm").
-            </p>
-
            <p>Note that this "intelligent passthrough" of network
            devices is very similar to the functionality of a
-            standard <code>&lt;hostdev&gt;</code> device, the
+            standard <code>&lt; hostdev&gt;</code> device, the
            difference being that this method allows specifying a MAC
-            address, vlan tag, and <code>&lt;virtualport&gt;</code>
+            address, vlan tag, and <code>&lt;virtualport &gt;</code>
            for the passed-through device. If these capabilities are
            not required, if you have a standard single-port PCI,
            PCIe, or USB network card that doesn't support SR-IOV (and
@@ -433,15 +319,14 @@
          <span class="since">since 0.10.0</span> When using forward
          mode 'hostdev', the interface pool is specified with a list
          of <code>&lt;address&gt;</code> elements, each of which has
-          <code>&lt;type&gt;</code> (must always be <code>'pci'</code>),
+          <code>&lt; type&gt;</code> (must always be <code>'pci'</code>,
          <code>&lt;domain&gt;</code>, <code>&lt;bus&gt;</code>,
-          <code>&lt;slot&gt;</code>and <code>&lt;function&gt;</code>
+          <code>&lt;slot&gt;</code>, and <code>&lt;function&gt;</code>
          attributes.
        </p>
        <pre>
 ...
  &lt;forward mode='hostdev' managed='yes'&gt;
-    &lt;driver name='vfio'/&gt;
    &lt;address type='pci' domain='0' bus='4' slot='0' function='1'/&gt;
    &lt;address type='pci' domain='0' bus='4' slot='0' function='2'/&gt;
    &lt;address type='pci' domain='0' bus='4' slot='0' function='3'/&gt;
@@ -476,135 +361,43 @@
 ...</pre>

      <p>
-        The <code>&lt;bandwidth&gt;</code> element allows setting
-        quality of service for a particular network
-        (<span class="since">since 0.9.4</span>). Setting
-        <code>bandwidth</code> for a network is supported only
-        for networks with a <code>&lt;forward&gt;</code> mode
-        of <code>route</code>, <code>nat</code>, or no mode at all
-        (i.e. an "isolated" network). Setting <code>bandwidth</code>
-        is <b>not</b> supported for forward modes
-        of <code>bridge</code>, <code>passthrough</code>, <code>private</code>,
-        or <code>hostdev</code>. Attempts to do this will lead to
-        a failure to define the network or to create a transient network.
-      </p>
-      <p>
-        The <code>&lt;bandwidth&gt;</code> element can only be a
-        subelement of a domain's <code>&lt;interface&gt;</code>, a
-        subelement of a <code>&lt;network&gt;</code>, or a subelement of
-        a <code>&lt;portgroup&gt;</code> in a <code>&lt;network&gt;</code>.
-      </p>
-      <p>
-        As a subelement of a domain's <code>&lt;interface&gt;</code>,
-        the bandwidth only applies to that one interface of the domain.
-        As a subelement of a <code>&lt;network&gt;</code>, the bandwidth
-        is a total aggregate bandwidth to/from all guest interfaces attached
-        to that network, <b>not</b> to each guest interface individually.
-        If a domain's <code>&lt;interface&gt;</code> has
-        <code>&lt;bandwidth&gt;</code> element values higher
-        than the aggregate for the entire network, then the aggregate
-        bandwidth for the <code>&lt;network&gt;</code> takes precedence.
-        This is because the two choke points are independent of each other
-        where the domain's <code>&lt;interface&gt;</code> bandwidth control
-        is applied on the interface's tap device, while the
-        <code>&lt;network&gt;</code> bandwidth control is applied on the
-        interface part of the bridge device created for that network.
-      </p>
-      <p>
-        As a subelement of a
-        <code>&lt;portgroup&gt;</code> in a <code>&lt;network&gt;</code>,
-        if a domain's <code>&lt;interface&gt;</code> has a
-        <code>portgroup</code> attribute in its
-        <code>&lt;source&gt;</code> element <b>and</b> if the
-        <code>&lt;interface&gt;</code>
-        itself has no <code>&lt;bandwidth&gt;</code> element, then the
-        <code>&lt;bandwidth&gt;</code> element of the portgroup will be
-        applied individually to each guest interface defined to be a
-        member of that portgroup. Any <code>&lt;bandwidth&gt;</code>
-        element in the domain's <code>&lt;interface&gt;</code> definition
-        will override the setting in the portgroup
-        (<span class="since">since 1.0.1</span>).
-      </p>
-      <p>
-        Incoming and outgoing traffic can be shaped independently. The
-        <code>bandwidth</code> element can have at most one
-        <code>inbound</code> and at most one <code>outbound</code>
-        child element. Leaving either of these children elements out
-        results in no QoS applied for that traffic direction.  So,
-        when you want to shape only incoming traffic, use
-        <code>inbound</code> only, and vice versa. Each of these
-        elements have one mandatory attribute - <code>average</code> (or
-        <code>floor</code> as described below). The attributes are as follows,
-        where accepted values for each attribute is an integer number.
-      </p>
-        <dl>
-          <dt><code>average</code></dt>
-          <dd>
-          Specifies the desired average bit rate for the interface
-          being shaped (in kilobytes/second).
-          </dd>
-          <dt><code>peak</code></dt>
-          <dd>
-          Optional attribute which specifies the maximum rate at
-          which the bridge can send data (in kilobytes/second).
-          Note the limitation of implementation: this attribute in the
-          <code>outbound</code> element is ignored (as Linux ingress
-          filters don't know it yet).
-          </dd>
-          <dt><code>burst</code></dt>
-          <dd>
-          Optional attribute which specifies the amount of kilobytes that
-          can be transmitted in a single burst at <code>peak</code> speed.
-          </dd>
-          <dt><code>floor</code></dt>
-          <dd>
-          Optional attribute available only for the <code>inbound</code>
-          element. This attribute guarantees minimal throughput for
-          shaped interfaces. This, however, requires that all traffic
-          goes through one point where QoS decisions can take place, hence
-          why this attribute works only for virtual networks for now
-          (that is <code>&lt;interface type='network'/&gt;</code> with a
-          forward type of route, nat, or no forward at all). Moreover, the
-          virtual network the interface is connected to is required to have
-          at least inbound QoS set (<code>average</code> at least). If
-          using the <code>floor</code> attribute users don't need to specify
-          <code>average</code>. However, <code>peak</code> and
-          <code>burst</code> attributes still require <code>average</code>.
-          Currently, the Linux kernel doesn't allow ingress qdiscs to have
-          any classes therefore <code>floor</code> can be applied only
-          on <code>inbound</code> and not <code>outbound</code>.
-          </dd>
-        </dl>
-
-      <p>
-        Attributes <code>average</code>, <code>peak</code>, and
-        <code>burst</code> are available
-        <span class="since">since 0.9.4</span>, while the
-        <code>floor</code> attribute is available
-        <span class="since">since 1.0.1</span>.
+        This part of network XML provides setting quality of service. Incoming
+        and outgoing traffic can be shaped independently. The
+        <code>bandwidth</code> element can have at most one <code>inbound</code>
+        and at most one <code>outbound</code> child elements. Leaving any of these
+        children element out result in no QoS applied on that traffic direction.
+        So, when you want to shape only network's incoming traffic, use
+        <code>inbound</code> only, and vice versa. Each of these elements have one
+        mandatory attribute <code>average</code>. It specifies average bit rate on
+        interface being shaped. Then there are two optional attributes:
+        <code>peak</code>, which specifies maximum rate at which bridge can send
+        data, and <code>burst</code>, amount of bytes that can be burst at
+        <code>peak</code> speed. Accepted values for attributes are integer
+        numbers, The units for <code>average</code> and <code>peak</code> attributes
+        are kilobytes per second, and for the <code>burst</code> just kilobytes.
+        The rate is shared equally within domains connected to the network.
+        Moreover, <code>bandwidth</code> element can be included in
+        <code>portgroup</code> element.
+        <span class="since">Since 0.9.4</span>
      </p>

    <h5><a name="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>

 <pre>
-&lt;network&gt;
-  &lt;name&gt;ovs-net&lt;/name&gt;
-  &lt;forward mode='bridge'/&gt;
-  &lt;bridge name='ovsbr0'/&gt;
-  &lt;virtualport type='openvswitch'&gt;
-    &lt;parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/&gt;
-  &lt;/virtualport&gt;
-  <b>&lt;vlan trunk='yes'&gt;</b>
-    <b>&lt;tag id='42' nativeMode='untagged'/&gt;</b>
-    <b>&lt;tag id='47'/&gt;</b>
-  <b>&lt;/vlan&gt;</b>
-  &lt;portgroup name='dontpanic'&gt;
-    <b>&lt;vlan&gt;</b>
-      <b>&lt;tag id='42'/&gt;</b>
-    <b>&lt;/vlan&gt;</b>
-  &lt;/portgroup&gt;
-&lt;/network&gt;
-</pre>
+  ...
+  &lt;devices&gt;
+    &lt;interface type='bridge'&gt;
+      <b>&lt;vlan trunk='yes'&gt;</b>
+        <b>&lt;tag id='42'/&gt;</b>
+        <b>&lt;tag id='47'/&gt;</b>
+      <b>&lt;/vlan&gt;</b>
+      &lt;source bridge='ovsbr0'/&gt;
+      &lt;virtualport type='openvswitch'&gt;
+        &lt;parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/&gt;
+      &lt;/virtualport&gt;
+    &lt;/interface&gt;
+  &lt;devices&gt;
+  ...</pre>

    <p>
      If (and only if) the network type supports vlan tagging
@@ -625,14 +418,6 @@
      is desired, the optional attribute <code>trunk='yes'</code> can
      be added to the vlan element.
    </p>
-    <p>
-      For network connections using openvswitch it is possible to
-      configure the 'native-tagged' and 'native-untagged' vlan modes
-      <span class="since">Since 1.1.0</span>. This uses the optional
-      <code>nativeMode</code> attribute on the <code>&lt;tag&gt;</code>
-      element: <code>nativeMode</code> may be set to 'tagged' or
-      'untagged'. The id attribute of the element sets the native vlan.
-    </p>
    <p>
      <code>&lt;vlan&gt;</code> elements can also be specified in
      a <code>&lt;portgroup&gt;</code> element, as well as directly in
@@ -666,7 +451,7 @@
      &lt;outbound average='1000' peak='5000' burst='5120'/&gt;
    &lt;/bandwidth&gt;
  &lt;/portgroup&gt;</b>
-  <b>&lt;portgroup name='sales' trustGuestRxFilters='no'&gt;
+  <b>&lt;portgroup name='sales'&gt;
    &lt;virtualport type='802.1Qbh'&gt;
      &lt;parameters profileid='salestest'/&gt;
    &lt;/virtualport&gt;
@@ -686,9 +471,9 @@
      network can have multiple portgroup elements (and one of those
      can optionally be designated as the 'default' portgroup for the
      network), and each portgroup has a name, as well as various
-      attributes and subelements associated with it. The currently supported
+      subelements associated with it. The currently supported
      subelements are <code>&lt;bandwidth&gt;</code>
-      (described <a href="formatnetwork.html#elementQoS">here</a>)
+      (documented <a href="formatdomain.html#elementQoS">here</a>)
      and <code>&lt;virtualport&gt;</code>
      (documented <a href="formatdomain.html#elementsNICSDirect">here</a>).
      If a domain interface definition specifies a portgroup (by
@@ -710,75 +495,6 @@
      considered an error, and will prevent the interface from
      starting.
    </p>
-    <p>
-      portgroups also support the optional
-      parameter <code>trustGuestRxFilters</code> which can be used to
-      set that attribute of the same name for each domain interface
-      using this portgroup (<span class="since">since
-      1.2.10</span>). See
-      the <a href="formatdomain.html#elementSNICS">Network
-      interfaces</a> section of the domain XML documentation for more
-      details. Note that an explicit setting of this attribute in the
-      portgroup overrides the network-wide setting, and an explicit
-      setting in the individual domain interface will override the
-      setting in the portgroup.
-    </p>
-
-    <h5><a name="elementsStaticroute">Static Routes</a></h5>
-    <p>
-      Static route definitions are used to provide routing information
-      to the virtualization host for networks which are not directly
-      reachable from the virtualization host, but *are* reachable from
-      a guest domain that is itself reachable from the
-      host <span class="since">since 1.0.6</span>.
-    </p>
-
-    <p>
-      As shown in <a href="formatnetwork.html#examplesNoGateway">this
-      example</a>, it is possible to define a virtual network
-      interface with no IPv4 or IPv6 addresses.  Such networks are
-      useful to provide host connectivity to networks which are only
-      reachable via a guest.  A guest with connectivity both to the
-      guest-only network and to another network that is directly
-      reachable from the host can act as a gateway between the
-      networks.  A static route added to the "host-visible" network
-      definition provides the routing information so that IP packets
-      can be sent from the virtualization host to guests on the hidden
-      network.
-    </p>
-
-    <p>
-      Here is a fragment of a definition which shows the static
-      route specification as well as the  IPv4 and IPv6 definitions
-      for network addresses which are referred to in the
-      <code>gateway</code> gateway address specifications.  Note
-      that the third static route specification includes the
-      <code>metric</code> attribute specification with a value of 2.
-      This particular route would *not* be preferred if there was
-      another existing rout on the system with the same address and
-      prefix but with a lower value for the metric. If there is a
-      route in the host system configuration that should be overridden
-      by a route in a virtual network whenever the virtual network is
-      running, the configuration for the system-defined route should
-      be modified to have a higher metric, and the route on the
-      virtual network given a lower metric (for example, the default
-      metric of "1").
-    </p>
-
-    <pre>
-      ...
-        &lt;ip address="192.168.122.1" netmask="255.255.255.0"&gt;
-          &lt;dhcp&gt;
-            &lt;range start="192.168.122.128" end="192.168.122.254" /&gt;
-          &lt;/dhcp&gt;
-        &lt;/ip&gt;
-        &lt;route address="192.168.222.0" prefix="24" gateway="192.168.122.2" /&gt;
-        &lt;ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" /&gt;
-        &lt;route family="ipv6" address="2001:db8:ca2:3::" prefix="64" gateway="2001:db8:ca2:2::2"/&gt;
-        &lt;route family="ipv6" address="2001:db9:4:1::" prefix="64" gateway="2001:db8:ca2:2::3" metric='2'&gt;
-        &lt;/route&gt;
-      ...
-    </pre>

    <h3><a name="elementsAddress">Addressing</a></h3>

@@ -797,8 +513,6 @@
        &lt;domain name="example.com"/&gt;
        &lt;dns&gt;
          &lt;txt name="example" value="example value" /&gt;
-          &lt;forwarder addr="8.8.8.8"/&gt;
-          &lt;forwarder addr="8.8.4.4"/&gt;
          &lt;srv service='name' protocol='tcp' domain='test-domain-name' target='.' port='1024' priority='10' weight='10'/&gt;
          &lt;host ip='192.168.122.2'&gt;
            &lt;hostname&gt;myhost&lt;/hostname&gt;
@@ -813,7 +527,6 @@
          &lt;/dhcp&gt;
        &lt;/ip&gt;
        &lt;ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" /&gt;
-        &lt;route family="ipv6" address="2001:db9:ca1:1::" prefix="64" gateway="2001:db8:ca2:2::2" /&gt;
      &lt;/network&gt;</pre>

    <dl>
@@ -831,36 +544,11 @@
        with the idiosyncrasies of the platform where libvirt is
        running. <span class="since">Since 0.8.8</span>
      </dd>
-      <dt><code>dns</code></dt>
-      <dd> The dns element of a network contains configuration
-        information for the virtual network's DNS
-        server <span class="since">Since 0.9.3</span>.
-
-        <p>
-          The dns element
-          can have an optional <code>forwardPlainNames</code>
-          attribute <span class="since">Since 1.1.2</span>.
-          If <code>forwardPlainNames</code> is "no", then DNS resolution
-          requests for names that are not qualified with a domain
-          (i.e. names with no "." character) will not be forwarded to
-          the host's upstream DNS server - they will only be resolved if
-          they are known locally within the virtual network's own DNS
-          server. If <code>forwardPlainNames</code> is "yes",
-          unqualified names <b>will</b> be forwarded to the upstream DNS
-          server if they can't be resolved by the virtual network's own
-          DNS server.
-        </p>
-
-        Currently supported sub-elements of <code>&lt;dns&gt;</code> are:
+      <dt><code>dns</code></dt><dd>
+        The dns element of a network contains configuration information for the
+        virtual network's DNS server. <span class="since">Since 0.9.3</span>
+        Currently supported elements are:
        <dl>
-          <dt><code>forwarder</code></dt>
-          <dd>A <code>dns</code> element can have 0 or
-            more <code>forwarder</code> elements.  Each forwarder
-            element defines an IP address to be used as forwarder in
-            DNS server configuration. The addr attribute is required
-            and defines the IP address of every
-            forwarder. <span class="since">Since 1.1.3</span>
-          </dd>
          <dt><code>txt</code></dt>
          <dd>A <code>dns</code> element can have 0 or more <code>txt</code> elements.
            Each txt element defines a DNS TXT record and has two attributes, both
@@ -1059,13 +747,8 @@
      &lt;/network&gt;</pre>

    <p>
-      Below is another IPv6 variation.  Instead of a dhcp range being
+      Below is another IPv6 varition.  Instead of a dhcp range being
      specified, this example has a couple of IPv6 host definitions.
-      Note that most of the dhcp host definitions use an "id" (client
-      id or DUID) since this has proven to be a more reliable way
-      of specifying the interface and its association with an IPv6
-      address.  The first is a DUID-LLT, the second a DUID-LL, and
-      the third a DUID-UUID.  <span class="since">Since 1.0.3</span>
    </p>

    <pre>
@@ -1081,40 +764,11 @@
        &lt;ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" &gt;
          &lt;dhcp&gt;
            &lt;host name="paul"   ip="2001:db8:ca2:2:3::1" /&gt;
-            &lt;host id="0:1:0:1:18:aa:62:fe:0:16:3e:44:55:66"    ip="2001:db8:ca2:2:3::2" /&gt;
-            &lt;host id="0:3:0:1:0:16:3e:11:22:33" name="ralph"  ip="2001:db8:ca2:2:3::3" /&gt;
-            &lt;host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" name="badbob" ip="2001:db8:ca2:2:3::4" /&gt;
+            &lt;host name="bob"    ip="2001:db8:ca2:2:3::2" /&gt;
          &lt;/dhcp&gt;
        &lt;/ip&gt;
      &lt;/network&gt;</pre>

-    <p>
-      Below is yet another IPv6 variation.  This variation has only
-      IPv6 defined with DHCPv6 on the primary IPv6 network.  A static
-      link if defined for a second IPv6 network which will not be
-      directly visible on the bridge interface but there will be a
-      static route defined for this network via the specified
-      gateway. Note that the gateway address must be directly
-      reachable via (on the same subnet as) one of the &lt;ip&gt;
-      addresses defined for this &lt;network&gt;.
-      <span class="since">Since 1.0.6</span>
-    </p>
-
-    <pre>
-      &lt;network&gt;
-        &lt;name&gt;net7&lt;/name&gt;
-        &lt;bridge name="virbr7" /&gt;
-        &lt;forward mode="route"/&gt;
-        &lt;ip family="ipv6" address="2001:db8:ca2:7::1" prefix="64" &gt;
-          &lt;dhcp&gt;
-            &lt;range start="2001:db8:ca2:7::100" end="2001:db8:ca2::1ff" /&gt;
-            &lt;host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" name="lucas" ip="2001:db8:ca2:2:3::4" /&gt;
-          &lt;/dhcp&gt;
-        &lt;/ip&gt;
-        &lt;route family="ipv6" address="2001:db8:ca2:8::" prefix="64" gateway="2001:db8:ca2:7::4" &gt;
-        &lt;/route&gt;
-      &lt;/network&gt;</pre>
-
    <h3><a name="examplesPrivate">Isolated network config</a></h3>

    <p>
@@ -1141,11 +795,6 @@

    <p>
      This variation of an isolated network defines only IPv6.
-      Note that most of the dhcp host definitions use an "id" (client
-      id or DUID) since this has proven to be a more reliable way
-      of specifying the interface and its association with an IPv6
-      address.  The first is a DUID-LLT, the second a DUID-LL, and
-      the third a DUID-UUID.  <span class="since">Since 1.0.3</span>
    </p>

    <pre>
@@ -1155,9 +804,7 @@
        &lt;ip family="ipv6" address="2001:db8:ca2:6::1" prefix="64" &gt;
          &lt;dhcp&gt;
            &lt;host name="peter"   ip="2001:db8:ca2:6:6::1" /&gt;
-            &lt;host id="0:1:0:1:18:aa:62:fe:0:16:3e:44:55:66" ip="2001:db8:ca2:6:6::2" /&gt;
-            &lt;host id="0:3:0:1:0:16:3e:11:22:33" name="dariusz" ip="2001:db8:ca2:6:6::3" /&gt;
-            &lt;host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" name="anita" ip="2001:db8:ca2:6:6::4" /&gt;
+            &lt;host name="dariusz" ip="2001:db8:ca2:6:6::2" /&gt;
          &lt;/dhcp&gt;
        &lt;/ip&gt;
      &lt;/network&gt;</pre>
--- a/docs/formatnode.html.in
+++ b/docs/formatnode.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Node devices XML format</h1>

@@ -13,7 +11,7 @@
      prefix <code>virNodeDevice</code>, which deal with management of
      host devices that can be handed to guests via passthrough as
      &lt;hostdev&gt; elements
-      in <a href="formatdomain.html#elementsHostDev">the domain XML</a>.
+      in <a href="formatdomain.html#elementsUSB">the domain XML</a>.
      These devices are represented as a hierarchy, where a device on
      a bus has a parent of the bus controller device; the root of the
      hierarchy is the node named "computer".
@@ -80,58 +78,6 @@
              <dd>Vendor details from the device ROM, including an
                attribute <code>id</code> with the hexadecimal vendor
                id, and an optional text name of that vendor.</dd>
-              <dt><code>iommuGroup</code></dt>
-              <dd>
-                This optional element describes the "IOMMU group" this
-                device belongs to. If the element exists, it has a
-                mandatory <code>number</code> attribute which tells
-                the group number used for management of the group (all
-                devices in group "n" will be found in
-                "/sys/kernel/iommu_groups/n"). It will also have a
-                list of <code>address</code> subelements, each
-                containing the PCI address of a device in the same
-                group. The toplevel device will itself be included in
-                this list.
-              </dd>
-              <dt><code>capability</code></dt>
-              <dd>
-                This optional element can occur multiple times. If it
-                exists, it has a mandatory <code>type</code> attribute
-                which will be set to
-                either <code>physical_function</code>
-                or <code>virtual_functions</code>. If the type
-                is <code>physical_function</code>, there will be a
-                single <code>address</code> subelement which contains
-                the PCI address of the SRIOV Physical Function (PF)
-                that is the parent of this device (and this device is,
-                by implication, an SRIOV Virtual Function (VF)). If
-                the type is <code>virtual_functions</code>, then this
-                device is an SRIOV PF, and the capability element will
-                have a list of <code>address</code> subelements, one
-                for each VF on this PF.
-              </dd>
-              <dt><code>numa</code></dt>
-              <dd>
-                This optional element contains information on the PCI device
-                with respect to NUMA. For example, the optional
-                <code>node</code> attribute tells which NUMA node is the PCI
-                device associated with.
-              </dd>
-              <dt><code>pci-express</code></dt>
-              <dd>
-              This optional element contains information on PCI Express part of
-              the device. For example, it can contain a child element
-              <code>link</code> which addresses the PCI Express device's link.
-              While a device has its own capabilities
-              (<code>validity='cap'</code>), the actual run time capabilities
-              are negotiated on the device initialization
-              (<code>validity='sta'</code>). The <code>link</code> element then
-              contains three attributes: <code>port</code> which says in which
-              port is the device plugged in, <code>speed</code> (in
-              GigaTransfers per second) and <code>width</code> for the number
-              of lanes used. Since the port can't be negotiated, it's not
-              exposed in <code>./pci-express/link/[@validity='sta']</code>.
-              </dd>
            </dl>
          </dd>
          <dt><code>usb_device</code></dt>
@@ -158,11 +104,11 @@
            <dl>
              <dt><code>number</code></dt>
              <dd>The device number.</dd>
-              <dt><code>class</code></dt>
+              <dt><code>number</code></dt>
              <dd>The device class.</dd>
-              <dt><code>subclass</code></dt>
+              <dt><code>number</code></dt>
              <dd>The device subclass.</dd>
-              <dt><code>protocol</code></dt>
+              <dt><code>number</code></dt>
              <dd>The device protocol.</dd>
              <dt><code>description</code></dt>
              <dd>If present, a description of the device.</dd>
@@ -176,33 +122,6 @@
              <dd>The interface name tied to this device.</dd>
              <dt><code>address</code></dt>
              <dd>If present, the MAC address of the device.</dd>
-              <dt><code>link</code></dt>
-              <dd>Optional to reflect the status of the link. It has
-                two optional attributes: <code>speed</code> in Mbits per
-                second and <code>state</code> to tell the state of the
-                link. So far, the whole element is just for output,
-                not setting.
-              </dd>
-              <dt><code>feature</code></dt>
-              <dd>If present, the hw offloads supported by this network
-                interface. Possible features are:
-                <dl>
-                    <dt><code>rx</code></dt><dd>rx-checksumming</dd>
-                    <dt><code>tx</code></dt><dd>tx-checksumming</dd>
-                    <dt><code>sg</code></dt><dd>scatter-gather</dd>
-                    <dt><code>tso</code></dt><dd>tcp-segmentation-offload</dd>
-                    <dt><code>ufo</code></dt><dd>udp-fragmentation-offload</dd>
-                    <dt><code>gso</code></dt><dd>generic-segmentation-offload</dd>
-                    <dt><code>gro</code></dt><dd>generic-receive-offload</dd>
-                    <dt><code>lro</code></dt><dd>large-receive-offload</dd>
-                    <dt><code>rxvlan</code></dt><dd>rx-vlan-offload</dd>
-                    <dt><code>txvlan</code></dt><dd>tx-vlan-offload</dd>
-                    <dt><code>ntuple</code></dt><dd>ntuple-filters</dd>
-                    <dt><code>rxhash</code></dt><dd>receive-hashing</dd>
-                    <dt><code>rdma</code></dt><dd>remote-direct-memory-access</dd>
-                    <dt><code>txudptnl</code></dt><dd>tx-udp-tunnel-segmentation</dd>
-                </dl>
-              </dd>
              <dt><code>capability</code></dt>
              <dd>A network protocol exposed by the device, where the
                attribute <code>type</code> can be "80203" for IEEE
@@ -215,26 +134,11 @@
            <dl>
              <dt><code>host</code></dt>
              <dd>The SCSI host number.</dd>
-              <dt><code>unique_id</code></dt>
-              <dd>On input, this optionally provides the value from the
-                'unique_id' file found in the scsi_host's directory. To
-                view the values of all 'unique_id' files, use <code>find -H
-                /sys/class/scsi_host/host{0..9}/unique_id |
-                xargs grep '[0-9]'</code>. On output, if the unique_id
-                file exists, the value from the file will be displayed.
-                This can be used in order to help uniquely identify the
-                scsi_host adapter in a <a href="formatstorage.html">
-                Storage Pool</a>. <span class="since">Since 1.2.7</span>
-              </dd>
              <dt><code>capability</code></dt>
              <dd>Current capabilities include "vports_ops" (indicates
-                vport operations are supported) and "fc_host". "vport_ops"
-                could contain two optional sub-elements: <code>vports</code>,
-                and <code>max_vports</code>. <code>vports</code> shows the
-                number of vport in use. <code>max_vports</code> shows the
-                maximum vports the HBA supports. "fc_host" implies following
-                sub-elements: <code>wwnn</code>, <code>wwpn</code>, and
-                <code>fabric_wwn</code>.
+                vport operations are supported) and "fc_host", the later
+                implies following sub-elements: <code>wwnn</code>,
+                <code>wwpn</code>, <code>fabric_wwn</code>.
              </dd>
            </dl>
          </dd>
@@ -322,42 +226,7 @@
    &lt;address&gt;00:27:13:6a:fe:00&lt;/address&gt;
    &lt;capability type='80203'/&gt;
  &lt;/capability&gt;
-&lt;/device&gt;
-
-&lt;device&gt;
-  &lt;name&gt;pci_0000_02_00_0&lt;/name&gt;
-  &lt;path&gt;/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0&lt;/path&gt;
-  &lt;parent&gt;pci_0000_00_04_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;2&lt;/bus&gt;
-    &lt;slot&gt;0&lt;/slot&gt;
-    &lt;function&gt;0&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;capability type='virt_functions'&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x0'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x2'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x4'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x6'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x0'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x2'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x4'/&gt;
-    &lt;/capability&gt;
-    &lt;iommuGroup number='12'&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/&gt;
-      &lt;address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/&gt;
-    &lt;/iommuGroup&gt;
-    &lt;pci-express&gt;
-      &lt;link validity='cap' port='1' speed='2.5' width='1'/&gt;
-      &lt;link validity='sta' speed='2.5' width='1'/&gt;
-    &lt;/pci-express&gt;
-  &lt;/capability&gt;
-&lt;/device&gt;
-    </pre>
+&lt;/device&gt;</pre>

  </body>
 </html>
--- a/docs/formatnwfilter.html.in
+++ b/docs/formatnwfilter.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Network Filters</h1>

@@ -115,7 +113,7 @@
    <p>
      Filtering rules are organized in filter chains. These chains can be
      thought of as having a tree structure with packet
-      filtering rules as entries in individual chains (branches). <br/>
+      filtering rules as entries in individual chains (branches). <br>
      Packets start their filter evaluation in the <code>root</code> chain
      and can then continue their evaluation in other chains, return from
      those chains back into the <code>root</code> chain or be
@@ -229,7 +227,7 @@
    <p>
      A chain with a lower priority value is accessed before one with a
      higher value.
-      <br/>
+      <br><br>
      <span class="since">Since 0.9.8</span> the above listed chains
      can be assigned custom priorities by writing a value in the
      range [-1000, 1000] into the priority (XML) attribute in the filter
@@ -372,7 +370,7 @@
    <p>
      Further, the notation of $VARIABLE is short-hand for $VARIABLE[@0]. The
      former notation always assumes the iterator with Id '0'.
-    </p>
+    <p>

    <h3><a name="nwfelemsRulesAdvIPAddrDetection">Automatic IP address detection</a></h3>
    <p>
@@ -396,7 +394,7 @@
       When a VM is migrated to another host or resumed after a suspend operation,
       the first packet sent by the VM will again determine the IP address it can
       use on a particular interface.
-       <br/>
+       <br/><br>
       A value of <code>dhcp</code> specifies that libvirt should only honor DHCP
       server-assigned addresses with valid leases. This method supports the detection
       and usage of multiple IP address per interface.
@@ -569,7 +567,7 @@
        (matching the rule passes this filter, but returns control to
        the calling filter for further
        analysis) <span class="since">(since 0.9.7)</span>,
-        or <code>continue</code> (matching the rule goes on to the next
+        or <code>continue<code> (matching the rule goes on to the next
        rule for further analysis) <span class="since">(since
        0.9.7)</span>.
     </li>
@@ -587,7 +585,7 @@
        <span class="since">Since 0.9.8</span> this has been extended to cover
        the range of -1000 to 1000. If this attribute is not
        provided, priority 500 will automatically be assigned.
-        <br/>
+        <br>
        Note that filtering rules in the <code>root</code> chain are sorted
        with filters connected to the <code>root</code> chain following
        their priorities. This allows to interleave filtering rules with
@@ -765,7 +763,7 @@
         <td>Mask applied to MAC address of destination</td>
       </tr>
       <tr>
-         <td>vlanid</td>
+         <td>vlan-id</td>
         <td>UINT16 (0x0-0xfff, 0 - 4095)</td>
         <td>VLAN ID</td>
       </tr>
@@ -989,21 +987,11 @@
         <td>IP_ADDR</td>
         <td>Source IP address in ARP/RARP packet</td>
       </tr>
-       <tr>
-         <td>arpsrcipmask <span class="since">(Since 1.2.3)</span></td>
-         <td>IP_MASK</td>
-         <td>Source IP mask</td>
-       </tr>
       <tr>
         <td>arpdstipaddr</td>
         <td>IP_ADDR</td>
         <td>Destination IP address in ARP/RARP packet</td>
       </tr>
-       <tr>
-         <td>arpdstipmask <span class="since">(Since 1.2.3)</span></td>
-         <td>IP_MASK</td>
-         <td>Destination IP mask</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1100,11 +1088,6 @@
         <td>UINT16</td>
         <td>End of range of valid destination ports; requires <code>protocol</code></td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1196,26 +1179,6 @@
         <td>UINT16</td>
         <td>End of range of valid destination ports; requires <code>protocol</code></td>
       </tr>
-       <tr>
-         <td>type<span class="since">(Since 1.2.12)</span></td>
-         <td>UINT8</td>
-         <td>ICMPv6 type; requires <code>protocol</code> to be set to <code>icmpv6</code></td>
-       </tr>
-       <tr>
-         <td>typeend<span class="since">(Since 1.2.12)</span></td>
-         <td>UINT8</td>
-         <td>ICMPv6 type end of range; requires <code>protocol</code> to be set to <code>icmpv6</code></td>
-       </tr>
-       <tr>
-         <td>code<span class="since">(Since 1.2.12)</span></td>
-         <td>UINT8</td>
-         <td>ICMPv6 code; requires <code>protocol</code> to be set to <code>icmpv6</code></td>
-       </tr>
-       <tr>
-         <td>code<span class="since">(Since 1.2.12)</span></td>
-         <td>UINT8</td>
-         <td>ICMPv6 code end of range; requires <code>protocol</code> to be set to <code>icmpv6</code></td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1308,11 +1271,6 @@
         <td>UINT16</td>
         <td>End of range of valid destination ports</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1428,11 +1386,6 @@
         <td>UINT16</td>
         <td>ICMP code</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1532,11 +1485,6 @@
         <td>IP_ADDR</td>
         <td>End of range of destination IP address</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1643,11 +1591,6 @@
         <td>UINT16</td>
         <td>End of range of valid destination ports</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1749,11 +1692,6 @@
         <td>UINT16</td>
         <td>ICMPv6 code</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1838,11 +1776,6 @@
         <td>IPV6_ADDR</td>
         <td>End of range of destination IP address</td>
       </tr>
-       <tr>
-         <td>dscp</td>
-         <td>UINT8 (0x0-0x3f, 0 - 63)</td>
-         <td>Differentiated Services Code Point</td>
-       </tr>
       <tr>
         <td>comment <span class="since">(Since 0.8.5)</span></td>
         <td>STRING</td>
@@ -1892,7 +1825,7 @@
     initiate a connection from TCP port 80 back towards the VM.
     By default the connection state match that enables connection tracking
     and then enforcement of directionality of traffic is turned on. <br/>
-     The following shows an example XML fragment where this feature has been
+     The following shows an example XML fragement where this feature has been
     turned off for incoming connections to TCP port 12345.
    </p>
 <pre>
@@ -2144,9 +2077,9 @@
     To enable traffic for TCP ports 22 and 80 we will add 2 rules to
     enable this type of traffic. To allow the VM to send ping traffic
     we will add a rule for ICMP traffic. For simplicity reasons
-     we allow general ICMP traffic to be initiated from the VM, not
+     we allow general ICMP traffic to be initated from the VM, not
     just ICMP echo request and response messages. To then
-     disallow all other traffic to reach or be initiated by the
+     disallow all other traffic to reach or be initated by the
     VM we will then need to add a rule that drops all other traffic.
     Assuming our VM is called <i>test</i> and
     the interface we want to associate our filter with is called <i>eth0</i>,
@@ -2420,7 +2353,7 @@
      on the source system are equivalent to those on the target system
      and vice versa.
      <br/><br/>
-      Migration must occur between libvirt installations of version
+      Migration must occur between libvirt insallations of version
      0.8.1 or later in order not to lose the network traffic filters
      associated with an interface.
     </p>
--- a/docs/formatsecret.html.in
+++ b/docs/formatsecret.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Secret XML format</h1>

@@ -41,205 +39,41 @@
      <dd>
        Specifies what this secret is used for.  A mandatory
        <code>type</code> attribute specifies the usage category, currently
-        only <code>volume</code>, <code>ceph</code> and <code>iscsi</code>
-        are defined. Specific usage categories are described below.
+        only <code>volume</code> and <code>ceph</code> are defined.
+        Specific usage categories are described below.
      </dd>
    </dl>

-    <h3><a name="VolumeUsageType">Usage type "volume"</a></h3>
+    <h3>Usage type "volume"</h3>

    <p>
      This secret is associated with a volume, and it is safe to delete the
      secret after the volume is deleted.  The <code>&lt;usage
      type='volume'&gt;</code> element must contain a
      single <code>volume</code> element that specifies the key of the volume
-      this secret is associated with. For example, create a volume-secret.xml
-      file as follows:
+      this secret is associated with.
    </p>

-    <pre>
-      &lt;secret ephemeral='no' private='yes'&gt;
-         &lt;description&gt;Super secret name of my first puppy&lt;/description&gt;
-         &lt;uuid&gt;0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f&lt;/uuid&gt;
-         &lt;usage type='volume'&gt;
-            &lt;volume&gt;/var/lib/libvirt/images/puppyname.img&lt;/volume&gt;
-         &lt;/usage&gt;
-      &lt;/secret&gt;
-    </pre>
+    <h3>Usage type "ceph"</h3>

-    <p>
-      Define the secret and set the pass phrase as follows:
-    </p>
-    <pre>
-      # virsh secret-define volume-secret.xml
-      Secret 0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f created
-      #
-      # MYSECRET=`printf %s "open sesame" | base64`
-      # virsh secret-set-value 0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f $MYSECRET
-      Secret value set
-      #
-    </pre>
-
-    <p>
-      The volume type secret can then be used in the XML for a storage volume
-      <a href="formatstorageencryption.html">encryption</a> as follows:
-    </p>
-    <pre>
-      &lt;encryption format='qcow'&gt;
-        &lt;secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f'/&gt;
-      &lt;/encryption&gt;
-    </pre>
-
-    <h3><a name="CephUsageType">Usage type "ceph"</a></h3>
    <p>
      This secret is associated with a Ceph RBD (rados block device).
      The <code>&lt;usage type='ceph'&gt;</code> element must contain
      a single <code>name</code> element that specifies a usage name
      for the secret.  The Ceph secret can then be used by UUID or by
      this usage name via the <code>&lt;auth&gt;</code> element of
-      a <a href="formatdomain.html#elementsDisks">disk device</a> or
-      a <a href="formatstorage.html">storage pool (rbd)</a>.
-      <span class="since">Since 0.9.7</span>. The following is an example
-      of the steps to be taken.  First create a ceph-secret.xml file:
+      a <a href="domain.html#elementsDisks">disk
+      device</a>. <span class="since">Since 0.9.7</span>.
    </p>

+    <h2><a name="example">Example</a></h2>
+
    <pre>
      &lt;secret ephemeral='no' private='yes'&gt;
-         &lt;description&gt;CEPH passphrase example&lt;/description&gt;
-         &lt;usage type='ceph'&gt;
-            &lt;name&gt;ceph_example&lt;/name&gt;
+         &lt;description&gt;LUKS passphrase for the main hard drive of our mail server&lt;/description&gt;
+         &lt;usage type='volume'&gt;
+            &lt;volume&gt;/var/lib/libvirt/images/mail.img&lt;/volume&gt;
         &lt;/usage&gt;
-      &lt;/secret&gt;
-    </pre>
-
-    <p>
-      Next, use <code>virsh secret-define ceph-secret.xml</code> to define
-      the secret and <code>virsh secret-set-value</code> using the generated
-      UUID value and a base64 generated secret value in order to define the
-      chosen secret pass phrase.
-    </p>
-    <pre>
-      # virsh secret-define ceph-secret.xml
-      Secret 1b40a534-8301-45d5-b1aa-11894ebb1735 created
-      #
-      # virsh secret-list
-      UUID                                 Usage
-      -----------------------------------------------------------
-      1b40a534-8301-45d5-b1aa-11894ebb1735 cephx ceph_example
-      #
-      # CEPHPHRASE=`printf %s "pass phrase" | base64`
-      # virsh secret-set-value 1b40a534-8301-45d5-b1aa-11894ebb1735 $CEPHPHRASE
-      Secret value set
-
-      #
-    </pre>
-
-    <p>
-      The ceph secret can then be used by UUID or by the
-      usage name via the <code>&lt;auth&gt;</code> element in a domain's
-      <a href="formatdomain.html#elementsDisks"><code>&lt;disk&gt;</code></a>
-      element as follows:
-    </p>
-    <pre>
-      &lt;auth username='myname'&gt;
-        &lt;secret type='ceph' usage='ceph_example'/&gt;
-      &lt;/auth&gt;
-    </pre>
-
-    <p>
-      As well as the <code>&lt;auth&gt;</code> element in a
-      <a href="formatstorage.html">storage pool (rbd)</a>
-      <code>&lt;source&gt;</code> element as follows:
-    </p>
-    <pre>
-      &lt;auth type='ceph' username='myname'&gt;
-        &lt;secret usage='ceph_example'/&gt;
-      &lt;/auth&gt;
-    </pre>
-
-    <h3><a name="iSCSIUsageType">Usage type "iscsi"</a></h3>
-
-    <p>
-      This secret is associated with an iSCSI target for CHAP authentication.
-      The <code>&lt;usage type='iscsi'&gt;</code> element must contain
-      a single <code>target</code> element that specifies a usage name
-      for the secret. The iSCSI secret can then be used by UUID or by
-      this usage name via the <code>&lt;auth&gt;</code> element of
-      a <a href="formatdomain.html#elementsDisks">disk device</a> or
-      a <a href="formatstorage.html">storage pool (iscsi)</a>.
-      <span class="since">Since 1.0.4</span>. The following is an example
-      of the XML that may be used to generate a secret for iSCSI CHAP
-      authentication. Assume the following sample entry in an iSCSI
-      authentication file:
-    </p>
-      <pre>
-      &lt;target iqn.2013-07.com.example:iscsi-pool&gt;
-      backing-store /home/tgtd/iscsi-pool/disk1
-      backing-store /home/tgtd/iscsi-pool/disk2
-      incominguser myname mysecret
-      &lt;/target&gt;
-      </pre>
-    <p>
-      Define an iscsi-secret.xml file to describe the secret. Use the
-      <code>incominguser</code> username used in your iSCSI authentication
-      configuration file as the value for the <code>username</code> attribute.
-      The <code>description</code> attribute should contain configuration
-      specific data. The <code>target</code> name may be any name of your
-      choosing to be used as the <code>usage</code> when used in the pool
-      or disk XML description.
-    </p>
-    <pre>
-      &lt;secret ephemeral='no' private='yes'&gt;
-         &lt;description&gt;Passphrase for the iSCSI example.com server&lt;/description&gt;
-         &lt;usage type='iscsi'&gt;
-            &lt;target&gt;libvirtiscsi&lt;/target&gt;
-         &lt;/usage&gt;
-      &lt;/secret&gt;
-    </pre>
-
-    <p>
-      Next, use <code>virsh secret-define iscsi-secret.xml</code> to define
-      the secret and <code>virsh secret-set-value</code> using the generated
-      UUID value and a base64 generated secret value in order to define the
-      chosen secret pass phrase.  The pass phrase must match the password
-      used in the iSCSI authentication configuration file.
-    </p>
-    <pre>
-      # virsh secret-define secret.xml
-      Secret c4dbe20b-b1a3-4ac1-b6e6-2ac97852ebb6 created
-
-      # virsh secret-list
-      UUID                                 Usage
-      -----------------------------------------------------------
-      c4dbe20b-b1a3-4ac1-b6e6-2ac97852ebb6 iscsi libvirtiscsi
-
-      # MYSECRET=`printf %s "mysecret" | base64`
-      # virsh secret-set-value c4dbe20b-b1a3-4ac1-b6e6-2ac97852ebb6 $MYSECRET
-      Secret value set
-      #
-    </pre>
-
-    <p>
-      The iSCSI secret can then be used by UUID or by the
-      usage name via the <code>&lt;auth&gt;</code> element in a domain's
-      <a href="formatdomain.html#elementsDisks"><code>&lt;disk&gt;</code></a>
-      element as follows:
-    </p>
-    <pre>
-      &lt;auth username='myname'&gt;
-        &lt;secret type='iscsi' usage='libvirtiscsi'/&gt;
-      &lt;/auth&gt;
-    </pre>
-
-    <p>
-      As well as the <code>&lt;auth&gt;</code> element in a
-      <a href="formatstorage.html">storage pool (iscsi)</a>
-      <code>&lt;source&gt;</code> element as follows:
-    </p>
-    <pre>
-      &lt;auth type='chap' username='myname'&gt;
-        &lt;secret usage='libvirtiscsi'/&gt;
-      &lt;/auth&gt;
-    </pre>
+      &lt;/secret&gt;</pre>
  </body>
 </html>
--- a/docs/formatsnapshot.html.in
+++ b/docs/formatsnapshot.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Snapshot XML format</h1>

@@ -148,55 +146,27 @@
            the <a href="formatdomain.html#elementsDisks">disk
            devices</a> specified for the domain at the time of the
            snapshot.  The attribute <code>snapshot</code> is
-            optional, and the possible values are the same as the
-            <code>snapshot</code> attribute for
-             <a href="formatdomain.html#elementsDisks">disk devices</a>
+            optional, and has the same values of the disk device
+            element for a domain
            (<code>no</code>, <code>internal</code>,
            or <code>external</code>).  Some hypervisors like ESX
            require that if specified, the snapshot mode must not
            override any snapshot mode attached to the corresponding
            domain disk, while others like qemu allow this field to
-            override the domain default.
-
-            <dl>
-              <dt><code>source</code></dt>
-              <dd>If the snapshot mode is external (whether specified
-              or inherited), then there is an optional sub-element
-              <code>source</code>, with an attribute <code>file</code>
-              giving the name of the new file.
-              If <code>source</code> is not
-              given and the disk is backed by a local image file (not
-              a block device or remote storage), a file name is
-              generated that consists of the existing file name
-              with anything after the trailing dot replaced by the
-              snapshot name.  Remember that with external
-              snapshots, the original file name becomes the read-only
-              snapshot, and the new file name contains the read-write
-              delta of all disk changes since the snapshot.
-              </dd>
-              <dt><code>driver</code></dt>
-              <dd>An optional sub-element <code>driver</code>,
-              with an attribute <code>type</code> giving the driver type (such
-              as qcow2), of the new file created by the external
-              snapshot of the new file.
-              </dd>
-            </dl>
-
-            <span class="since">Since 1.2.2</span> the <code>disk</code> element
-            supports an optional attribute <code>type</code> if the
-            <code>snapshot</code> attribute is set to <code>external</code>.
-            This attribute specifies the snapshot target storage type and allows
-            to overwrite the default <code>file</code> type. The <code>type</code>
-            attribute along with the format of the <code>source</code>
-            sub-element is identical to the <code>source</code> element used in
-            domain disk definitions. See the
-            <a href="formatdomain.html#elementsDisks">disk devices</a> section
-            documentation for further information.
-
-            Libvirt currently supports the <code>type</code> element in the qemu
-            driver and supported values are <code>file</code>, <code>block</code>
-            and <code>network</code> with a protocol of <code>gluster</code>
-            <span class="since">(since 1.2.2)</span>.
+            override the domain default.  If the snapshot mode is
+            external (whether specified or inherited), then there is
+            an optional sub-element <code>source</code>, with an
+            attribute <code>file</code> giving the name, and an
+            optional sub-element <code>driver</code>, with an
+            attribute <code>type</code> giving the driver type (such
+            as qcow2), of the new file created by the external
+            snapshot of the new file.  If <code>source</code> is not
+            given, a file name is generated that consists of the
+            existing file name with anything after the trailing dot
+            replaced by the snapshot name.  Remember that with external
+            snapshots, the original file name becomes the read-only
+            snapshot, and the new file name contains the read-write
+            delta of all disk changes since the snapshot.
          </dd>
        </dl>
      </dd>
--- a/docs/formatstorage.html.in
+++ b/docs/formatstorage.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Storage pool and volume XML format</h1>

@@ -17,16 +15,10 @@
    <p>
      The top level tag for a storage pool document is 'pool'. It has
      a single attribute <code>type</code>, which is one of <code>dir</code>,
-      <code>fs</code>, <code>netfs</code>, <code>disk</code>,
-      <code>iscsi</code>, <code>logical</code>, <code>scsi</code>
-      (all <span class="since">since 0.4.1</span>), <code>mpath</code>
-      (<span class="since">since 0.7.1</span>), <code>rbd</code>
-      (<span class="since">since 0.9.13</span>), <code>sheepdog</code>
-      (<span class="since">since 0.10.0</span>),
-      <code>gluster</code> (<span class="since">since
-      1.2.0</span>) or <code>zfs</code> (<span class="since">since
-      1.2.8</span>). This corresponds to the
-      storage backend drivers listed further along in this document.
+      <code>fs</code>,<code>netfs</code>,<code>disk</code>,<code>iscsi</code>,
+      <code>logical</code>. This corresponds to the storage backend drivers
+      listed further along in this document.
+      The storage pool XML format is available <span class="since">since 0.4.1</span>
    </p>
    <h3><a name="StoragePoolFirst">General metadata</a></h3>

@@ -70,274 +62,49 @@
    <p>
      A single <code>source</code> element is contained within the top level
      <code>pool</code> element. This tag is used to describe the source of
-      the storage pool. The set of child elements that it will contain
-      depend on the pool type, but come from the following child elements:
+      the storage pool. It can contain the following child elements:
    </p>

    <pre>
        ...
        &lt;source&gt;
          &lt;host name="iscsi.example.com"/&gt;
-          &lt;device path="iqn.2013-06.com.example:iscsi-pool"/&gt;
-          &lt;auth type='chap' username='myname'&gt;
-            &lt;secret usage='mycluster_myname'/&gt;
-          &lt;/auth&gt;
+          &lt;device path="demo-target"/&gt;
          &lt;vendor name="Acme"/&gt;
          &lt;product name="model"/&gt;
        &lt;/source&gt;
        ...</pre>

-    <pre>
-        ...
-        &lt;source&gt;
-          &lt;adapter type='scsi_host' name='scsi_host1'/&gt;
-        &lt;/source&gt;
-        ...</pre>
-
-    <pre>
-        ...
-        &lt;source&gt;
-          &lt;adapter type='scsi_host'&gt;
-            &lt;parentaddr unique_id='1'&gt;
-              &lt;address domain='0x0000' bus='0x00' slot='0x1f' addr='0x2'/&gt;
-            &lt;/parentaddr&gt;
-          &lt;/adapter&gt;
-        &lt;/source&gt;
-        ...</pre>
-
-    <pre>
-        ...
-        &lt;source&gt;
-          &lt;adapter type='fc_host' parent='scsi_host5' wwnn='20000000c9831b4b' wwpn='10000000c9831b4b'/&gt;
-        &lt;/source&gt;
-        ...</pre>
-
    <dl>
      <dt><code>device</code></dt>
-      <dd>Provides the source for pools backed by physical devices
-        (pool types <code>fs</code>, <code>logical</code>, <code>disk</code>,
-        <code>iscsi</code>, <code>zfs</code>).
+      <dd>Provides the source for pools backed by physical devices.
        May be repeated multiple times depending on backend driver. Contains
-        a single attribute <code>path</code> which is either the fully
-        qualified path to the block device node or for <code>iscsi</code>
-        the iSCSI Qualified Name (IQN).
-        <span class="since">Since 0.4.1</span></dd>
-      <dt><code>dir</code></dt>
-      <dd>Provides the source for pools backed by directories (pool
-        types <code>dir</code>, <code>netfs</code>, <code>gluster</code>),
-        or optionally to select a subdirectory
-        within a pool that resembles a filesystem (pool
-        type <code>gluster</code>). May
+        a single attribute <code>path</code> which is the fully qualified
+        path to the block device node. <span class="since">Since 0.4.1</span></dd>
+      <dt><code>directory</code></dt>
+      <dd>Provides the source for pools backed by directories. May
        only occur once. Contains a single attribute <code>path</code>
-        which is the fully qualified path to the backing directory or
-        for a <code>netfs</code> pool type using <code>format</code>
-        type "cifs", the path to the Samba share without the leading slash.
+        which is the fully qualified path to the block device node.
        <span class="since">Since 0.4.1</span></dd>
      <dt><code>adapter</code></dt>
-      <dd>Provides the source for pools backed by SCSI adapters (pool
-        type <code>scsi</code>). May only occur once.
-        <dl>
-          <dt><code>name</code></dt>
-          <dd>The SCSI adapter name (e.g. "scsi_host1", although a name
-            such as "host1" is still supported for backwards compatibility,
-            it is not recommended). The scsi_host name to be used can be
-            determined from the output of a <code>virsh nodedev-list
-            scsi_host</code> command followed by a combination of
-            <code>lspci</code> and <code>virsh nodedev-dumpxml
-            scsi_hostN</code> commands to find the <code>scsi_hostN</code>
-            to be used. <span class="since">Since 0.6.2</span>
-            <p>
-            It is further recommended to utilize the
-            <code>parentaddr</code> element since it's possible to have
-            the path to which the scsi_hostN uses change between system
-            reboots. <span class="since">Since 1.2.7</span>
-            </p>
-          </dd>
-        </dl>
-        <dl>
-          <dt><code>type</code></dt>
-          <dd>Specifies the adapter type. Valid values are "scsi_host" or
-            "fc_host". If omitted and the <code>name</code> attribute is
-            specified, then it defaults to "scsi_host". To keep backwards
-            compatibility, this attribute is optional <b>only</b> for the
-            "scsi_host" adapter, but is mandatory for the "fc_host" adapter.
-            <span class="since">Since 1.0.5</span>
-            A "fc_host" capable scsi_hostN can be determined by using
-            <code>virsh nodedev-list --cap fc_host</code>.
-            <span class="since">Since 1.2.8</span>
-            <p>
-            Note: Regardless of whether a "scsi_host" adapter type is defined
-            using a <code>name</code> or a <code>parentaddr</code>, it
-            should refer to a real scsi_host adapter as found through a
-            <code>virsh nodedev-list scsi_host</code> and <code>virsh
-            nodedev-dumpxml scsi_hostN</code> on one of the scsi_host's
-            displayed. It should not refer to a "fc_host" capable scsi_hostN
-            nor should it refer to the vHBA created for some "fc_host"
-            adapter. For a vHBA the <code>nodedev-dumpxml</code>
-            output parent setting will be the "fc_host" capable scsi_hostN
-            value. Additionally, do not refer to an iSCSI scsi_hostN for the
-            "scsi_host" source. An iSCSI scsi_hostN's
-            <code>nodedev-dumpxml</code> output parent field is generally
-            "computer". This is a libvirt created parent value indicating
-            no parent was defined for the node device.
-            </p>
-            </dd>
-        </dl>
-        <dl>
-          <dt><code>wwnn</code> and <code>wwpn</code></dt>
-          <dd>The "World Wide Node Name" (<code>wwnn</code>) and "World Wide
-            Port Name" (<code>wwpn</code>) are used by the "fc_host" adapter
-            to uniquely identify the device in the Fibre Channel storage fabric
-            (the device can be either a HBA or vHBA). Both wwnn and wwpn should
-            be specified. Use the command 'virsh nodedev-dumpxml' to determine
-            how to set the values for the wwnn/wwpn of a (v)HBA. The wwnn and
-            wwpn have very specific numerical format requirements based on the
-            hypervisor being used, thus care should be taken if you decide to
-            generate your own to follow the standards; otherwise, the pool
-            will fail to start with an opaque error message indicating failure
-            to write to the vport_create file during vport create/delete due
-            to "No such file or directory".
-            <span class="since">Since 1.0.4</span>
-          </dd>
-        </dl>
-        <dl>
-          <dt><code>parent</code></dt>
-          <dd>Used by the "fc_host" adapter type to optionally specify the
-            parent scsi_host device defined in the
-            <a href="formatnode.html">Node Device</a> database as the
-            <a href="http://wiki.libvirt.org/page/NPIV_in_libvirt">NPIV</a>
-            virtual Host Bus Adapter (vHBA). The value provided must be
-            a vport capable scsi_host. The value is not the scsi_host of
-            the vHBA created by 'virsh nodedev-create', rather it is
-            the parent of that vHBA. If the value is not provided, libvirt
-            will determine the parent based either finding the wwnn,wwpn
-            defined for an existing scsi_host or by creating a vHBA. Providing
-            the parent attribute is also useful for the duplicate pool
-            definition checks. This is more important in environments where
-            both the "fc_host" and "scsi_host" source adapter pools are being
-            used in order to ensure a new definition doesn't duplicate using
-            the scsi_hostN of some existing storage pool.
-            <span class="since">Since 1.0.4</span>
-          </dd>
-          <dt><code>managed</code></dt>
-          <dd>An optional attribute to instruct the SCSI storage backend to
-            manage destroying the vHBA when the pool is destroyed. For
-            configurations that do not provide an already created vHBA
-            from a 'virsh nodedev-create', libvirt will set this property
-            to "yes". For configurations that have already created a vHBA
-            via 'virsh nodedev-create' and are using the wwnn/wwpn from
-            that vHBA and optionally the scsi_host parent, setting this
-            attribute to "yes" will allow libvirt to destroy the node device
-            when the pool is destroyed. If this attribute is set to "no" or
-            not defined in the XML, then libvirt will not destroy the vHBA.
-            <span class="since">Since 1.2.11</span>
-          </dd>
-        </dl>
-        <dl>
-          <dt><code>parentaddr</code></dt>
-          <dd>Used by the "scsi_host" adapter type instead of the
-            <code>name</code> attribute to more uniquely identify the
-            SCSI host. Using a combination of the <code>unique_id</code>
-            attribute and the <code>address</code> element to formulate
-            a PCI address, a search will be performed of the
-            <code>/sys/class/scsi_host/hostNN</code> links for a
-            matching PCI address with a matching <code>unique_id</code>
-            value in the <code>/sys/class/scsi_host/hostNN/unique_id</code>
-            file. The value in the "unique_id" file will be unique enough
-            for the specific PCI address. The <code>hostNN</code> will be
-            used by libvirt as the basis to define which SCSI host is to
-            be used for the currently booted system.
-            <span class="since">Since 1.2.7</span>
-            <dl>
-              <dt><code>address</code></dt>
-              <dd>The PCI address of the scsi_host device to be used. Using
-                a PCI address provides consistent naming across system reboots
-                and kernel reloads. The address will have four attributes:
-                <code>domain</code> (a 2-byte hex integer, not currently used
-                by qemu), <code>bus</code> (a hex value between 0 and 0xff,
-                inclusive), <code>slot</code> (a hex value between 0x0 and
-                0x1f, inclusive), and <code>function</code> (a value between
-                0 and 7, inclusive). The PCI address can be determined by
-                listing the <code>/sys/bus/pci/devices</code> and the
-                <code>/sys/class/scsi_host</code> directories in order to
-                find the expected scsi_host device. The address will be
-                provided in a format such as "0000:00:1f:2" which can be
-                used to generate the expected PCI address
-                "domain='0x0000' bus='0x00' slot='0x1f' function='0x0'".
-                Optionally, using the combination of the commands 'virsh
-                nodedev-list scsi_host' and 'virsh nodedev-dumpxml' for a
-                specific list entry and converting the resulting
-                <code>path</code> element as the basis to formulate the
-                correctly formatted PCI address.
-              </dd>
-            </dl>
-            <dl>
-              <dt><code>unique_id</code></dt>
-              <dd>Required <code>parentaddr</code> attribute used to determine
-                which of the scsi_host adapters for the provided PCI address
-                should be used. The value is determine by contents of the
-                <code>unique_id</code> file for the specific scsi_host adapter.
-                For a PCI address of "0000:00:1f:2", the unique identifer files
-                can be found using the command
-                <code>find -H /sys/class/scsi_host/host*/unique_id |
-                xargs grep '[0-9]'</code>. Optionally, the
-                <code>virsh nodedev-dumpxml scsi_hostN</code>' of a
-                specific scsi_hostN list entry will list the
-                <code>unique_id</code> value.
-              </dd>
-            </dl>
-          </dd>
-        </dl>
-      </dd>
+      <dd>Provides the source for pools backed by SCSI adapters. May
+        only occur once. Contains a single attribute <code>name</code>
+        which is the SCSI adapter name (ex. "host1").
+        <span class="since">Since 0.6.2</span></dd>
      <dt><code>host</code></dt>
      <dd>Provides the source for pools backed by storage from a
-        remote server (pool types <code>netfs</code>, <code>iscsi</code>,
-        <code>rbd</code>, <code>sheepdog</code>, <code>gluster</code>). Will be
-        used in combination with a <code>directory</code>
+        remote server. Will be used in combination with a <code>directory</code>
        or <code>device</code> element. Contains an attribute <code>name</code>
        which is the hostname or IP address of the server. May optionally
        contain a <code>port</code> attribute for the protocol specific
-        port number. Duplicate storage pool definition checks may perform
-        a cursory check that the same host name by string comparison in the
-        new pool does not match an existing pool's source host name when
-        combined with the <code>directory</code> or <code>device</code>
-        element. Name resolution of the provided hostname or IP address
-        is left to the storage driver backend interactions with the remote
-        server. See the <a href="storage.html">storage driver page</a> for
-        any restrictions for specific storage backends.
-        <span class="since">Since 0.4.1</span></dd>
-      <dt><code>auth</code></dt>
-      <dd>If present, the <code>auth</code> element provides the
-        authentication credentials needed to access the source by the
-        setting of the <code>type</code> attribute (pool
-        types <code>iscsi</code>, <code>rbd</code>). The <code>type</code>
-        must be either "chap" or "ceph". Use "ceph" for
-        Ceph RBD (Rados Block Device) network sources and use "iscsi" for CHAP
-        (Challenge-Handshake Authentication Protocol) iSCSI
-        targets. Additionally a mandatory attribute
-        <code>username</code> identifies the username to use during
-        authentication as well as a sub-element <code>secret</code> with
-        a mandatory attribute <code>type</code>, to tie back to a
-        <a href="formatsecret.html">libvirt secret object</a> that
-        holds the actual password or other credentials. The domain XML
-        intentionally does not expose the password, only the reference
-        to the object that manages the password.
-        The <code>secret</code> element requires either a <code>uuid</code>
-        attribute with the UUID of the secret object or a <code>usage</code>
-        attribute matching the key that was specified in the
-        secret object.  <span class="since">Since 0.9.7 for "ceph" and
-        1.1.1 for "chap"</span>
-      </dd>
+        port number. <span class="since">Since 0.4.1</span></dd>
      <dt><code>name</code></dt>
      <dd>Provides the source for pools backed by storage from a
-        named element (pool types <code>logical</code>, <code>rbd</code>,
-        <code>sheepdog</code>, <code>gluster</code>).  Contains a
-        string identifier.
+        named element (e.g., a logical volume group name).
+        remote server. Contains a string identifier.
        <span class="since">Since 0.4.5</span></dd>
      <dt><code>format</code></dt>
-      <dd>Provides information about the format of the pool (pool
-        types <code>fs</code>, <code>netfs</code>, <code>disk</code>,
-        <code>logical</code>). This
+      <dd>Provides information about the format of the pool. This
        contains a single attribute <code>type</code> whose value is
        backend specific. This is typically used to indicate filesystem
        type, or network filesystem type, or partition table type, or
@@ -359,11 +126,7 @@

    <p>
      A single <code>target</code> element is contained within the top level
-      <code>pool</code> element for some types of pools (pool
-      types <code>dir</code>, <code>fs</code>, <code>netfs</code>,
-      <code>logical</code>, <code>disk</code>, <code>iscsi</code>,
-      <code>scsi</code>, <code>mpath</code>). This tag is used to
-      describe the mapping of
+      <code>pool</code> element. This tag is used to describe the mapping of
      the storage pool into the host filesystem. It can contain the following
      child elements:
    </p>
@@ -392,36 +155,27 @@
    <dl>
      <dt><code>path</code></dt>
      <dd>Provides the location at which the pool will be mapped into
-        the local filesystem namespace, as an absolute path. For a
-        filesystem/directory based pool it will be a fully qualified name of
-        the directory in which volumes will be created. For device based pools
-        it will be a fully qualified name of the directory in which
+        the local filesystem namespace. For a filesystem/directory based
+        pool it will be the name of the directory in which volumes will
+        be created. For device based pools it will be the name of the directory in which
        devices nodes exist. For the latter <code>/dev/</code> may seem
        like the logical choice, however, devices nodes there are not
        guaranteed stable across reboots, since they are allocated on
        demand. It is preferable to use a stable location such as one
-        of the <code>/dev/disk/by-{path|id|uuid|label}</code> locations.
-        For a Multipath pool (type <code>mpath</code>), the provided
-        value is ignored and the default value of "/dev/mapper" is used.
+        of the <code>/dev/disk/by-{path,id,uuid,label</code> locations.
        <span class="since">Since 0.4.1</span>
      </dd>
      <dt><code>permissions</code></dt>
-      <dd>This is currently only useful for directory or filesystem based
-        pools, which are mapped as a directory into the local filesystem
-        namespace. It provides information about the permissions to use for the
-        final directory when the pool is built. There are 4 child elements.
-        The <code>mode</code> element contains the octal permission set.
-        The <code>mode</code> defaults to 0755 when not provided.
-        The <code>owner</code> element contains the numeric user ID.
-        The <code>group</code> element contains the numeric group ID.
-        If <code>owner</code> or <code>group</code> aren't specified when
-        creating a directory, the values are inherited from the parent
-        directory. The <code>label</code> element contains the MAC (eg SELinux)
-        label string.
+      <dd>Provides information about the default permissions to use
+        when creating volumes. This is currently only useful for directory
+        or filesystem based pools, where the volumes allocated are simple
+        files. For pools where the volumes are device nodes, the hotplug
+        scripts determine permissions. It contains 4 child elements. The
+        <code>mode</code> element contains the octal permission set. The
+        <code>owner</code> element contains the numeric user ID. The <code>group</code>
+        element contains the numeric group ID. The <code>label</code> element
+        contains the MAC (eg SELinux) label string.
        <span class="since">Since 0.4.1</span>
-        For running directory or filesystem based pools, these fields
-        will be filled with the values used by the existing directory.
-        <span class="since">Since 1.2.16</span>
      </dd>
      <dt><code>timestamps</code></dt>
      <dd>Provides timing information about the volume. Up to four
@@ -465,18 +219,14 @@

    <h2><a name="StorageVol">Storage volume XML</a></h2>
    <p>
-      A storage volume will generally be either a file or a device
-      node; <span class="since">since 1.2.0</span>, an optional
-      output-only attribute <code>type</code> lists the actual type
-      (file, block, dir, network, or netdir), which is also available
-      from <code>virStorageVolGetInfo()</code>.  The storage volume
-      XML format is available <span class="since">since 0.4.1</span>
+      A storage volume will be either a file or a device node.
+      The storage volume XML format is available <span class="since">since 0.4.1</span>
    </p>

    <h3><a name="StorageVolFirst">General metadata</a></h3>

    <pre>
-      &lt;volume type='file'&gt;
+      &lt;volume&gt;
        &lt;name&gt;sparse.img&lt;/name&gt;
        &lt;key&gt;/var/lib/xen/images/sparse.img&lt;/key&gt;
        &lt;allocation&gt;0&lt;/allocation&gt;
@@ -486,18 +236,10 @@
    <dl>
      <dt><code>name</code></dt>
      <dd>Providing a name for the volume which is unique to the pool.
-        This is mandatory when defining a volume. For a disk pool, the
-        name must be combination of the <code>source</code> device path
-        device and next partition number to be created. For example, if
-        the <code>source</code> device path is /dev/sdb and there are no
-        partitions on the disk, then the name must be sdb1 with the next
-        name being sdb2 and so on.
-        <span class="since">Since 0.4.1</span></dd>
+        This is mandatory when defining a volume.  <span class="since">Since 0.4.1</span></dd>
      <dt><code>key</code></dt>
-      <dd>Providing an identifier for the volume which identifies a
-          single volume. In some cases it's possible to have two distinct keys
-          identifying a single volume. This field cannot be set when creating
-          a volume: it is always generated.
+      <dd>Providing an identifier for the volume which is globally unique.
+          This cannot be set when creating a volume: it is always generated.
        <span class="since">Since 0.4.1</span></dd>
      <dt><code>allocation</code></dt>
      <dd>Providing the total storage allocation for the volume. This
@@ -508,11 +250,7 @@
        allocated at time of creation. If set to a value smaller than the
        capacity, the pool has the <strong>option</strong> of deciding
        to sparsely allocate a volume. It does not have to honour requests
-        for sparse allocation though. Different types of pools may treat
-        sparse volumes differently. For example, the <code>logical</code>
-        pool will not automatically expand volume's allocation when it
-        gets full; the user is responsible for doing that or configuring
-        dmeventd to do so automatically.<br/>
+        for sparse allocation though.<br/>
        <br/>
        By default this is specified in bytes, but an optional attribute
        <code>unit</code> can be specified to adjust the passed value.
@@ -567,11 +305,6 @@
            &lt;mode&gt;0744&lt;/mode&gt;
            &lt;label&gt;virt_image_t&lt;/label&gt;
          &lt;/permissions&gt;
-          &lt;compat&gt;1.1&lt;/compat&gt;
-          &lt;nocow/&gt;
-          &lt;features&gt;
-            &lt;lazy_refcounts/&gt;
-          &lt;/features&gt;
        &lt;/target&gt;</pre>

    <dl>
@@ -582,59 +315,24 @@
        <span class="since">Since 0.4.1</span></dd>
      <dt><code>format</code></dt>
      <dd>Provides information about the pool specific volume format.
-        For disk pools it will provide the partition table format type, but is
-        not preserved after a pool refresh or libvirtd restart. Use extended
-        in order to create an extended disk extent partition. For filesystem
+        For disk pools it will provide the partition type. For filesystem
        or directory pools it will provide the file format type, eg cow,
        qcow, vmdk, raw. If omitted when creating a volume, the pool's
        default format will be used. The actual format is specified via
-        the <code>type</code> attribute. Consult the
-        <a href="storage.html">storage driver page</a> for the list of valid
-        volume format type values for each specific pool. The
-        <code>format</code> will be ignored on input for pools without a
-        volume format type value and the default pool format will be used.
-        <span class="since">Since 0.4.1</span></dd>
+        the <code>type</code> attribute. Consult the pool-specific docs for
+        the list of valid values. <span class="since">Since 0.4.1</span></dd>
      <dt><code>permissions</code></dt>
-      <dd>Provides information about the permissions to use
+      <dd>Provides information about the default permissions to use
        when creating volumes. This is currently only useful for directory
        or filesystem based pools, where the volumes allocated are simple
        files. For pools where the volumes are device nodes, the hotplug
-        scripts determine permissions. There are 4 child elements.
-        The <code>mode</code> element contains the octal permission set.
-        The <code>mode</code> defaults to 0600 when not provided.
-        The <code>owner</code> element contains the numeric user ID.
-        The <code>group</code> element contains the numeric group ID.
-        If <code>owner</code> or <code>group</code> aren't specified when
-        creating a supported volume, the values are inherited from the parent
-        directory. The <code>label</code> element contains the MAC (eg SELinux)
-        label string.
-        For existing directory or filesystem based volumes, these fields
-        will be filled with the values used by the existing file.
+        scripts determine permissions. It contains 4 child elements. The
+        <code>mode</code> element contains the octal permission set. The
+        <code>owner</code> element contains the numeric user ID. The <code>group</code>
+        element contains the numeric group ID. The <code>label</code> element
+        contains the MAC (eg SELinux) label string.
        <span class="since">Since 0.4.1</span>
      </dd>
-      <dt><code>compat</code></dt>
-      <dd>Specify compatibility level. So far, this is only used for
-        <code>type='qcow2'</code> volumes. Valid values are <code>0.10</code>
-        and <code>1.1</code> so far, specifying QEMU version the images should
-        be compatible with. If the <code>feature</code> element is present,
-        1.1 is used.
-        <span class="since">Since 1.1.0</span> If omitted, 0.10 is used.
-        <span class="since">Since 1.1.2</span>
-      </dd>
-      <dt><code>nocow</code></dt>
-      <dd>Turn off COW of the newly created volume. So far, this is only valid
-        for a file image in btrfs file system. It will improve performance when
-        the file image is used in VM. To create non-raw file images, it
-        requires QEMU version since 2.1. <span class="since">Since 1.2.7</span>
-      </dd>
-      <dt><code>features</code></dt>
-      <dd>Format-specific features. Only used for <code>qcow2</code> now.
-        Valid sub-elements are:
-        <ul>
-          <li><code>&lt;lazy_refcounts/&gt;</code> - allow delayed reference
-          counter updates. <span class="since">Since 1.1.0</span></li>
-        </ul>
-      </dd>
    </dl>

    <h3><a name="StorageVolBacking">Backing store elements</a></h3>
@@ -677,8 +375,11 @@
        <span class="since">Since 0.6.0</span></dd>
      <dt><code>permissions</code></dt>
      <dd>Provides information about the permissions of the backing file.
-          See volume <code>permissions</code> documentation for explanation
-          of individual fields.
+        It contains 4 child elements. The
+        <code>mode</code> element contains the octal permission set. The
+        <code>owner</code> element contains the numeric user ID. The <code>group</code>
+        element contains the numeric group ID. The <code>label</code> element
+        contains the MAC (eg SELinux) label string.
        <span class="since">Since 0.6.0</span>
      </dd>
    </dl>
@@ -707,10 +408,7 @@
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;source&gt;
          &lt;host name="iscsi.example.com"/&gt;
-          &lt;device path="iqn.2013-06.com.example:iscsi-pool"/&gt;
-          &lt;auth type='chap' username='myuser'&gt;
-            &lt;secret usage='libvirtiscsi'/&gt;
-          &lt;/auth&gt;
+          &lt;device path="demo-target"/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/dev/disk/by-path&lt;/path&gt;
--- a/docs/formatstorageencryption.html.in
+++ b/docs/formatstorageencryption.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Storage volume encryption XML format</h1>

@@ -35,7 +33,7 @@
    </p>
    <h3><a name="StorageEncryptionDefault">"default" format</a></h3>
    <p>
-      <code>&lt;encryption format="default"/&gt;</code> can be specified only
+      <code>&lt;encryption type="default"/&gt;</code> can be specified only
      when creating a volume.  If the volume is successfully created, the
      encryption formats, parameters and secrets will be auto-generated by
      libvirt and the attached <code>encryption</code> tag will be updated.
--- a/docs/genaclperms.pl
+++ b/docs/genaclperms.pl
@@ -1,124 +0,0 @@
-#!/usr/bin/perl
-#
-# 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/>.
-#
-
-use strict;
-use warnings;
-
-my @objects = (
-    "CONNECT", "DOMAIN", "INTERFACE",
-    "NETWORK","NODE_DEVICE", "NWFILTER",
-     "SECRET", "STORAGE_POOL", "STORAGE_VOL",
-    );
-
-my %class;
-
-foreach my $object (@objects) {
-    my $class = lc $object;
-
-    $class =~ s/(^\w|_\w)/uc $1/eg;
-    $class =~ s/_//g;
-    $class =~ s/Nwfilter/NWFilter/;
-    $class = "vir" . $class . "Ptr";
-
-    $class{$object} = $class;
-}
-
-my $objects = join ("|", @objects);
-
-my %opts;
-my $in_opts = 0;
-
-my %perms;
-
-while (<>) {
-    if ($in_opts) {
-        if (m,\*/,) {
-            $in_opts = 0;
-        } elsif (/\*\s*\@(\w+):\s*(.*?)\s*$/) {
-            $opts{$1} = $2;
-        }
-    } elsif (m,/\*\*,) {
-        $in_opts = 1;
-    } elsif (/VIR_ACCESS_PERM_($objects)_((?:\w|_)+),/) {
-        my $object = $1;
-        my $perm = lc $2;
-        next if $perm eq "last";
-
-        $perm =~ s/_/-/g;
-
-        $perms{$object} = {} unless exists $perms{$object};
-        $perms{$object}->{$perm} = {
-            desc => $opts{desc},
-            message => $opts{message},
-            anonymous => $opts{anonymous}
-        };
-        %opts = ();
-    }
-}
-
-print <<EOF;
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-EOF
-
-foreach my $object (sort { $a cmp $b } keys %perms) {
-    my $class = $class{$object};
-    my $olink = lc "object_" . $object;
-    print <<EOF;
-<h3><a name="$olink">$class</a></h3>
-<table class="acl">
-  <thead>
-    <tr>
-      <th>Permission</th>
-      <th>Description</th>
-    </tr>
-  </thead>
-  <tbody>
-EOF
-
-    foreach my $perm (sort { $a cmp $b } keys %{$perms{$object}}) {
-        my $description = $perms{$object}->{$perm}->{desc};
-
-        die "missing description for $object.$perm" unless
-            defined $description;
-
-        my $plink = lc "perm_" . $object . "_" . $perm;
-        $plink =~ s/-/_/g;
-
-        print <<EOF;
-    <tr>
-      <td><a name="$plink">$perm</a></td>
-      <td>$description</td>
-    </tr>
-EOF
-
-    }
-
-    print <<EOF;
-  </tbody>
-</table>
-EOF
-}
-
-print <<EOF;
-  </body>
-</html>
-EOF
--- a/docs/generic.css
+++ b/docs/generic.css
@@ -1,9 +1,10 @@
+
 body {
  margin: 0em;
  padding: 0px;
  color: rgb(0,0,0);
  font-family: Verdana, Arial, Helvetica, sans-serif;
-  font-size: smaller;
+  font-size: 80%;
  background: #ffffff;
 }

@@ -63,6 +64,8 @@ h6 {
 dl dt {
  margin-left: 1em;
  margin-right: 2em;
+  font-weight: bold;
+  font-size: larger;
 }

 dl dd {
--- a/docs/goals.html.in
+++ b/docs/goals.html.in
@@ -1,6 +1,5 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<?xml version="1.0"?>
+<html>
  <body>
    <h1>Terminology and goals</h1>
    <p>To avoid ambiguity about the terms used, here are the definitions
--- a/docs/governance.html.in
+++ b/docs/governance.html.in
@@ -1,294 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <body>
-    <h1>Project governance</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      The libvirt project operates as a meritocratic, consensus-based community.
-      Anyone with an interest in the project can join the community, contributing
-      to the ongoing development of the project's work. This pages describes how
-      that participation takes place and how contributors earn merit, and thus
-      influence, within the community.
-    </p>
-
-    <h2><a name="codeofconduct">Code of conduct</a></h2>
-
-    <p>
-      The libvirt project community covers people from a wide variety of
-      countries, backgrounds and positions. This global diversity is a great
-      strength of the project, but can also lead to communication issues,
-      which may in turn cause unhappiness. To maximise happiness of the
-      project community taken as a whole, all members (whether users,
-      contributors or committers) are expected to abide by the project's
-      code of conduct. At a high level the code can be summarized as
-      <em>"be excellent to each other"</em>. Expanding on this:
-    </p>
-
-    <ul>
-      <li><strong>Be respectful:</strong> disagreements between people are to
-        be expected and are usually the sign of healthy debate and engagement.
-        Disagreements can lead to frustration and even anger for some members.
-        Turning to personal insults, intimidation or threatening behaviour does
-        not improve the situation though. Participants should thus take care to
-        ensure all communications / interactions stay professional at all times.</li>
-
-      <li><strong>Be considerate:</strong> remember that the community has members
-        with a diverse background many of whom have English as a second language.
-        What might appear impolite, may simply be a result of a lack of knowledge
-        of the English language. Bear in mind that actions will have an impact
-        on other community members and the project as a whole, so take potential
-        consequences into account before pursuing a course of action.</li>
-
-      <li><strong>Be forgiving:</strong> humans are fallible and as such prone
-        to make mistakes and inexplicably change their positions at times. Don't
-        assume that other members are acting with malicious intent. Be prepared
-        to forgive people who make mistakes and assist each other in learning
-        from them. Playing a blame game doesn't help anyone.</li>
-    </ul>
-
-    <h2><a name="roles">Roles and responsibilities</a></h2>
-
-    <h3><a href="users">Users</a></h3>
-
-    <p>
-      The users are anyone who has a need for the output of the project.
-      There are no rules or requirements to become a user of libvirt. Even
-      if the software does not yet work on their OS platform, a person can
-      be considered a potential future user and welcomed to participate.
-    </p>
-
-    <p>
-      Participation by users is key to ensuring the project moves in the
-      right direction, satisfying their real world needs. Users are
-      encouraged to participate in the broader libvirt community in any
-      number of ways:
-    </p>
-
-    <ul>
-      <li>Evangelism: spread the word about what libvirt is doing, how it
-        helps solve your problems. This can be via blog articles, social
-        media postings, video blogs, user group / conference presentations
-        and any other method of disseminating information</li>
-      <li>Feedback: let the developers know about what does and does not
-        work with the project. Talk to developers on the project's
-        IRC channel and mailing list, or find them at conferences. Tell
-        them what gaps the project has or where they should look for
-        future development</li>
-      <li>Moral support: developers live for recognition of the positive
-        impact their work has on users' lives. Give thanks to the developers
-        when evangelising the project, or when meeting them at user groups,
-        conferences, etc.</li>
-    </ul>
-
-    <p>
-      The above is not an exhaustive list of things users can do to
-      participate in the project. Further ideas and suggestions are
-      welcome. Users are encouraged to take their participation
-      further and become contributors to the project in any of the
-      ways listed in the next section.
-    </p>
-
-    <h3><a name="contributors">Contributors</a></h3>
-
-    <p>
-      The contributors are community members who have some concrete impact
-      to the ongoing development of the project. There are many ways in which
-      members can contribute, with no requirement to be a software engineer.
-      Many users can in fact consider themselves contributors merely by
-      engaging in evangelism for the project.
-    </p>
-
-    <ul>
-      <li>Bug reporting: improve the quality of the project by reporting
-        any problems found either to the project's own bug tracker, or to
-        that of the OS vendor shipping the libvirt code.</li>
-      <li>User help: join the <a href="contact.html">IRC channel or mailing list</a>
-        to assist or advice other users in troubleshooting the problems they face.</li>
-      <li>Feature requests: help set the direction for future work by
-        reporting details of features which are missing to the project's
-        own bug tracker or mailing lists.</li>
-      <li>Graphical design: contribute to the development of the project's
-        websites / wiki brand with improved graphics, styling or layout.</li>
-      <li>Code development: write and submit patches to address bugs or implement
-        new features</li>
-      <li>Architectural design: improve the usefulness of the project
-        by providing feedback on the design of proposed features, to
-        ensure they satisfy the broadest applicable needs and survive
-        the long term</li>
-      <li>Code review: look at patches which are submitted and critique
-        the code to identify bugs, potential design problems or other
-        issues which should be addressed before the code is accepted</li>
-      <li>Documentation: contribute to content on personal blogs, the
-        website, wiki, code comments, or any of the formal documentation
-        efforts.</li>
-      <li>Translation: join the Fedora transifex community to improve the
-        quality of translations needed by the libvirt project.</li>
-      <li>Testing: try proposed patches or release candidates and report
-        whether the build passes and the changes work as expected.</li>
-    </ul>
-
-    <p>
-      The above is not an exhaustive list of things members can do to
-      contribute to the project. Further ideas and suggestions are
-      welcome.
-    </p>
-
-    <p>
-      There are no special requirements to becoming a contributor other
-      than having the interest and ability to provide a contribution. The
-      libvirt project <strong>does not require</strong> any
-      <em>"Contributor License Agreement"</em>
-      to be signed prior to engagement with the community.
-    </p>
-
-    <p>
-      In making a contribution to the project, the community member is
-      implicitly stating that they accept the terms of the license under
-      which the work they are contributing to is distributed. They are
-      also implicitly stating that they have the legal right to make the
-      contribution, if doing so on behalf of a broader organization /
-      company. Most of the project's code is distributed under the GNU
-      Lesser General Public License, version 2 or later. Details of the
-      exact license under which contributions will be presumed to be
-      covered are found in the source repositories, or website in question.
-    </p>
-
-    <h3><a name="committers">Committers</a></h3>
-
-    <p>
-      The committers are the subset of contributors who have direct access
-      to commit code to the project's primary source code repositories, which
-      are currently using the GIT software. The committers are chosen based
-      on the quality of their contributions over a period of time. This includes
-      both the quality of code they submit, as well as the quality of reviews
-      they provide on other contributors' submissions and a demonstration that
-      they understand day-to-day operation of the project and its goals. There
-      is no minimum level of contribution required in order to become a committer,
-      though 2-3 months worth of quality contribution would be a rough guide.
-    </p>
-
-    <p>
-      There are no special requirements to becoming a committer other than to
-      have shown a willingness and ability to contribute to the project over
-      an extended period of time. Proposals for elevating contributors to
-      committers are typically made by existing committers, though contributors
-      are also welcome to make proposals. The decision to approve the elevation
-      of a contributor to a committer is made through "rough consensus" between
-      the existing committers.
-    </p>
-
-    <p>
-      The aim in elevating contributors to committers is to ensure that there
-      is a broad base of experience and expertize across all areas of the
-      project's work. Committers are not required to have knowledge across
-      all areas of the project's work. While an approved committer has the
-      technical ability to commit code to any area of the project, by convention
-      they will only commit to areas they feel themselves to be qualified to
-      evaluate the contribution. If in doubt, committers will defer to the
-      opinion of other committers with greater expertize in an area.
-    </p>
-
-    <p>
-      The committers hold the ultimate control over what contributions are
-      accepted by the project, however, this does not mean they have the
-      right to do whatever they want. Where there is debate and disagreement
-      between contributors, committers are expected to look at the issues with
-      an unbiased point of view and help achieve a "rough consensus". If the
-      committer has a conflict of interest in the discussion, for example due
-      to their position of employment, they are expected to put the needs of
-      the community project first. If they cannot put the community project
-      first, they must declare their conflict of interest, and allow other
-      non-conflicted committers to make any final decision.
-    </p>
-
-    <p>
-      The committers are expected to monitor contributions to areas of the
-      project where they have expertize and ensure that either some form of
-      feedback is provided to the contributor, or to accept their contribution.
-      There is no formal minimum level of approval required to accept a
-      contribution. Positive review by any committer experienced in the area
-      of work is considered to be enough to justify acceptance in normal
-      circumstances. Where one committer explicitly rejects a contribution,
-      however, other committers should not override that rejection without
-      first establishing a "rough consensus" amongst the broader group of
-      committers.
-    </p>
-
-    <p>
-      Being a committer is a privilege, not a right. In exceptional
-      circumstances, the privilege may be removed from an active
-      contributor. Such decisions will be taken based on "rough
-      consensus" amongst other committers. In the event that a committer
-      is no longer able to participate in the project, after some period
-      of inactivity passes, they may be asked to confirm that they wish
-      to retain their role as a committer.
-    </p>
-
-    <h3><a name="secteam">Security team</a></h3>
-
-    <p>
-      The security team consists of a subset of the project committers
-      along with representatives from vendors shipping the project's
-      software. The subset of project committers is chosen to be the
-      minimal size necessary to provide expertise spanning most of
-      the project's work. Further project committers may be requested
-      to engage in resolving specific security issues on a case by
-      case basis. Any vendor who is shipping the project's software
-      may submit a request for one or more of their representatives
-      to join the security team. Such requests must by approved by
-      existing members of the team vouching for the integrity of
-      the nominated person or organization.
-    </p>
-
-    <p>
-      Members of the security team are responsible for triaging and
-      resolving any security issues that are reported to the project.
-      They are expected to abide by the project's documented
-      <a href="securityprocess.html">security process</a>. In particular
-      they must respect any embargo period agreed amongst the team
-      before disclosing a private issue.
-    </p>
-
-    <h2><a name="roughconsensus">Rough consensus</a></h2>
-
-    <p>
-      A core concept for governance of the project described above is
-      that of "rough consensus". To expand on this, it is a process
-      of decision making that involves the following steps
-    </p>
-
-    <ul>
-      <li>Proposal</li>
-      <li>Discussion</li>
-      <li>Vote (exceptional circumstances only)</li>
-      <li>Decision</li>
-    </ul>
-
-    <p>
-      To put this into words, any contributor is welcome to make a proposal
-      for consideration. Any contributor may participate in the discussions
-      around the proposal. The discussion will usually result in agreement
-      between the interested parties, or at least agreement between the
-      committers. Only in the very exceptional circumstance where there
-      is disagreement between committers, would a vote be considered.
-      Even in these exceptional circumstances, it is usually found to be
-      obvious what the majority opinion of the committers is. In the event
-      that even a formal vote is tied, the committers will have to hold
-      ongoing discussions until the stalemate is resolved or the proposal
-      withdrawn.
-    </p>
-
-    <p>
-      The overall goal of the "rough consensus" process is to ensure that
-      decisions can be made within the project, with a minimum level of
-      bureaucracy and process. Implicit in this is that any person who does
-      not explicitly reject to a proposal is assumed to be supportive, or
-      at least agnostic.
-    </p>
-
-
-  </body>
-</html>
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -1,6 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
+<html>
  <body>
    <h1>Contributor guidelines</h1>

@@ -11,24 +9,8 @@
      <li>Discuss any large changes on the mailing list first.  Post patches
        early and listen to feedback.</li>

-      <li>Official upstream repository is kept in git
-        (<code>git://libvirt.org/libvirt.git</code>) and is browsable
-        along with other libvirt-related repositories
-        (e.g. libvirt-python) <a href="http://libvirt.org/git/">online</a>.</li>
-
-      <li>Patches to translations are maintained via
-        the <a href="https://fedora.zanata.org/">zanata project</a>.
-        If you want to fix a translation in a .po file, join the
-        appropriate language team. The libvirt release process
-        automatically pulls the latest version of each translation
-        file from zanata.</li>
-
-      <li><p>Post patches in unified diff format, with git rename
-        detection enabled.  You need a one-time setup of:</p>
-<pre>
-  git config diff.renames true
-</pre>
-        <p>After that, a command similar to this should work:</p>
+      <li><p>Post patches in unified diff format.  A command similar to this
+        should work:</p>
 <pre>
  diff -urp libvirt.orig/ libvirt.modified/ &gt; libvirt-myfeature.patch
 </pre>
@@ -38,18 +20,14 @@
 <pre>
  git diff &gt; libvirt-myfeature.patch
 </pre>
-        <p>Also, for code motion patches, you may find that <code>git
-        diff --patience</code> provides an easier-to-read patch.
-        However, the usual workflow of libvirt developer is:</p>
+        <p>However, the usual workflow of libvirt developer is:</p>
 <pre>
  git checkout master
  git pull
  git checkout -t origin -b workbranch
  Hack, committing any changes along the way
 </pre>
-        <p>More hints on compiling can be
-        found <a href="compiling.html">here</a>.  When you want to
-        post your patches:</p>
+        <p>Then, when you want to post your patches:</p>
 <pre>
  git pull --rebase
  (fix any conflicts)
@@ -57,7 +35,7 @@
                 --to=libvir-list@redhat.com master
 </pre>
        <p>(Note that the "git send-email" subcommand may not be in
-        the main git package and using it may require installation of a
+        the main git package and using it may require installion of a
        separate package, for example the "git-email" package in
        Fedora.)  For a single patch you can omit
        <code>--cover-letter</code>, but a series of two or more
@@ -72,7 +50,7 @@
        review your patch set. One should avoid sending patches as attachments,
        but rather send them in email body along with commit message. If a
        developer is sending another version of the patch (e.g. to address
-        review comments), they are advised to note differences to previous
+        review comments), he is advised to note differences to previous
        versions after the <code>---</code> line in the patch so that it helps
        reviewers but doesn't become part of git history. Moreover, such patch
        needs to be prefixed correctly with
@@ -81,21 +59,6 @@
        version if needed though).</p>
      </li>

-      <li><p>In your commit message, make the summary line reasonably
-          short (60 characters is typical), followed by a blank line,
-          followed by any longer description of why your patch makes
-          sense.  If the patch fixes a regression, and you know what
-          commit introduced the problem, mentioning that is useful.
-          If the patch resolves a bugzilla report, mentioning the URL
-          of the bug number is useful; but also summarize the issue
-          rather than making all readers follow the link.  You can use
-          'git shortlog -30' to get an idea of typical summary lines.
-          Libvirt does not currently attach any meaning to
-          Signed-off-by: lines, so it is up to you if you want to
-          include or omit them in the commit message.
-        </p>
-      </li>
-
      <li><p>Split large changes into a series of smaller patches,
        self-contained if possible, with an explanation of each patch
        and an explanation of how the sequence of patches fits
@@ -125,23 +88,10 @@
  make syntax-check
  make -C tests valgrind
 </pre>
-        <p><a href="http://valgrind.org/">Valgrind</a> is a test that checks
-        for memory management issues, such as leaks or use of uninitialized
-        variables.
+        <p>
+          The latter test checks for memory leaks.
        </p>

-        <p>
-          Some tests are skipped by default in a development environment,
-          based on the time they take in comparison to the likelihood
-          that those tests will turn up problems during incremental builds.
-          These tests default to being run when building from a
-          tarball or with the configure option --enable-expensive-tests;
-          you can also force a one-time toggle of these tests by
-          setting VIR_TEST_EXPENSIVE to 0 or 1 at make time, as in:
-        </p>
-<pre>
-  make check VIR_TEST_EXPENSIVE=1
-</pre>
        <p>
          If you encounter any failing tests, the VIR_TEST_DEBUG
          environment variable may provide extra information to debug
@@ -153,17 +103,6 @@
  VIR_TEST_DEBUG=1 make check    (or)
  VIR_TEST_DEBUG=2 make check
 </pre>
-
-        <p>
-          When debugging failures during development, it is possible
-          to focus in on just the failing subtests by using TESTS and
-          VIR_TEST_RANGE:
-        </p>
-
-<pre>
-  make check VIR_TEST_DEBUG=1 VIR_TEST_RANGE=3-5 TESTS=qemuxml2argvtest
-</pre>
-
        <p>
          Also, individual tests can be run from inside the <code>tests/</code>
          directory, like:
@@ -172,110 +111,6 @@
  ./qemuxml2xmltest
 </pre>

-        <p>
-          If you are adding new test cases, or making changes that alter
-          existing test output, you can use the environment variable
-          VIR_TEST_REGENERATE_OUTPUT to quickly update the saved test data.
-          Of course you still need to review the changes VERY CAREFULLY to
-          ensure they are correct.
-        </p>
-<pre>
-  VIR_TEST_REGENERATE_OUTPUT=1 ./qemuxml2argvtest
-</pre>
-
-        <p>There is also a <code>./run</code> script at the top level,
-          to make it easier to run programs that have not yet been
-          installed, as well as to wrap invocations of various tests
-          under gdb or Valgrind.
-        </p>
-
-      </li>
-      <li><p>The Valgrind test should produce similar output to
-          <code>make check</code>. If the output has traces within libvirt
-          API's, then investigation is required in order to determine the
-          cause of the issue. Output such as the following indicates some
-          sort of leak:
-        </p>
-<pre>
-==5414== 4 bytes in 1 blocks are definitely lost in loss record 3 of 89
-==5414==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
-==5414==    by 0x34DE0AAB85: xmlStrndup (in /usr/lib64/libxml2.so.2.7.8)
-==5414==    by 0x4CC97A6: virDomainVideoDefParseXML (domain_conf.c:7410)
-==5414==    by 0x4CD581D: virDomainDefParseXML (domain_conf.c:10188)
-==5414==    by 0x4CD8C73: virDomainDefParseNode (domain_conf.c:10640)
-==5414==    by 0x4CD8DDB: virDomainDefParse (domain_conf.c:10590)
-==5414==    by 0x41CB1D: testCompareXMLToArgvHelper (qemuxml2argvtest.c:100)
-==5414==    by 0x41E20F: virtTestRun (testutils.c:161)
-==5414==    by 0x41C7CB: mymain (qemuxml2argvtest.c:866)
-==5414==    by 0x41E84A: virtTestMain (testutils.c:723)
-==5414==    by 0x34D9021734: (below main) (in /usr/lib64/libc-2.15.so)
-</pre>
-        <p>In this example, the <code>virDomainDefParseXML()</code> had
-           an error path where the <code>virDomainVideoDefPtr video</code>
-           pointer was not properly disposed. By simply adding a
-           <code>virDomainVideoDefFree(video);</code> in the error path,
-           the issue was resolved.
-        </p>
-
-        <p>Another common mistake is calling a printing function, such as
-           <code>VIR_DEBUG()</code> without initializing a variable to be
-           printed.  The following example involved a call which could return
-           an error, but not set variables passed by reference to the call.
-           The solution was to initialize the variables prior to the call.
-        </p>
-<pre>
-==4749== Use of uninitialised value of size 8
-==4749==    at 0x34D904650B: _itoa_word (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x34D9049118: vfprintf (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x34D9108F60: __vasprintf_chk (in /usr/lib64/libc-2.15.so)
-==4749==    by 0x4CAEEF7: virVasprintf (stdio2.h:199)
-==4749==    by 0x4C8A55E: virLogVMessage (virlog.c:814)
-==4749==    by 0x4C8AA96: virLogMessage (virlog.c:751)
-==4749==    by 0x4DA0056: virNetTLSContextCheckCertKeyUsage (virnettlscontext.c:225)
-==4749==    by 0x4DA06DB: virNetTLSContextCheckCert (virnettlscontext.c:439)
-==4749==    by 0x4DA1620: virNetTLSContextNew (virnettlscontext.c:562)
-==4749==    by 0x4DA26FC: virNetTLSContextNewServer (virnettlscontext.c:927)
-==4749==    by 0x409C39: testTLSContextInit (virnettlscontexttest.c:467)
-==4749==    by 0x40AB8F: virtTestRun (testutils.c:161)
-</pre>
-        <p>Valgrind will also find some false positives or code paths
-           which cannot be resolved by making changes to the libvirt code.
-           For these paths, it is possible to add a filter to avoid the
-           errors. For example:
-        </p>
-<pre>
-==4643== 7 bytes in 1 blocks are possibly lost in loss record 4 of 20
-==4643==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
-==4643==    by 0x34D90853F1: strdup (in /usr/lib64/libc-2.15.so)
-==4643==    by 0x34EEC2C08A: ??? (in /usr/lib64/libnl.so.1.1)
-==4643==    by 0x34EEC15B81: ??? (in /usr/lib64/libnl.so.1.1)
-==4643==    by 0x34D8C0EE15: call_init.part.0 (in /usr/lib64/ld-2.15.so)
-==4643==    by 0x34D8C0EECF: _dl_init (in /usr/lib64/ld-2.15.so)
-==4643==    by 0x34D8C01569: ??? (in /usr/lib64/ld-2.15.so)
-
-</pre>
-        <p>In this instance, it is acceptable to modify the
-           <code>tests/.valgrind.supp</code> file in order to add a
-           suppression filter. The filter should be unique enough to
-           not suppress real leaks, but it should be generic enough to
-           cover multiple code paths. The format of the entry can be
-           found in the documentation found at the
-           <a href="http://valgrind.org/">Valgrind home page</a>.
-           The following trace was added to <code>tests/.valgrind.supp</code>
-           in order to suppress the warning:
-        </p>
-<pre>
-{
-    dlInitMemoryLeak1
-    Memcheck:Leak
-    fun:?alloc
-    ...
-    fun:call_init.part.0
-    fun:_dl_init
-    ...
-    obj:*/lib*/ld-2.*so*
-}
-</pre>
      </li>
      <li>Update tests and/or documentation, particularly if you are adding
        a new feature or changing the output of a program.</li>
@@ -284,8 +119,8 @@
    <p>
      There is more on this subject, including lots of links to background
      reading on the subject, on
-      <a href="http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/">
-        Richard Jones' guide to working with open source projects</a>.
+      <a href="http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/">
+        Richard Jones' guide to working with open source projects</a>
    </p>


@@ -297,11 +132,26 @@
      In short, use spaces-not-TABs for indentation, use 4 spaces for each
      indentation level, and other than that, follow the K&amp;R style.
    </p>
+    <p>
+      If you use Emacs, add the following to one of one of your start-up files
+      (e.g., ~/.emacs), to help ensure that you get indentation right:
+    </p>
+<pre>
+  ;;; When editing C sources in libvirt, use this style.
+  (defun libvirt-c-mode ()
+    "C mode with adjusted defaults for use with libvirt."
+    (interactive)
+    (c-set-style "K&amp;R")
+    (setq indent-tabs-mode nil) ; indent using spaces, not TABs
+    (setq c-indent-level 4)
+    (setq c-basic-offset 4))
+  (add-hook 'c-mode-hook
+            '(lambda () (if (string-match "/libvirt" (buffer-file-name))
+                            (libvirt-c-mode))))
+</pre>

    <p>
-      If you use Emacs, the project includes a file .dir-locals.el
-      that sets up the preferred indentation. If you use vim,
-      append the following to your ~/.vimrc file:
+      If you use vim, append the following to your ~/.vimrc file:
    </p>
 <pre>
  set nocompatible
@@ -312,7 +162,7 @@
  set tabstop=8
  set shiftwidth=4
  set expandtab
-  set cinoptions=(0,:0,l1,t0,L3
+  set cinoptions=(0,:0,l1,t0
  filetype plugin indent on
  au FileType make setlocal noexpandtab
  au BufRead,BufNewFile *.am setlocal noexpandtab
@@ -367,7 +217,7 @@
    <p>
      The keywords <code>if</code>, <code>for</code>, <code>while</code>,
      and <code>switch</code> must have a single space following them
-      before the opening bracket. E.g.
+      before the opening bracket. eg
    </p>
    <pre>
      if(foo)   // Bad
@@ -376,7 +226,7 @@

    <p>
      Function implementations must <strong>not</strong> have any whitespace
-      between the function name and the opening bracket. E.g.
+      between the function name and the opening bracket. eg
    </p>
    <pre>
      int foo (int wizz)  // Bad
@@ -385,7 +235,7 @@

    <p>
      Function calls must <strong>not</strong> have any whitespace
-      between the function name and the opening bracket. E.g.
+      between the function name and the opening bracket. eg
    </p>
    <pre>
      bar = foo (wizz);  // Bad
@@ -395,7 +245,7 @@
    <p>
      Function typedefs must <strong>not</strong> have any whitespace
      between the closing bracket of the function name and opening
-      bracket of the arg list. E.g.
+      bracket of the arg list. eg
    </p>
    <pre>
      typedef int (*foo) (int wizz);  // Bad
@@ -404,109 +254,33 @@

    <p>
      There must not be any whitespace immediately following any
-      opening bracket, or immediately prior to any closing bracket. E.g.
+      opening bracket, or immediately prior to any closing bracket
    </p>
    <pre>
      int foo( int wizz );  // Bad
      int foo(int wizz);    // Good
 </pre>

-    <h2><a name="comma">Commas</a></h2>
-
-    <p>
-      Commas should always be followed by a space or end of line, and
-      never have leading space; this is enforced during 'make
-      syntax-check'.
-    </p>
-    <pre>
-      call(a,b ,c);// Bad
-      call(a, b, c); // Good
-</pre>
-
-    <p>
-      When declaring an enum or using a struct initializer that
-      occupies more than one line, use a trailing comma.  That way,
-      future edits to extend the list only have to add a line, rather
-      than modify an existing line to add the intermediate comma.  Any
-      sentinel enumerator value with a name ending in _LAST is exempt,
-      since you would extend such an enum before the _LAST element.
-      Another reason to favor trailing commas is that it requires less
-      effort to produce via code generators.  Note that the syntax
-      checker is unable to enforce a style of trailing commas, so
-      there are counterexamples in existing code which do not use it;
-      also, while C99 allows trailing commas, remember that JSON and
-      XDR do not.
-    </p>
-    <pre>
-      enum {
-          VALUE_ONE,
-          VALUE_TWO // Bad
-      };
-      enum {
-          VALUE_THREE,
-          VALUE_FOUR, // Good
-      };
-</pre>
-
-    <h2><a name="semicolon">Semicolons</a></h2>
-
-    <p>
-      Semicolons should never have a space beforehand.  Inside the
-      condition of a <code>for</code> loop, there should always be a
-      space or line break after each semicolon, except for the special
-      case of an infinite loop (although more infinite loops
-      use <code>while</code>).  While not enforced, loop counters
-      generally use post-increment.
-    </p>
-    <pre>
-      for (i = 0 ;i &lt; limit ; ++i) { // Bad
-      for (i = 0; i &lt; limit; i++) { // Good
-      for (;;) { // ok
-      while (1) { // Better
-</pre>
-    <p>
-      Empty loop bodies are better represented with curly braces and a
-      comment, although use of a semicolon is not currently rejected.
-    </p>
-    <pre>
-      while ((rc = waitpid(pid, &amp;st, 0) == -1) &amp;&amp;
-             errno == EINTR); // ok
-      while ((rc = waitpid(pid, &amp;st, 0) == -1) &amp;&amp;
-             errno == EINTR) { // Better
-          /* nothing */
-      }
-</pre>
-
    <h2><a name="curly_braces">Curly braces</a></h2>

    <p>
      Omit the curly braces around an <code>if</code>, <code>while</code>,
-      <code>for</code> etc. body only when both that body and the condition
-      itself occupy a single line.  In every other case we require
+      <code>for</code> etc. body only
+      when that body occupies a single line.  In every other case we require
      the braces.  This ensures that it is trivially easy to identify a
      single-<i>statement</i> loop: each has only one <i>line</i> in its body.
    </p>
+    <p>
+      Omitting braces with a single-line body is fine:
+    </p>

 <pre>
-  while (expr)             // single line body; {} is forbidden
+  while (expr) // one-line body -> omitting curly braces is ok
      single_line_stmt();
 </pre>

-<pre>
-  while (expr(arg1,
-              arg2))      // indentation makes it obvious it is single line,
-      single_line_stmt(); // {} is optional (not enforced either way)
-</pre>
-
-<pre>
-  while (expr1 &amp;&amp;
-         expr2) {         // multi-line, at same indentation, {} required
-      single_line_stmt();
-  }
-</pre>
-
    <p>
-      However, the moment your loop/if/else body extends on to a second
+      However, the moment your loop/if/else body extends onto a second
      line, for whatever reason (even if it's just an added comment), then
      you should add braces.  Otherwise, it would be too easy to insert a
      statement just before that comment (without adding braces), thinking
@@ -627,46 +401,8 @@
  }
 </pre>

-    <p>Use hanging braces for compound statements: the opening brace
-      of a compound statement should be on the same line as the
-      condition being tested.  Only top-level function bodies, nested
-      scopes, and compound structure declarations should ever have {
-      on a line by itself.
-    </p>
-
-<pre>
-  void
-  foo(int a, int b)
-  {                          // correct - function body
-      int 2d[][] = {
-        {                    // correct - complex initialization
-          1, 2,
-        },
-      };
-      if (a)
-      {                      // BAD: compound brace on its own line
-          do_stuff();
-      }
-      {                      // correct - nested scope
-          int tmp;
-          if (a &lt; b) {       // correct - hanging brace
-              tmp = b;
-              b = a;
-              a = tmp;
-          }
-      }
-  }
-</pre>
-
    <h2><a name="preprocessor">Preprocessor</a></h2>

-    <p>Macros defined with an ALL_CAPS name should generally be
-      assumed to be unsafe with regards to arguments with side-effects
-      (that is, MAX(a++, b--) might increment a or decrement b too
-      many or too few times).  Exceptions to this rule are explicitly
-      documented for macros in viralloc.h and virstring.h.
-    </p>
-
    <p>
      For variadic macros, stick with C99 syntax:
    </p>
@@ -679,7 +415,7 @@
    </p>
 <pre>
  #if defined(HAVE_POSIX_FALLOCATE) &amp;&amp; !defined(HAVE_FALLOCATE)
-  # define fallocate(a, ignored, b, c) posix_fallocate(a, b, c)
+  # define fallocate(a,ignored,b,c) posix_fallocate(a,b,c)
  #endif
 </pre>

@@ -764,7 +500,7 @@
      Use of the malloc/free/realloc/calloc APIs is deprecated in the libvirt
      codebase, because they encourage a number of serious coding bugs and do
      not enable compile time verification of checks for NULL. Instead of these
-      routines, use the macros from viralloc.h.
+      routines, use the macros from memory.h.
    </p>

    <ul>
@@ -773,8 +509,10 @@
 <pre>
  virDomainPtr domain;

-  if (VIR_ALLOC(domain) &lt; 0)
+  if (VIR_ALLOC(domain) &lt; 0) {
+      virReportOOMError();
      return NULL;
+  }
 </pre>
      </li>

@@ -783,8 +521,10 @@
  virDomainPtr domains;
  size_t ndomains = 10;

-  if (VIR_ALLOC_N(domains, ndomains) &lt; 0)
+  if (VIR_ALLOC_N(domains, ndomains) &lt; 0) {
+      virReportOOMError();
      return NULL;
+  }
 </pre>
      </li>

@@ -793,8 +533,10 @@
  virDomainPtr *domains;
  size_t ndomains = 10;

-  if (VIR_ALLOC_N(domains, ndomains) &lt; 0)
+  if (VIR_ALLOC_N(domains, ndomains) &lt; 0) {
+      virReportOOMError();
      return NULL;
+  }
 </pre>
      </li>

@@ -806,8 +548,10 @@
  virDomainPtr domains;
  size_t ndomains = 0;

-  if (VIR_EXPAND_N(domains, ndomains, 1) &lt; 0)
+  if (VIR_EXPAND_N(domains, ndomains, 1) &lt; 0) {
+      virReportOOMError();
      return NULL;
+  }
  domains[ndomains - 1] = domain;
 </pre></li>

@@ -820,8 +564,10 @@
  size_t ndomains = 0;
  size_t ndomains_max = 0;

-  if (VIR_RESIZE_N(domains, ndomains_max, ndomains, 1) &lt; 0)
+  if (VIR_RESIZE_N(domains, ndomains_max, ndomains, 1) &lt; 0) {
+      virReportOOMError();
      return NULL;
+  }
  domains[ndomains++] = domain;
 </pre>
      </li>
@@ -993,27 +739,12 @@
      virStrncpy(dest, src, strlen(src), sizeof(dest)).
    </p>

-<pre>
-  VIR_STRDUP(char *dst, const char *src);
-  VIR_STRNDUP(char *dst, const char *src, size_t n);
-</pre>
-    <p>
-      You should avoid using strdup or strndup directly as they do not report
-      out-of-memory error, and do not allow a NULL source. Use
-      VIR_STRDUP or VIR_STRNDUP macros instead, which return 0 for
-      NULL source, 1 for successful copy, and -1 for allocation
-      failure with the error already reported. In very
-      specific cases, when you don't want to report the out-of-memory error, you
-      can use VIR_STRDUP_QUIET or VIR_STRNDUP_QUIET, but such usage is very rare
-      and usually considered a flaw.
-    </p>
-
    <h2><a name="strbuf">Variable length string buffer</a></h2>

    <p>
      If there is a need for complex string concatenations, avoid using
      the usual sequence of malloc/strcpy/strcat/snprintf functions and
-      make use of the virBuffer API described in virbuffer.h
+      make use of the virBuffer API described in buf.h
    </p>

    <p>Typical usage is as follows:</p>
@@ -1033,8 +764,11 @@

     ...

-     if (virBufferCheckError(&amp;buf) &lt; 0)
+     if (virBufferError(&amp;buf)) {
+         virBufferFreeAndReset(&amp;buf);
+         virReportOOMError();
         return NULL;
+     }

     return virBufferContentAndReset(&amp;buf);
  }
@@ -1065,7 +799,7 @@
  #include &lt;string.h&gt;
  #include &lt;limits.h&gt;

-  #if WITH_NUMACTL                Some system includes aren't supported
+  #if HAVE_NUMACTL                Some system includes aren't supported
  # include &lt;numa.h&gt;              everywhere so need these #if guards.
  #endif

@@ -1081,12 +815,10 @@
 </pre>

    <p>
-      Of particular note: <b>Do not</b> include libvirt/libvirt.h,
-      libvirt/virterror.h, libvirt/libvirt-qemu.h, or libvirt/libvirt-lxc.h.
-      They are included by "internal.h" already and there are some special reasons
-      why you cannot include these files explicitly. One of the special cases,
-      "libvirt/libvirt.h" is included prior to "internal.h" in "remote_protocol.x",
-      to avoid exposing *_LAST enum elements.
+      Of particular note: <b>Do not</b> include libvirt/libvirt.h or
+      libvirt/virterror.h.  It is included by "internal.h" already and there
+      are some special reasons why you cannot include these files
+      explicitly.
    </p>


@@ -1186,20 +918,6 @@
      retry: If needing to jump upwards (e.g., retry on EINTR)
 </pre>

-    <p>
-    Top-level labels should be indented by one space (putting them on
-    the beginning of the line confuses function context detection in git):
-    </p>
-
-<pre>
-int foo()
-{
-    /* ... do stuff ... */
- cleanup:
-    /* ... do other stuff ... */
-}
-</pre>
-


    <h2><a name="committers">Libvirt committer guidelines</a></h2>
--- a/Show More
+++ b/Show More