mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-09-17 21:45:33 +03:00
Compare commits
1 Commits
v6.4.0-rc1
...
v0.8.3-mai
| Author | SHA1 | Date | |
|---|---|---|---|
|
b1a94564ad |
@@ -1,38 +0,0 @@
|
||||
-I@abs_top_builddir@
|
||||
-I@abs_top_srcdir@
|
||||
-I@abs_top_builddir@/include
|
||||
-I@abs_top_srcdir@/include
|
||||
-I@abs_top_builddir@/src
|
||||
-I@abs_top_srcdir@/src
|
||||
-I@abs_top_builddir@/src/access
|
||||
-I@abs_top_srcdir@/src/access
|
||||
-I@abs_top_builddir@/src/admin
|
||||
-I@abs_top_srcdir@/src/admin
|
||||
-I@abs_top_builddir@/src/bhyve
|
||||
-I@abs_top_srcdir@/src/bhyve
|
||||
-I@abs_top_builddir@/src/conf
|
||||
-I@abs_top_srcdir@/src/conf
|
||||
-I@abs_top_builddir@/src/libxl
|
||||
-I@abs_top_srcdir@/src/libxl
|
||||
-I@abs_top_builddir@/src/locking
|
||||
-I@abs_top_srcdir@/src/locking
|
||||
-I@abs_top_builddir@/src/logging
|
||||
-I@abs_top_srcdir@/src/logging
|
||||
-I@abs_top_builddir@/src/lxc
|
||||
-I@abs_top_srcdir@/src/lxc
|
||||
-I@abs_top_builddir@/src/qemu
|
||||
-I@abs_top_srcdir@/src/qemu
|
||||
-I@abs_top_builddir@/src/remote
|
||||
-I@abs_top_srcdir@/src/remote
|
||||
-I@abs_top_builddir@/src/rpc
|
||||
-I@abs_top_srcdir@/src/rpc
|
||||
-I@abs_top_builddir@/src/secret
|
||||
-I@abs_top_srcdir@/src/secret
|
||||
-I@abs_top_builddir@/src/security
|
||||
-I@abs_top_srcdir@/src/security
|
||||
-I@abs_top_builddir@/src/util
|
||||
-I@abs_top_srcdir@/src/util
|
||||
-I@abs_top_builddir@/src/vmx
|
||||
-I@abs_top_srcdir@/src/vmx
|
||||
-I@abs_top_builddir@/src/xenconfig
|
||||
-I@abs_top_srcdir@/src/xenconfig
|
||||
6
.ctags
6
.ctags
@@ -1,6 +0,0 @@
|
||||
--recurse
|
||||
--exclude=*.orig
|
||||
--exclude=*.html
|
||||
--exclude=*.html.in
|
||||
--langmap=c:+.h.in
|
||||
--c-kinds=+p
|
||||
@@ -1 +0,0 @@
|
||||
../.ctags
|
||||
@@ -1,20 +0,0 @@
|
||||
(
|
||||
(c-mode . (
|
||||
(c-file-style . "K&R")
|
||||
(indent-tabs-mode . nil)
|
||||
(c-indent-level . 4)
|
||||
(c-basic-offset . 4)
|
||||
))
|
||||
(html-mode . (
|
||||
(indent-tabs-mode . nil)
|
||||
))
|
||||
(sh-mode . (
|
||||
(indent-tabs-mode . nil)
|
||||
))
|
||||
(nxml-mode . (
|
||||
(indent-tabs-mode . nil)
|
||||
))
|
||||
(perl-mode . (
|
||||
(indent-tabs-mode . nil)
|
||||
))
|
||||
)
|
||||
@@ -1,21 +0,0 @@
|
||||
# EditorConfig is a file format and collection of text editor plugins
|
||||
# for maintaining consistent coding styles between different editors
|
||||
# and IDEs. Most popular editors support this either natively or via
|
||||
# plugin.
|
||||
#
|
||||
# Check https://editorconfig.org for details.
|
||||
|
||||
root = true
|
||||
|
||||
[*]
|
||||
end_of_line = lf
|
||||
insert_final_newline = true
|
||||
charset = utf-8
|
||||
|
||||
[*.c]
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
|
||||
[*.{rng,xml}]
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
38
.github/lockdown.yml
vendored
38
.github/lockdown.yml
vendored
@@ -1,38 +0,0 @@
|
||||
# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown
|
||||
|
||||
skipCreatedBefore: 2020-01-01
|
||||
|
||||
# Close issues and pull requests
|
||||
close: true
|
||||
|
||||
# Lock issues and pull requests
|
||||
lock: true
|
||||
|
||||
# Optionally, specify configuration settings just for `issues` or `pulls`
|
||||
issues:
|
||||
comment: |
|
||||
Thank you for your interest in the libvirt project.
|
||||
|
||||
Since this repository is a read-only mirror of the project's master repostory hosted on GitLab, issues opened here are not processed.
|
||||
|
||||
We kindly request that new issues are reported to
|
||||
|
||||
https://gitlab.com/libvirt/libvirt/-/issues/new
|
||||
|
||||
Thank you for your time and understanding.
|
||||
|
||||
pulls:
|
||||
comment: |
|
||||
Thank you for your interest in the libvirt project.
|
||||
|
||||
Since this repository is a read-only mirror of the project's master repostory hosted on GitLab, merge requests opened here are not processed.
|
||||
|
||||
We kindly request that contributors fork the project at
|
||||
|
||||
https://gitlab.com/libvirt/libvirt/
|
||||
|
||||
push changes to the fork, and then open a new merge request at
|
||||
|
||||
https://gitlab.com/libvirt/libvirt/-/merge_requests/new
|
||||
|
||||
Thank you for your time and understanding.
|
||||
86
.gitignore
vendored
86
.gitignore
vendored
@@ -1,40 +1,54 @@
|
||||
# vim related ignores
|
||||
*.swp
|
||||
.lvimrc
|
||||
|
||||
# emacs related ignores
|
||||
*#*#
|
||||
*.#*#
|
||||
.#*
|
||||
*~
|
||||
|
||||
# autotools related ignores
|
||||
!/m4/virt-*.m4
|
||||
*.cov
|
||||
/AUTHORS
|
||||
/INSTALL
|
||||
/aclocal.m4
|
||||
/autom4te.cache
|
||||
/build-aux/compile
|
||||
/build-aux/config.guess
|
||||
/build-aux/config.sub
|
||||
/build-aux/depcomp
|
||||
/build-aux/install-sh
|
||||
/build-aux/ltmain.sh
|
||||
/build-aux/missing
|
||||
/build-aux/test-driver
|
||||
/config.h.in
|
||||
/config.log
|
||||
/configure
|
||||
/m4/*
|
||||
Makefile.in
|
||||
|
||||
# git related ignores
|
||||
*.rej
|
||||
*.a
|
||||
*.exe
|
||||
*.gcda
|
||||
*.gcno
|
||||
*.gcov
|
||||
*.o
|
||||
*.orig
|
||||
*.rej
|
||||
*~
|
||||
.git
|
||||
.git-module-status
|
||||
|
||||
# libvirt related ignores
|
||||
/build/
|
||||
/ci/scratch/
|
||||
tags
|
||||
.sc-start-sc_*
|
||||
/GNUmakefile
|
||||
/libvirt-[0-9]*
|
||||
/maint.mk
|
||||
ABOUT-NLS
|
||||
COPYING
|
||||
ChangeLog
|
||||
INSTALL
|
||||
Makefile
|
||||
Makefile.in
|
||||
NEWS
|
||||
aclocal.m4
|
||||
autom4te.cache
|
||||
config.cache
|
||||
config.guess
|
||||
config.h
|
||||
config.h.in
|
||||
config.log
|
||||
config.rpath
|
||||
config.status
|
||||
config.sub
|
||||
configure
|
||||
coverage
|
||||
cscope.files
|
||||
cscope.out
|
||||
gnulib/
|
||||
libtool
|
||||
libvirt-*.tar.gz
|
||||
libvirt.pc
|
||||
libvirt.spec
|
||||
ltconfig
|
||||
ltmain.sh
|
||||
mingw32-libvirt.spec
|
||||
mkinstalldirs
|
||||
results.log
|
||||
stamp-h
|
||||
stamp-h.in
|
||||
stamp-h1
|
||||
tests/*.log
|
||||
tests/nwfilterxml2xmltest
|
||||
update.log
|
||||
|
||||
235
.gitlab-ci.yml
235
.gitlab-ci.yml
@@ -1,235 +0,0 @@
|
||||
variables:
|
||||
GIT_DEPTH: 100
|
||||
|
||||
stages:
|
||||
- prebuild
|
||||
- native_build
|
||||
- cross_build
|
||||
|
||||
.script_variables: &script_variables |
|
||||
export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
|
||||
export CCACHE_BASEDIR="$(pwd)"
|
||||
export CCACHE_DIR="$CCACHE_BASEDIR/ccache"
|
||||
export CCACHE_MAXSIZE="500M"
|
||||
export PATH="$CCACHE_WRAPPERSDIR:$PATH"
|
||||
|
||||
# Common templates
|
||||
|
||||
# Default native build jobs that are always run
|
||||
.native_build_default_job_template: &native_build_default_job_definition
|
||||
stage: native_build
|
||||
cache:
|
||||
paths:
|
||||
- ccache/
|
||||
key: "$CI_JOB_NAME"
|
||||
before_script:
|
||||
- *script_variables
|
||||
script:
|
||||
- mkdir build
|
||||
- cd build
|
||||
- ../autogen.sh || (cat config.log && exit 1)
|
||||
- $MAKE distcheck
|
||||
|
||||
# Extra native build jobs that are only run post-merge, or
|
||||
# when code is pushed to a branch with "ci-full-" name prefix
|
||||
.native_build_extra_job_template: &native_build_extra_job_definition
|
||||
<<: *native_build_default_job_definition
|
||||
only:
|
||||
- master
|
||||
- /^ci-full-.*$/
|
||||
|
||||
|
||||
# Default cross build jobs that are always run
|
||||
.cross_build_default_job_template: &cross_build_default_job_definition
|
||||
stage: cross_build
|
||||
cache:
|
||||
paths:
|
||||
- ccache/
|
||||
key: "$CI_JOB_NAME"
|
||||
before_script:
|
||||
- *script_variables
|
||||
script:
|
||||
- mkdir build
|
||||
- cd build
|
||||
- ../autogen.sh $CONFIGURE_OPTS || (cat config.log && exit 1)
|
||||
- $MAKE
|
||||
|
||||
# Extra cross build jobs that are only run post-merge, or
|
||||
# when code is pushed to a branch with "ci-full-" name prefix
|
||||
.cross_build_extra_job_template: &cross_build_extra_job_definition
|
||||
<<: *cross_build_default_job_definition
|
||||
only:
|
||||
- master
|
||||
- /^ci-full-.*$/
|
||||
|
||||
|
||||
# Native architecture build + test jobs
|
||||
|
||||
x64-debian-9:
|
||||
<<: *native_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-9:latest
|
||||
|
||||
x64-debian-10:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-10:latest
|
||||
|
||||
x64-debian-sid:
|
||||
<<: *native_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-sid:latest
|
||||
|
||||
x64-centos-7:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-centos-7:latest
|
||||
|
||||
x64-centos-8:
|
||||
<<: *native_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-centos-8:latest
|
||||
|
||||
x64-fedora-31:
|
||||
<<: *native_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest
|
||||
|
||||
x64-fedora-32:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-fedora-32:latest
|
||||
|
||||
x64-fedora-rawhide:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide:latest
|
||||
|
||||
x64-opensuse-151:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-opensuse-151:latest
|
||||
|
||||
x64-ubuntu-1804:
|
||||
<<: *native_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-ubuntu-1804:latest
|
||||
|
||||
x64-ubuntu-2004:
|
||||
<<: *native_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-ubuntu-2004:latest
|
||||
|
||||
|
||||
# Cross compiled build jobs
|
||||
|
||||
armv6l-debian-9:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-armv6l:latest
|
||||
|
||||
mips64el-debian-9:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips64el:latest
|
||||
|
||||
mips-debian-9:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-9-cross-mips:latest
|
||||
|
||||
aarch64-debian-10:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-aarch64:latest
|
||||
|
||||
ppc64le-debian-10:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-ppc64le:latest
|
||||
|
||||
s390x-debian-10:
|
||||
<<: *cross_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-10-cross-s390x:latest
|
||||
|
||||
armv7l-debian-sid:
|
||||
<<: *cross_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-armv7l:latest
|
||||
|
||||
i686-debian-sid:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-i686:latest
|
||||
|
||||
mipsel-debian-sid:
|
||||
<<: *cross_build_extra_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-debian-sid-cross-mipsel:latest
|
||||
|
||||
mingw32-fedora-rawhide:
|
||||
<<: *cross_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide-cross-mingw32:latest
|
||||
|
||||
mingw64-fedora-rawhide:
|
||||
<<: *cross_build_default_job_definition
|
||||
image: quay.io/libvirt/buildenv-libvirt-fedora-rawhide-cross-mingw64:latest
|
||||
|
||||
|
||||
# This artifact published by this job is downloaded by libvirt.org to
|
||||
# be deployed to the web root:
|
||||
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=website
|
||||
website:
|
||||
stage: prebuild
|
||||
before_script:
|
||||
- *script_variables
|
||||
script:
|
||||
- mkdir build
|
||||
- cd build
|
||||
- ../autogen.sh --prefix=$(pwd)/../vroot || (cat config.log && exit 1)
|
||||
- $MAKE -C docs
|
||||
- $MAKE -C docs install
|
||||
- cd ..
|
||||
- mv vroot/share/doc/libvirt/html/ website
|
||||
image: quay.io/libvirt/buildenv-libvirt-centos-8:latest
|
||||
artifacts:
|
||||
expose_as: 'Website'
|
||||
name: 'website'
|
||||
when: on_success
|
||||
expire_in: 30 days
|
||||
paths:
|
||||
- website
|
||||
|
||||
|
||||
codestyle:
|
||||
stage: prebuild
|
||||
before_script:
|
||||
- *script_variables
|
||||
script:
|
||||
- mkdir build
|
||||
- cd build
|
||||
- ../autogen.sh || (cat config.log && exit 1)
|
||||
- $MAKE syntax-check
|
||||
image: quay.io/libvirt/buildenv-libvirt-centos-8:latest
|
||||
|
||||
|
||||
# This artifact published by this job is downloaded to push to Weblate
|
||||
# for translation usage:
|
||||
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=potfile
|
||||
potfile:
|
||||
stage: prebuild
|
||||
only:
|
||||
- master
|
||||
before_script:
|
||||
- *script_variables
|
||||
script:
|
||||
- mkdir build
|
||||
- cd build
|
||||
- ../autogen.sh || (cat config.log && exit 1)
|
||||
- $MAKE -C src generated-sources
|
||||
- $MAKE -C po libvirt.pot
|
||||
- cd ..
|
||||
- mv build/po/libvirt.pot libvirt.pot
|
||||
image: quay.io/libvirt/buildenv-libvirt-centos-8:latest
|
||||
artifacts:
|
||||
expose_as: 'Potfile'
|
||||
name: 'potfile'
|
||||
when: on_success
|
||||
expire_in: 30 days
|
||||
paths:
|
||||
- libvirt.pot
|
||||
|
||||
|
||||
# Check that all commits are signed-off for the DCO.
|
||||
# Skip on "libvirt" namespace, since we only need to run
|
||||
# this test on developer's personal forks from which
|
||||
# merge requests are submitted
|
||||
check-dco:
|
||||
stage: prebuild
|
||||
image: registry.gitlab.com/libvirt/libvirt-ci/check-dco:master
|
||||
script:
|
||||
- /check-dco
|
||||
except:
|
||||
variables:
|
||||
- $CI_PROJECT_NAMESPACE == 'libvirt'
|
||||
6
.gitmodules
vendored
6
.gitmodules
vendored
@@ -1,3 +1,3 @@
|
||||
[submodule "keycodemapdb"]
|
||||
path = src/keycodemapdb
|
||||
url = https://gitlab.com/keycodemap/keycodemapdb.git
|
||||
[submodule "gnulib"]
|
||||
path = .gnulib
|
||||
url = git://git.sv.gnu.org/gnulib.git
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
[gitpublishprofile "default"]
|
||||
base = master
|
||||
to = libvir-list@redhat.com
|
||||
prefix = libvirt PATCH
|
||||
79
.mailmap
79
.mailmap
@@ -1,79 +0,0 @@
|
||||
# 'git shortlog --help' and look for mailmap for the format of each line
|
||||
|
||||
# Email consolidation:
|
||||
# <Preferred address in AUTHORS> <other alias used by same author>
|
||||
|
||||
<bozzolan@gmail.com> <redshift@gmx.com>
|
||||
<charles_duffy@messageone.com> <charles@dyfis.net>
|
||||
<claudio.bley@gmail.com> <cbley@av-test.de>
|
||||
<dfj@redhat.com> <dfj@dfj.bne.redhat.com>
|
||||
<dpkshetty@gmail.com> <deepakcs@linux.vnet.ibm.com>
|
||||
<dpkshetty@gmail.com> <deepakcs@redhat.com>
|
||||
<eblake@redhat.com> <ebb9@byu.net>
|
||||
<gdolley@arpnetworks.com> <gdolley@ucla.edu>
|
||||
<gerhard.stenzel@de.ibm.com> <gstenzel@linux.vnet.ibm.com>
|
||||
<jamie@canonical.com> <jamie@ubuntu.com>
|
||||
<laine@redhat.com> <laine@laine.org>
|
||||
<meyering@redhat.com> <jim@meyering.net>
|
||||
<socketpair@gmail.com> <socketpair gmail com>
|
||||
<soren@linux2go.dk> <soren@ubuntu.com>
|
||||
<jfehlig@suse.com> <jfehlig@novell.com>
|
||||
<jfehlig@suse.com> <jfehlig@linux-ypgk.site>
|
||||
<jclift@redhat.com> <justin@salasaga.org>
|
||||
<soren@linux2go.dk> <soren@canonical.com>
|
||||
<cfergeau@redhat.com> <teuf@gnome.org>
|
||||
<wency@cn.fujitsu.com> <wency cn fujitsu com>
|
||||
<cardoe@cardoe.com> <cardoe@gentoo.org>
|
||||
<fsimonce@redhat.com> <federico.simoncelli@gmail.com>
|
||||
<marcandre.lureau@redhat.com> <marcandre.lureau@gmail.com>
|
||||
<supriyak@linux.vnet.ibm.com> <supriyak@in.ibm.com>
|
||||
<neil@aldur.co.uk> <neil@brightbox.co.uk>
|
||||
<stefanb@us.ibm.com> <stefanb@linux.vnet.ibm.com>
|
||||
<stefanb@us.ibm.com> <stefannb@linux.vnet.ibm.com>
|
||||
<josh.durgin@inktank.com> <joshd@hq.newdream.net>
|
||||
<josh.durgin@inktank.com> <josh.durgin@dreamhost.com>
|
||||
<gerd@egidy.de> <lists@egidy.de>
|
||||
<gerd@egidy.de> <gerd.von.egidy@intra2net.com>
|
||||
<benoar@dolka.fr> <benjamin.cama@telecom-bretagne.eu>
|
||||
<zhlcindy@linux.vnet.ibm.com> <zhlcindy@gmail.com>
|
||||
<serge.hallyn@canonical.com> <serue@us.ibm.com>
|
||||
<pritesh.kothari@sun.com> <Pritesh.Kothari@Sun.COM>
|
||||
<cbosdonnat@suse.com> <cedric.bosdonnat@free.fr>
|
||||
<mnestratov@virtuozzo.com> <mnestratov@parallels.com>
|
||||
<nshirokovskiy@virtuozzo.com> <nshirokovskiy@parallels.com>
|
||||
<jyang@redhat.com> <osier@yunify.com>
|
||||
<kkoukiou@redhat.com> <k.koukiou@googlemail.com>
|
||||
<intrigeri@boum.org> <intrigeri+libvirt@boum.org>
|
||||
<fidencio@redhat.com> <fabiano@fidencio.org>
|
||||
<shi_lei@massclouds.com> <shilei.massclouds@gmx.com>
|
||||
<adrian.brzezinski@eo.pl> <redhat@adrb.pl>
|
||||
|
||||
# Name consolidation:
|
||||
# Preferred author spelling <preferred email>
|
||||
Alex Jia <ajia@redhat.com>
|
||||
Royce Lv <lvroyce@linux.vnet.ibm.com>
|
||||
Daniel J Walsh <dwalsh@redhat.com>
|
||||
Ján Tomko <jtomko@redhat.com>
|
||||
Gerd von Egidy <gerd@egidy.de>
|
||||
MATSUDA Daiki <matsudadik@intellilink.co.jp>
|
||||
Tang Chen <tangchen@cn.fujitsu.com>
|
||||
Peng Zhou <ailvpeng25@gmail.com>
|
||||
Dirk Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
|
||||
Thibault VINCENT <thibault.vincent@smartjog.com>
|
||||
Aurelien Rougemont <beorn@binaries.fr>
|
||||
Serge E. Hallyn <serge.hallyn@canonical.com>
|
||||
Henrik Persson E <henrik.e.persson@ericsson.com>
|
||||
Philipp Hahn <hahn@univention.de>
|
||||
Pritesh Kothari <pritesh.kothari@sun.com>
|
||||
Wang Yufei (James) <james.wangyufei@huawei.com>
|
||||
Deepak C Shetty <dpkshetty@gmail.com>
|
||||
Dave Allan <dallan@redhat.com>
|
||||
Richard W.M. Jones <rjones@redhat.com>
|
||||
|
||||
# Non-trivial consolidation:
|
||||
# see git documentation for information about the format
|
||||
Daniel P. Berrangé <berrange@redhat.com>
|
||||
Daniel P. Berrangé <berrange@redhat.com> <dan@berrange.com>
|
||||
Michal Prívozník <mprivozn@redhat.com>
|
||||
Michal Prívozník <mprivozn@redhat.com> <miso.privoznik@gmail.com>
|
||||
Marco Bozzolan <bozzolan@gmail.com> <redshift@gmx.com>
|
||||
58
.travis.yml
58
.travis.yml
@@ -1,58 +0,0 @@
|
||||
language: c
|
||||
compiler: clang
|
||||
os: osx
|
||||
|
||||
branches:
|
||||
except:
|
||||
- /^.*-maint$/
|
||||
|
||||
addons:
|
||||
homebrew:
|
||||
update: true
|
||||
packages:
|
||||
- ccache
|
||||
- rpcgen
|
||||
- xz
|
||||
- yajl
|
||||
- glib
|
||||
- docutils
|
||||
- gnutls
|
||||
|
||||
matrix:
|
||||
include:
|
||||
- osx_image: xcode11.3
|
||||
- osx_image: xcode10.3
|
||||
|
||||
env:
|
||||
global:
|
||||
- PATH="/usr/local/opt/gettext/bin:/usr/local/opt/ccache/libexec:/usr/local/opt/rpcgen/bin:$PATH"
|
||||
- PKG_CONFIG_PATH="/usr/local/opt/libxml2/lib/pkgconfig"
|
||||
|
||||
before_script:
|
||||
# Hack to blow away py2
|
||||
- brew link --overwrite python
|
||||
|
||||
script:
|
||||
# We can't run 'distcheck' or 'syntax-check' because they fail on
|
||||
# macOS, but doing 'install' and 'dist' gives us some useful coverage
|
||||
- mkdir build && cd build
|
||||
- ../autogen.sh --prefix=$(pwd)/install-root && make -j3 && make -j3 install && make -j3 dist
|
||||
|
||||
git:
|
||||
submodules: true
|
||||
|
||||
notifications:
|
||||
irc:
|
||||
# The channel name "irc.oftc.net#virt" is encrypted against libvirt/libvirt
|
||||
# to prevent IRC notifications from github forks. This was created using:
|
||||
# $ travis encrypt -r "libvirt/libvirt" "irc.oftc.net#virt"
|
||||
channels:
|
||||
- secure: "hUPdkLxX7nh75+clpnk4U0XLExLfV9DFKSvQSAUtf5JtDNMslj7AeOCf2wcbkNsEhkiF557odTAnov1s5m1w/yaa56zbjFAh5agzqRKya3QjqsrvlBKw/WuN+l82iMNLLeebTgCPAXrbAbGWH8YmYssp/7+eMsnKaVh84EQQNbMCHlLg6ovE26Fs18mZ6J5RC3OPa1vbv+xkdCHvGg/Oyp4K8bpU7RYyimA56jdxI/OfdTH9HxntHYSzykR7hDbyzZhdIlAUyRKReQVjcV5+R8fdDL/1imyGA/88KTztMeKXpZ5Rf+Ss3vYLZb6qsLLegCZ4AU/q0vvbWxjpZGJZoeyrVpfBTZdYGIzmLTMl9GYXXa/gDwFlbvRDiPDG4TIy6GlMUROinj7KRKEHu1fWRYu012ife5OjidxcwrTnz21vYaCv3AKWPpMPxwIzQPkY1hex9uLLX6z+TrAxxDLF+7UzRT9w2RLFBkLYlj2aDVrLAVb/ynRsxDz5CGzC61FSQVft2e308SkGjdn8YxvguCuXv+N70Fu1cvFyh5XYeHb4fbBRo0Ctzaec78leHlQvRGWKJxXDXRkE2lvvBc7YbBNSAYh7Fs8Y+zY7l7rMxvXdrt3nuaNQhe74V3yhxPDAld66qmAn9TYMmaZW2f5/KKKILLbCa0t2MxiAc6L2OI8="
|
||||
on_success: change
|
||||
on_failure: always
|
||||
email:
|
||||
# The list name 'libvirt-ci@redhat.com" is encrypted against libvirt/libvirt
|
||||
# to prevent IRC notifications from github forks. This was created using:
|
||||
# $ travis encrypt -r "libvirt/libvirt" "libvirt-ci@redhat.com"
|
||||
recipients:
|
||||
- secure: "QcU9eP96P0RlDNzVRZl/4sxyydPStGzECrpgJhr2IPB/7pHk23yaBrmUsq9S830tB+jwLGma1IscNB8uf7Sf7WY+cYIpfR8v030OffWnaipo/Gcs0dpnlfURWHjOFQI3RJzGEihsqvbwUFOwsM+3IDyO3qdWaiT6cN2Tj9ROlwYCySSX5YWzLyX7arBZ4lp8ESs7ohQaEwp2cegnMP2oGPJJe4SebvlCDjHZbjkU5aEradwUWnRQDJZWTKknpNLArVFxN2/ixp6f/MGY4DmkHoDweio6mHIPN5zTs5Jt32aiX6wDBa+bBa4v8TCRqzhYkQ63ZZhNV8bY5Uf9ufTdyvt96yIANyakd85b1QpMdAX76IyJi1l0/Uub6DTQZAcq3vK7iPjGeTVSpyoXrqTfGy4JxMjqDoocpWvv8ALX1wrYI/HfN2R2Aepw9jModTimOsebYhJ1yMhSt8qnh5AQNftGKL2JBKoA1LWdU2YJ5fO1bGjKNiVEkGFQTPYFWrYCUY5JcT+s5WCzNeMNm8s9na8liYhGl3WtS3rPr5M8bof+BMsBhG2hQ0loduc94x2GkvyhQZUgRbqrwNR+y4hn+rWFC3hBzzyiAULs43vY/PJ+eBdKEf3VAc0MkhQ8GgXGSA61fR6aXYonroI/WnBVItwDmUnnMfSziZXxk09GLl4="
|
||||
@@ -1,43 +0,0 @@
|
||||
flags = [
|
||||
'-I@abs_top_builddir@',
|
||||
'-I@abs_top_srcdir@',
|
||||
'-I@abs_top_builddir@/include',
|
||||
'-I@abs_top_srcdir@/include',
|
||||
'-I@abs_top_builddir@/src',
|
||||
'-I@abs_top_srcdir@/src',
|
||||
'-I@abs_top_builddir@/src/access',
|
||||
'-I@abs_top_srcdir@/src/access',
|
||||
'-I@abs_top_builddir@/src/admin',
|
||||
'-I@abs_top_srcdir@/src/admin',
|
||||
'-I@abs_top_builddir@/src/bhyve',
|
||||
'-I@abs_top_srcdir@/src/bhyve',
|
||||
'-I@abs_top_builddir@/src/conf',
|
||||
'-I@abs_top_srcdir@/src/conf',
|
||||
'-I@abs_top_builddir@/src/libxl',
|
||||
'-I@abs_top_srcdir@/src/libxl',
|
||||
'-I@abs_top_builddir@/src/locking',
|
||||
'-I@abs_top_srcdir@/src/locking',
|
||||
'-I@abs_top_builddir@/src/logging',
|
||||
'-I@abs_top_srcdir@/src/logging',
|
||||
'-I@abs_top_builddir@/src/lxc',
|
||||
'-I@abs_top_srcdir@/src/lxc',
|
||||
'-I@abs_top_builddir@/src/qemu',
|
||||
'-I@abs_top_srcdir@/src/qemu',
|
||||
'-I@abs_top_builddir@/src/remote',
|
||||
'-I@abs_top_srcdir@/src/remote',
|
||||
'-I@abs_top_builddir@/src/rpc',
|
||||
'-I@abs_top_srcdir@/src/rpc',
|
||||
'-I@abs_top_builddir@/src/secret',
|
||||
'-I@abs_top_srcdir@/src/secret',
|
||||
'-I@abs_top_builddir@/src/security',
|
||||
'-I@abs_top_srcdir@/src/security',
|
||||
'-I@abs_top_builddir@/src/util',
|
||||
'-I@abs_top_srcdir@/src/util',
|
||||
'-I@abs_top_builddir@/src/vmx',
|
||||
'-I@abs_top_srcdir@/src/vmx',
|
||||
'-I@abs_top_builddir@/src/xenconfig',
|
||||
'-I@abs_top_srcdir@/src/xenconfig',
|
||||
]
|
||||
|
||||
def FlagsForFile(filename, **kwargs):
|
||||
return { 'flags': flags, 'do_cache': True }
|
||||
102
AUTHORS.in
102
AUTHORS.in
@@ -1,102 +0,0 @@
|
||||
libvirt Authors
|
||||
===============
|
||||
|
||||
The libvirt project was initiated by:
|
||||
|
||||
Daniel Veillard <veillard@redhat.com> or <daniel@veillard.com>
|
||||
|
||||
The primary maintainers and people with commit access rights:
|
||||
|
||||
Alex Jia <ajia@redhat.com>
|
||||
Andrea Bolognani <abologna@redhat.com>
|
||||
Cédric Bosdonnat <cbosdonnat@suse.com>
|
||||
Christian Ehrhardt <christian.ehrhardt@canonical.com>
|
||||
Christophe Fergeau <cfergeau@redhat.com>
|
||||
Claudio Bley <claudio.bley@gmail.com>
|
||||
Cole Robinson <crobinso@redhat.com>
|
||||
Daniel P. Berrangé <berrange@redhat.com>
|
||||
Daniel Veillard <veillard@redhat.com>
|
||||
Doug Goldstein <cardoe@gentoo.org>
|
||||
Eric Blake <eblake@redhat.com>
|
||||
Erik Skultety <eskultet@redhat.com>
|
||||
Fabiano Fidêncio <fidencio@redhat.com>
|
||||
Gao Feng <gaofeng@cn.fujitsu.com>
|
||||
Guido Günther <agx@sigxcpu.org>
|
||||
Ján Tomko <jtomko@redhat.com>
|
||||
Jim Fehlig <jfehlig@suse.com>
|
||||
Jiří Denemark <jdenemar@redhat.com>
|
||||
John Ferlan <jferlan@redhat.com>
|
||||
Katerina Koukiou <kkoukiou@redhat.com>
|
||||
Laine Stump <laine@redhat.com>
|
||||
Mark McLoughlin <markmc@redhat.com>
|
||||
Martin Kletzander <mkletzan@redhat.com>
|
||||
Matthias Bolte <matthias.bolte@googlemail.com>
|
||||
Maxim Nestratov <mnestratov@virtuozzo.com>
|
||||
Michal Prívozník <mprivozn@redhat.com>
|
||||
Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
|
||||
Pavel Hrdina <phrdina@redhat.com>
|
||||
Peter Krempa <pkrempa@redhat.com>
|
||||
Richard W.M. Jones <rjones@redhat.com>
|
||||
Roman Bogorodskiy <bogorodskiy@gmail.com>
|
||||
Stefan Berger <stefanb@us.ibm.com>
|
||||
Wen Congyang <wency@cn.fujitsu.com>
|
||||
|
||||
Previous maintainers:
|
||||
|
||||
Anthony Liguori <aliguori@us.ibm.com>
|
||||
Atsushi SAKAI <sakaia@jp.fujitsu.com>
|
||||
Chris Lalancette <clalance@redhat.com>
|
||||
Dan Smith <danms@us.ibm.com>
|
||||
Dave Allan <dallan@redhat.com>
|
||||
Dave Leskovec <dlesko@linux.vnet.ibm.com>
|
||||
Dmitry Guryanov <dguryanov@parallels.com>
|
||||
Guannan Ren <gren@redhat.com>
|
||||
Jim Meyering <meyering@redhat.com>
|
||||
John Levon <john.levon@sun.com>
|
||||
Justin Clift <jclift@redhat.com>
|
||||
Karel Zak <kzak@redhat.com>
|
||||
Osier Yang <jyang@redhat.com>
|
||||
|
||||
Patches have also been contributed by:
|
||||
|
||||
Abel Míguez Rodríguez <amiguezr@pdi.ucm.es>
|
||||
Amit Shah <amit.shah@redhat.com>
|
||||
Andrew Puch <apuch@redhat.com>
|
||||
Anton Protopopov <aspsk2@gmail.com>
|
||||
Ben Guthro <ben.guthro@gmail.com>
|
||||
Daniel Hokka Zakrisson <daniel@hozac.com>
|
||||
Dan Wendlandt <dan@nicira.com>
|
||||
David Lively <dlively@virtualiron.com>
|
||||
David Lutterkort <dlutter@redhat.com>
|
||||
Evgeniy Sokolov <evg@openvz.org>
|
||||
Hugh Brock <hbrock@redhat.com>
|
||||
Itamar Heim <iheim@redhat.com>
|
||||
James Morris <jmorris@namei.org>
|
||||
Javier Fontan <jfontan@gmail.com>
|
||||
Jeremy Katz <katzj@redhat.com>
|
||||
Kaitlin Rupert <kaitlin@linux.vnet.ibm.com>
|
||||
Kazuki Mizushima <mizushima.kazuk@jp.fujitsu.com>
|
||||
Mads Chr. Olesen <shiyee@shiyee.dk>
|
||||
Mark Johnson <johnson.nh@gmail.com>
|
||||
Markus Armbruster <armbru@redhat.com>
|
||||
Masayuki Sunou <fj1826dm@aa.jp.fujitsu.com>
|
||||
Matthias Witte <witte@netzquadrat.de>
|
||||
Michel Ponceau <michel.ponceau@bull.net>
|
||||
Nobuhiro Itou <fj0873gn@aa.jp.fujitsu.com>
|
||||
Pete Vetere <pvetere@redhat.com>
|
||||
Philippe Berthault <philippe.berthault@Bull.net>
|
||||
Saori Fukuta <fukuta.saori@jp.fujitsu.com>
|
||||
Shigeki Sakamoto <fj0588di@aa.jp.fujitsu.com>
|
||||
Shuveb Hussain <shuveb@binarykarma.com>
|
||||
Stefan de Konink <dekonink@kinkrsoftware.nl>
|
||||
Takahashi Tomohiro <takatom@jp.fujitsu.com>
|
||||
Tatsuro Enokura <fj7716hz@aa.jp.fujitsu.com>
|
||||
|
||||
#contributorslist#
|
||||
|
||||
The libvirt logo was designed by Diana Fong
|
||||
|
||||
-- End
|
||||
;; Local Variables:
|
||||
;; coding: utf-8
|
||||
;; End:
|
||||
@@ -1,46 +0,0 @@
|
||||
=======================
|
||||
Contributing to libvirt
|
||||
=======================
|
||||
|
||||
Full, up to date information on how to contribute to libvirt can be
|
||||
found on the libvirt website:
|
||||
|
||||
https://libvirt.org/contribute.html
|
||||
|
||||
To build the same document locally, from the top level directory of
|
||||
your git clone run:
|
||||
|
||||
::
|
||||
|
||||
$ mkdir build && cd build
|
||||
$ ../autogen.sh
|
||||
$ make
|
||||
|
||||
You'll find the freshly-built document in ``docs/contribute.html``.
|
||||
|
||||
If ``configure`` fails because of missing dependencies, you can set
|
||||
up your system by calling
|
||||
|
||||
::
|
||||
|
||||
$ sudo dnf builddep libvirt
|
||||
|
||||
if you're on a RHEL-based distribution or
|
||||
|
||||
::
|
||||
|
||||
$ sudo apt-get build-dep libvirt
|
||||
|
||||
if you're on a Debian-based one.
|
||||
|
||||
Note that, for the RHEL-based case, if you're on a machine where you
|
||||
haven't done any C development before, you will probably also need
|
||||
to run
|
||||
|
||||
::
|
||||
|
||||
$ sudo dnf install gcc make libtool autoconf automake rpm-build
|
||||
|
||||
You might still be missing some dependencies if your distribution is
|
||||
shipping an old libvirt version, but that will get you much closer to
|
||||
where you need to be to build successfully from source.
|
||||
339
COPYING
339
COPYING
@@ -1,339 +0,0 @@
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Lesser General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it
|
||||
in new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software, and
|
||||
(2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program", below,
|
||||
refers to any such program or work, and a "work based on the Program"
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term "modification".) Each licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running the Program is not restricted, and the output from the Program
|
||||
is covered only if its contents constitute a work based on the
|
||||
Program (independent of having been made by running the Program).
|
||||
Whether that is true depends on what the Program does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any warranty;
|
||||
and give any other recipients of the Program a copy of this License
|
||||
along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy, and
|
||||
you may at your option offer warranty protection in exchange for a fee.
|
||||
|
||||
2. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b) You must cause any work that you distribute or publish, that in
|
||||
whole or in part contains or is derived from the Program or any
|
||||
part thereof, to be licensed as a whole at no charge to all third
|
||||
parties under the terms of this License.
|
||||
|
||||
c) If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display an
|
||||
announcement including an appropriate copyright notice and a
|
||||
notice that there is no warranty (or else, saying that you provide
|
||||
a warranty) and that users may redistribute the program under
|
||||
these conditions, and telling the user how to view a copy of this
|
||||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Program, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Program
|
||||
with the Program (or with a work based on the Program) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms of
|
||||
Sections 1 and 2 above provided that you also do one of the following:
|
||||
|
||||
a) Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of Sections
|
||||
1 and 2 above on a medium customarily used for software interchange; or,
|
||||
|
||||
b) Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a medium
|
||||
customarily used for software interchange; or,
|
||||
|
||||
c) Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with such
|
||||
an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete source
|
||||
code means all the source code for all modules it contains, plus any
|
||||
associated interface definition files, plus the scripts used to
|
||||
control compilation and installation of the executable. However, as a
|
||||
special exception, the source code distributed need not include
|
||||
anything that is normally distributed (in either source or binary
|
||||
form) with the major components (compiler, kernel, and so on) of the
|
||||
operating system on which the executable runs, unless that component
|
||||
itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this License.
|
||||
However, parties who have received copies, or rights, from you under
|
||||
this License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
5. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Program or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Program (or any work based on the
|
||||
Program), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Program or works based on it.
|
||||
|
||||
6. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program subject to
|
||||
these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties to
|
||||
this License.
|
||||
|
||||
7. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Program at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Program by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under
|
||||
any particular circumstance, the balance of the section is intended to
|
||||
apply and the section as a whole is intended to apply in other
|
||||
circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
may add an explicit geographical distribution limitation excluding
|
||||
those countries, so that distribution is permitted only in or among
|
||||
countries not thus excluded. In such case, this License incorporates
|
||||
the limitation as if written in the body of this License.
|
||||
|
||||
9. The Free Software Foundation may publish revised and/or new versions
|
||||
of the General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and "any
|
||||
later version", you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
Foundation.
|
||||
|
||||
10. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the author
|
||||
to ask for permission. For software which is copyrighted by the Free
|
||||
Software Foundation, write to the Free Software Foundation; we sometimes
|
||||
make exceptions for this. Our decision will be guided by the two goals
|
||||
of preserving the free status of all derivatives of our free software and
|
||||
of promoting the sharing and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License along
|
||||
with this program; if not, write to the Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like this
|
||||
when it starts in an interactive mode:
|
||||
|
||||
Gnomovision version 69, Copyright (C) year name of author
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, the commands you use may
|
||||
be called something other than `show w' and `show c'; they could even be
|
||||
mouse-clicks or menu items--whatever suits your program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a "copyright disclaimer" for the program, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
|
||||
`Gnomovision' (which makes passes at compilers) written by James Hacker.
|
||||
|
||||
<signature of Ty Coon>, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
|
||||
This General Public License does not permit incorporating your program into
|
||||
proprietary programs. If your program is a subroutine library, you may
|
||||
consider it more useful to permit linking proprietary applications with the
|
||||
library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License.
|
||||
502
COPYING.LESSER
502
COPYING.LESSER
@@ -1,502 +0,0 @@
|
||||
GNU LESSER GENERAL PUBLIC LICENSE
|
||||
Version 2.1, February 1999
|
||||
|
||||
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
[This is the first released version of the Lesser GPL. It also counts
|
||||
as the successor of the GNU Library Public License, version 2, hence
|
||||
the version number 2.1.]
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
Licenses are intended to guarantee your freedom to share and change
|
||||
free software--to make sure the software is free for all its users.
|
||||
|
||||
This license, the Lesser General Public License, applies to some
|
||||
specially designated software packages--typically libraries--of the
|
||||
Free Software Foundation and other authors who decide to use it. You
|
||||
can use it too, but we suggest you first think carefully about whether
|
||||
this license or the ordinary General Public License is the better
|
||||
strategy to use in any particular case, based on the explanations below.
|
||||
|
||||
When we speak of free software, we are referring to freedom of use,
|
||||
not price. Our General Public Licenses are designed to make sure that
|
||||
you have the freedom to distribute copies of free software (and charge
|
||||
for this service if you wish); that you receive source code or can get
|
||||
it if you want it; that you can change the software and use pieces of
|
||||
it in new free programs; and that you are informed that you can do
|
||||
these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
distributors to deny you these rights or to ask you to surrender these
|
||||
rights. These restrictions translate to certain responsibilities for
|
||||
you if you distribute copies of the library or if you modify it.
|
||||
|
||||
For example, if you distribute copies of the library, whether gratis
|
||||
or for a fee, you must give the recipients all the rights that we gave
|
||||
you. You must make sure that they, too, receive or can get the source
|
||||
code. If you link other code with the library, you must provide
|
||||
complete object files to the recipients, so that they can relink them
|
||||
with the library after making changes to the library and recompiling
|
||||
it. And you must show them these terms so they know their rights.
|
||||
|
||||
We protect your rights with a two-step method: (1) we copyright the
|
||||
library, and (2) we offer you this license, which gives you legal
|
||||
permission to copy, distribute and/or modify the library.
|
||||
|
||||
To protect each distributor, we want to make it very clear that
|
||||
there is no warranty for the free library. Also, if the library is
|
||||
modified by someone else and passed on, the recipients should know
|
||||
that what they have is not the original version, so that the original
|
||||
author's reputation will not be affected by problems that might be
|
||||
introduced by others.
|
||||
|
||||
Finally, software patents pose a constant threat to the existence of
|
||||
any free program. We wish to make sure that a company cannot
|
||||
effectively restrict the users of a free program by obtaining a
|
||||
restrictive license from a patent holder. Therefore, we insist that
|
||||
any patent license obtained for a version of the library must be
|
||||
consistent with the full freedom of use specified in this license.
|
||||
|
||||
Most GNU software, including some libraries, is covered by the
|
||||
ordinary GNU General Public License. This license, the GNU Lesser
|
||||
General Public License, applies to certain designated libraries, and
|
||||
is quite different from the ordinary General Public License. We use
|
||||
this license for certain libraries in order to permit linking those
|
||||
libraries into non-free programs.
|
||||
|
||||
When a program is linked with a library, whether statically or using
|
||||
a shared library, the combination of the two is legally speaking a
|
||||
combined work, a derivative of the original library. The ordinary
|
||||
General Public License therefore permits such linking only if the
|
||||
entire combination fits its criteria of freedom. The Lesser General
|
||||
Public License permits more lax criteria for linking other code with
|
||||
the library.
|
||||
|
||||
We call this license the "Lesser" General Public License because it
|
||||
does Less to protect the user's freedom than the ordinary General
|
||||
Public License. It also provides other free software developers Less
|
||||
of an advantage over competing non-free programs. These disadvantages
|
||||
are the reason we use the ordinary General Public License for many
|
||||
libraries. However, the Lesser license provides advantages in certain
|
||||
special circumstances.
|
||||
|
||||
For example, on rare occasions, there may be a special need to
|
||||
encourage the widest possible use of a certain library, so that it becomes
|
||||
a de-facto standard. To achieve this, non-free programs must be
|
||||
allowed to use the library. A more frequent case is that a free
|
||||
library does the same job as widely used non-free libraries. In this
|
||||
case, there is little to gain by limiting the free library to free
|
||||
software only, so we use the Lesser General Public License.
|
||||
|
||||
In other cases, permission to use a particular library in non-free
|
||||
programs enables a greater number of people to use a large body of
|
||||
free software. For example, permission to use the GNU C Library in
|
||||
non-free programs enables many more people to use the whole GNU
|
||||
operating system, as well as its variant, the GNU/Linux operating
|
||||
system.
|
||||
|
||||
Although the Lesser General Public License is Less protective of the
|
||||
users' freedom, it does ensure that the user of a program that is
|
||||
linked with the Library has the freedom and the wherewithal to run
|
||||
that program using a modified version of the Library.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow. Pay close attention to the difference between a
|
||||
"work based on the library" and a "work that uses the library". The
|
||||
former contains code derived from the library, whereas the latter must
|
||||
be combined with the library in order to run.
|
||||
|
||||
GNU LESSER GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License Agreement applies to any software library or other
|
||||
program which contains a notice placed by the copyright holder or
|
||||
other authorized party saying it may be distributed under the terms of
|
||||
this Lesser General Public License (also called "this License").
|
||||
Each licensee is addressed as "you".
|
||||
|
||||
A "library" means a collection of software functions and/or data
|
||||
prepared so as to be conveniently linked with application programs
|
||||
(which use some of those functions and data) to form executables.
|
||||
|
||||
The "Library", below, refers to any such software library or work
|
||||
which has been distributed under these terms. A "work based on the
|
||||
Library" means either the Library or any derivative work under
|
||||
copyright law: that is to say, a work containing the Library or a
|
||||
portion of it, either verbatim or with modifications and/or translated
|
||||
straightforwardly into another language. (Hereinafter, translation is
|
||||
included without limitation in the term "modification".)
|
||||
|
||||
"Source code" for a work means the preferred form of the work for
|
||||
making modifications to it. For a library, complete source code means
|
||||
all the source code for all modules it contains, plus any associated
|
||||
interface definition files, plus the scripts used to control compilation
|
||||
and installation of the library.
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running a program using the Library is not restricted, and output from
|
||||
such a program is covered only if its contents constitute a work based
|
||||
on the Library (independent of the use of the Library in a tool for
|
||||
writing it). Whether that is true depends on what the Library does
|
||||
and what the program that uses the Library does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Library's
|
||||
complete source code as you receive it, in any medium, provided that
|
||||
you conspicuously and appropriately publish on each copy an
|
||||
appropriate copyright notice and disclaimer of warranty; keep intact
|
||||
all the notices that refer to this License and to the absence of any
|
||||
warranty; and distribute a copy of this License along with the
|
||||
Library.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy,
|
||||
and you may at your option offer warranty protection in exchange for a
|
||||
fee.
|
||||
|
||||
2. You may modify your copy or copies of the Library or any portion
|
||||
of it, thus forming a work based on the Library, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) The modified work must itself be a software library.
|
||||
|
||||
b) You must cause the files modified to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
c) You must cause the whole of the work to be licensed at no
|
||||
charge to all third parties under the terms of this License.
|
||||
|
||||
d) If a facility in the modified Library refers to a function or a
|
||||
table of data to be supplied by an application program that uses
|
||||
the facility, other than as an argument passed when the facility
|
||||
is invoked, then you must make a good faith effort to ensure that,
|
||||
in the event an application does not supply such function or
|
||||
table, the facility still operates, and performs whatever part of
|
||||
its purpose remains meaningful.
|
||||
|
||||
(For example, a function in a library to compute square roots has
|
||||
a purpose that is entirely well-defined independent of the
|
||||
application. Therefore, Subsection 2d requires that any
|
||||
application-supplied function or table used by this function must
|
||||
be optional: if the application does not supply it, the square
|
||||
root function must still compute square roots.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Library,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Library, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote
|
||||
it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Library.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Library
|
||||
with the Library (or with a work based on the Library) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may opt to apply the terms of the ordinary GNU General Public
|
||||
License instead of this License to a given copy of the Library. To do
|
||||
this, you must alter all the notices that refer to this License, so
|
||||
that they refer to the ordinary GNU General Public License, version 2,
|
||||
instead of to this License. (If a newer version than version 2 of the
|
||||
ordinary GNU General Public License has appeared, then you can specify
|
||||
that version instead if you wish.) Do not make any other change in
|
||||
these notices.
|
||||
|
||||
Once this change is made in a given copy, it is irreversible for
|
||||
that copy, so the ordinary GNU General Public License applies to all
|
||||
subsequent copies and derivative works made from that copy.
|
||||
|
||||
This option is useful when you wish to copy part of the code of
|
||||
the Library into a program that is not a library.
|
||||
|
||||
4. You may copy and distribute the Library (or a portion or
|
||||
derivative of it, under Section 2) in object code or executable form
|
||||
under the terms of Sections 1 and 2 above provided that you accompany
|
||||
it with the complete corresponding machine-readable source code, which
|
||||
must be distributed under the terms of Sections 1 and 2 above on a
|
||||
medium customarily used for software interchange.
|
||||
|
||||
If distribution of object code is made by offering access to copy
|
||||
from a designated place, then offering equivalent access to copy the
|
||||
source code from the same place satisfies the requirement to
|
||||
distribute the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
5. A program that contains no derivative of any portion of the
|
||||
Library, but is designed to work with the Library by being compiled or
|
||||
linked with it, is called a "work that uses the Library". Such a
|
||||
work, in isolation, is not a derivative work of the Library, and
|
||||
therefore falls outside the scope of this License.
|
||||
|
||||
However, linking a "work that uses the Library" with the Library
|
||||
creates an executable that is a derivative of the Library (because it
|
||||
contains portions of the Library), rather than a "work that uses the
|
||||
library". The executable is therefore covered by this License.
|
||||
Section 6 states terms for distribution of such executables.
|
||||
|
||||
When a "work that uses the Library" uses material from a header file
|
||||
that is part of the Library, the object code for the work may be a
|
||||
derivative work of the Library even though the source code is not.
|
||||
Whether this is true is especially significant if the work can be
|
||||
linked without the Library, or if the work is itself a library. The
|
||||
threshold for this to be true is not precisely defined by law.
|
||||
|
||||
If such an object file uses only numerical parameters, data
|
||||
structure layouts and accessors, and small macros and small inline
|
||||
functions (ten lines or less in length), then the use of the object
|
||||
file is unrestricted, regardless of whether it is legally a derivative
|
||||
work. (Executables containing this object code plus portions of the
|
||||
Library will still fall under Section 6.)
|
||||
|
||||
Otherwise, if the work is a derivative of the Library, you may
|
||||
distribute the object code for the work under the terms of Section 6.
|
||||
Any executables containing that work also fall under Section 6,
|
||||
whether or not they are linked directly with the Library itself.
|
||||
|
||||
6. As an exception to the Sections above, you may also combine or
|
||||
link a "work that uses the Library" with the Library to produce a
|
||||
work containing portions of the Library, and distribute that work
|
||||
under terms of your choice, provided that the terms permit
|
||||
modification of the work for the customer's own use and reverse
|
||||
engineering for debugging such modifications.
|
||||
|
||||
You must give prominent notice with each copy of the work that the
|
||||
Library is used in it and that the Library and its use are covered by
|
||||
this License. You must supply a copy of this License. If the work
|
||||
during execution displays copyright notices, you must include the
|
||||
copyright notice for the Library among them, as well as a reference
|
||||
directing the user to the copy of this License. Also, you must do one
|
||||
of these things:
|
||||
|
||||
a) Accompany the work with the complete corresponding
|
||||
machine-readable source code for the Library including whatever
|
||||
changes were used in the work (which must be distributed under
|
||||
Sections 1 and 2 above); and, if the work is an executable linked
|
||||
with the Library, with the complete machine-readable "work that
|
||||
uses the Library", as object code and/or source code, so that the
|
||||
user can modify the Library and then relink to produce a modified
|
||||
executable containing the modified Library. (It is understood
|
||||
that the user who changes the contents of definitions files in the
|
||||
Library will not necessarily be able to recompile the application
|
||||
to use the modified definitions.)
|
||||
|
||||
b) Use a suitable shared library mechanism for linking with the
|
||||
Library. A suitable mechanism is one that (1) uses at run time a
|
||||
copy of the library already present on the user's computer system,
|
||||
rather than copying library functions into the executable, and (2)
|
||||
will operate properly with a modified version of the library, if
|
||||
the user installs one, as long as the modified version is
|
||||
interface-compatible with the version that the work was made with.
|
||||
|
||||
c) Accompany the work with a written offer, valid for at
|
||||
least three years, to give the same user the materials
|
||||
specified in Subsection 6a, above, for a charge no more
|
||||
than the cost of performing this distribution.
|
||||
|
||||
d) If distribution of the work is made by offering access to copy
|
||||
from a designated place, offer equivalent access to copy the above
|
||||
specified materials from the same place.
|
||||
|
||||
e) Verify that the user has already received a copy of these
|
||||
materials or that you have already sent this user a copy.
|
||||
|
||||
For an executable, the required form of the "work that uses the
|
||||
Library" must include any data and utility programs needed for
|
||||
reproducing the executable from it. However, as a special exception,
|
||||
the materials to be distributed need not include anything that is
|
||||
normally distributed (in either source or binary form) with the major
|
||||
components (compiler, kernel, and so on) of the operating system on
|
||||
which the executable runs, unless that component itself accompanies
|
||||
the executable.
|
||||
|
||||
It may happen that this requirement contradicts the license
|
||||
restrictions of other proprietary libraries that do not normally
|
||||
accompany the operating system. Such a contradiction means you cannot
|
||||
use both them and the Library together in an executable that you
|
||||
distribute.
|
||||
|
||||
7. You may place library facilities that are a work based on the
|
||||
Library side-by-side in a single library together with other library
|
||||
facilities not covered by this License, and distribute such a combined
|
||||
library, provided that the separate distribution of the work based on
|
||||
the Library and of the other library facilities is otherwise
|
||||
permitted, and provided that you do these two things:
|
||||
|
||||
a) Accompany the combined library with a copy of the same work
|
||||
based on the Library, uncombined with any other library
|
||||
facilities. This must be distributed under the terms of the
|
||||
Sections above.
|
||||
|
||||
b) Give prominent notice with the combined library of the fact
|
||||
that part of it is a work based on the Library, and explaining
|
||||
where to find the accompanying uncombined form of the same work.
|
||||
|
||||
8. You may not copy, modify, sublicense, link with, or distribute
|
||||
the Library except as expressly provided under this License. Any
|
||||
attempt otherwise to copy, modify, sublicense, link with, or
|
||||
distribute the Library is void, and will automatically terminate your
|
||||
rights under this License. However, parties who have received copies,
|
||||
or rights, from you under this License will not have their licenses
|
||||
terminated so long as such parties remain in full compliance.
|
||||
|
||||
9. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Library or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Library (or any work based on the
|
||||
Library), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Library or works based on it.
|
||||
|
||||
10. Each time you redistribute the Library (or any work based on the
|
||||
Library), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute, link with or modify the Library
|
||||
subject to these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties with
|
||||
this License.
|
||||
|
||||
11. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Library at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Library by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Library.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under any
|
||||
particular circumstance, the balance of the section is intended to apply,
|
||||
and the section as a whole is intended to apply in other circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
12. If the distribution and/or use of the Library is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Library under this License may add
|
||||
an explicit geographical distribution limitation excluding those countries,
|
||||
so that distribution is permitted only in or among countries not thus
|
||||
excluded. In such case, this License incorporates the limitation as if
|
||||
written in the body of this License.
|
||||
|
||||
13. The Free Software Foundation may publish revised and/or new
|
||||
versions of the Lesser General Public License from time to time.
|
||||
Such new versions will be similar in spirit to the present version,
|
||||
but may differ in detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Library
|
||||
specifies a version number of this License which applies to it and
|
||||
"any later version", you have the option of following the terms and
|
||||
conditions either of that version or of any later version published by
|
||||
the Free Software Foundation. If the Library does not specify a
|
||||
license version number, you may choose any version ever published by
|
||||
the Free Software Foundation.
|
||||
|
||||
14. If you wish to incorporate parts of the Library into other free
|
||||
programs whose distribution conditions are incompatible with these,
|
||||
write to the author to ask for permission. For software which is
|
||||
copyrighted by the Free Software Foundation, write to the Free
|
||||
Software Foundation; we sometimes make exceptions for this. Our
|
||||
decision will be guided by the two goals of preserving the free status
|
||||
of all derivatives of our free software and of promoting the sharing
|
||||
and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
|
||||
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
|
||||
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
|
||||
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
|
||||
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
|
||||
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
|
||||
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
|
||||
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
|
||||
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
|
||||
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
|
||||
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
|
||||
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
|
||||
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
|
||||
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
|
||||
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
|
||||
DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Libraries
|
||||
|
||||
If you develop a new library, and you want it to be of the greatest
|
||||
possible use to the public, we recommend making it free software that
|
||||
everyone can redistribute and change. You can do so by permitting
|
||||
redistribution under these terms (or, alternatively, under the terms of the
|
||||
ordinary General Public License).
|
||||
|
||||
To apply these terms, attach the following notices to the library. It is
|
||||
safest to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least the
|
||||
"copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the library's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This library is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU Lesser General Public
|
||||
License as published by the Free Software Foundation; either
|
||||
version 2.1 of the License, or (at your option) any later version.
|
||||
|
||||
This library is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
Lesser General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU Lesser General Public
|
||||
License along with this library; if not, write to the Free Software
|
||||
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a "copyright disclaimer" for the library, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
Yoyodyne, Inc., hereby disclaims all copyright interest in the
|
||||
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
|
||||
|
||||
<signature of Ty Coon>, 1 April 1990
|
||||
Ty Coon, President of Vice
|
||||
|
||||
That's all there is to it!
|
||||
15
ChangeLog
15
ChangeLog
@@ -1,15 +0,0 @@
|
||||
libvirt ChangeLog
|
||||
=================
|
||||
|
||||
The libvirt project doesn't include a detailed ChangeLog in its release
|
||||
archives.
|
||||
|
||||
If you're interested in the full list of changes made to libvirt since
|
||||
the project was started, you can clone the git repository from
|
||||
|
||||
https://libvirt.org/git/libvirt.git
|
||||
|
||||
and browse them locally using your favorite git history viewer or,
|
||||
alternatively, browse them online at
|
||||
|
||||
https://libvirt.org/git/?p=libvirt.git;a=log
|
||||
74
GNUmakefile
74
GNUmakefile
@@ -1,74 +0,0 @@
|
||||
# Having a separate GNUmakefile lets me 'include' the dynamically
|
||||
# generated rules created via cfg.mk (package-local configuration)
|
||||
# as well as maint.mk (generic maintainer rules).
|
||||
# This makefile is used only if you run GNU Make.
|
||||
# It is necessary if you want to build targets usually of interest
|
||||
# only to the maintainer.
|
||||
|
||||
# Copyright (C) 2001, 2003, 2006-2019 Free Software Foundation, Inc.
|
||||
|
||||
# This program is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
_build-aux ?= build-aux
|
||||
_autoreconf ?= autoreconf -v
|
||||
|
||||
# If the user runs GNU make but has not yet run ./configure,
|
||||
# give them a diagnostic.
|
||||
_gl-Makefile := $(wildcard [M]akefile)
|
||||
ifneq ($(_gl-Makefile),)
|
||||
|
||||
# Make tar archive easier to reproduce.
|
||||
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
|
||||
|
||||
# Allow the user to add to this in the Makefile.
|
||||
ALL_RECURSIVE_TARGETS =
|
||||
|
||||
include Makefile
|
||||
include $(srcdir)/$(_build-aux)/syntax-check.mk
|
||||
|
||||
else
|
||||
|
||||
.DEFAULT_GOAL := abort-due-to-no-makefile
|
||||
srcdir = .
|
||||
|
||||
# The package can override .DEFAULT_GOAL to run actions like autoreconf.
|
||||
include $(srcdir)/$(_build-aux)/syntax-check.mk
|
||||
|
||||
ifeq ($(.DEFAULT_GOAL),abort-due-to-no-makefile)
|
||||
$(MAKECMDGOALS): abort-due-to-no-makefile
|
||||
endif
|
||||
|
||||
abort-due-to-no-makefile:
|
||||
@echo There seems to be no Makefile in this directory. 1>&2
|
||||
@echo "You must run ./configure before running 'make'." 1>&2
|
||||
@exit 1
|
||||
|
||||
endif
|
||||
|
||||
# Tell version 3.79 and up of GNU make to not build goals in this
|
||||
# directory in parallel, in case someone tries to build multiple
|
||||
# targets, and one of them can cause a recursive target to be invoked.
|
||||
|
||||
# Only set this if Automake doesn't provide it.
|
||||
AM_RECURSIVE_TARGETS ?= $(RECURSIVE_TARGETS:-recursive=) \
|
||||
$(RECURSIVE_CLEAN_TARGETS:-recursive=) \
|
||||
dist distcheck tags ctags
|
||||
|
||||
ALL_RECURSIVE_TARGETS += $(AM_RECURSIVE_TARGETS)
|
||||
|
||||
ifneq ($(word 2, $(MAKECMDGOALS)), )
|
||||
ifneq ($(filter $(ALL_RECURSIVE_TARGETS), $(MAKECMDGOALS)), )
|
||||
.NOTPARALLEL:
|
||||
endif
|
||||
endif
|
||||
201
Makefile.am
201
Makefile.am
@@ -1,201 +0,0 @@
|
||||
## Process this file with automake to produce Makefile.in
|
||||
|
||||
## Copyright (C) 2005-2013 Red Hat, Inc.
|
||||
##
|
||||
## This library is free software; you can redistribute it and/or
|
||||
## modify it under the terms of the GNU Lesser General Public
|
||||
## License as published by the Free Software Foundation; either
|
||||
## version 2.1 of the License, or (at your option) any later version.
|
||||
##
|
||||
## This library is distributed in the hope that it will be useful,
|
||||
## but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
## Lesser General Public License for more details.
|
||||
##
|
||||
## You should have received a copy of the GNU Lesser General Public
|
||||
## License along with this library. If not, see
|
||||
## <http://www.gnu.org/licenses/>.
|
||||
|
||||
LCOV = lcov
|
||||
GENHTML = genhtml
|
||||
|
||||
# when building from tarball -Werror isn't auto enabled
|
||||
# so force it explicitly
|
||||
DISTCHECK_CONFIGURE_FLAGS = --enable-werror
|
||||
|
||||
SUBDIRS = . include/libvirt src tools docs \
|
||||
tests po examples
|
||||
|
||||
XZ_OPT ?= -v -T0
|
||||
export XZ_OPT
|
||||
|
||||
ACLOCAL_AMFLAGS = -I m4
|
||||
|
||||
EXTRA_DIST = \
|
||||
config-post.h \
|
||||
libvirt.spec libvirt.spec.in \
|
||||
mingw-libvirt.spec.in \
|
||||
libvirt.pc.in \
|
||||
libvirt-qemu.pc.in \
|
||||
libvirt-lxc.pc.in \
|
||||
libvirt-admin.pc.in \
|
||||
Makefile.nonreentrant \
|
||||
autogen.sh \
|
||||
GNUmakefile \
|
||||
run.in \
|
||||
README.rst \
|
||||
AUTHORS.in \
|
||||
CONTRIBUTING.rst \
|
||||
scripts/apibuild.py \
|
||||
scripts/augeas-gentest.py \
|
||||
build-aux/check-spacing.pl \
|
||||
scripts/check-aclperms.py \
|
||||
scripts/check-aclrules.py \
|
||||
scripts/check-drivername.py \
|
||||
scripts/check-driverimpls.py \
|
||||
scripts/check-file-access.py \
|
||||
scripts/check-remote-protocol.py \
|
||||
scripts/check-symfile.py \
|
||||
scripts/check-symsorting.py \
|
||||
scripts/dtrace2systemtap.py \
|
||||
scripts/esx_vi_generator.py \
|
||||
scripts/genaclperms.py \
|
||||
scripts/genpolkit.py \
|
||||
scripts/gensystemtap.py \
|
||||
scripts/group-qemu-caps.py \
|
||||
scripts/header-ifdef.py \
|
||||
scripts/hvsupport.py \
|
||||
scripts/hyperv_wmi_generator.py \
|
||||
scripts/minimize-po.py \
|
||||
scripts/mock-noinline.py \
|
||||
scripts/prohibit-duplicate-header.py \
|
||||
scripts/reformat-news.py \
|
||||
scripts/test-wrap-argv.py \
|
||||
build-aux/syntax-check.mk \
|
||||
build-aux/useless-if-before-free \
|
||||
build-aux/vc-list-files \
|
||||
ci/Makefile \
|
||||
ci/build.sh \
|
||||
ci/list-images.sh \
|
||||
ci/prepare.sh \
|
||||
$(NULL)
|
||||
|
||||
pkgconfigdir = $(libdir)/pkgconfig
|
||||
pkgconfig_DATA = libvirt.pc libvirt-qemu.pc libvirt-lxc.pc libvirt-admin.pc
|
||||
|
||||
NEWS: \
|
||||
$(srcdir)/docs/news.xml \
|
||||
$(srcdir)/docs/news-ascii.xsl \
|
||||
$(top_srcdir)/scripts/reformat-news.py
|
||||
$(AM_V_GEN) \
|
||||
if [ -x $(XSLTPROC) ]; then \
|
||||
$(XSLTPROC) --nonet \
|
||||
$(srcdir)/docs/news-ascii.xsl \
|
||||
$(srcdir)/docs/news.xml \
|
||||
>$@-tmp \
|
||||
|| { rm -f $@-tmp; exit 1; }; \
|
||||
$(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/reformat-news.py $@-tmp >$@ \
|
||||
|| { rm -f $@-tmp; exit 1; }; \
|
||||
rm -f $@-tmp; \
|
||||
fi
|
||||
EXTRA_DIST += \
|
||||
$(srcdir)/docs/news.xml \
|
||||
$(srcdir)/docs/news-ascii.xsl \
|
||||
$(NULL)
|
||||
|
||||
rpm: clean
|
||||
@(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.xz)
|
||||
|
||||
srpm: clean
|
||||
@(unset CDPATH ; $(MAKE) dist && rpmbuild -ts $(distdir).tar.xz)
|
||||
|
||||
check-local: all tests
|
||||
|
||||
check-access: all
|
||||
@($(MAKE) $(AM_MAKEFLAGS) -C tests check-access)
|
||||
|
||||
cov: clean-cov
|
||||
$(MKDIR_P) $(top_builddir)/coverage
|
||||
$(LCOV) -c -o $(top_builddir)/coverage/libvirt.info.tmp \
|
||||
-d $(top_builddir)/src \
|
||||
-d $(top_builddir)/tests
|
||||
$(LCOV) -r $(top_builddir)/coverage/libvirt.info.tmp \
|
||||
-o $(top_builddir)/coverage/libvirt.info
|
||||
rm $(top_builddir)/coverage/libvirt.info.tmp
|
||||
$(GENHTML) --show-details -t "libvirt" -o $(top_builddir)/coverage \
|
||||
--legend $(top_builddir)/coverage/libvirt.info
|
||||
|
||||
clean-cov:
|
||||
rm -rf $(top_builddir)/coverage
|
||||
|
||||
MAINTAINERCLEANFILES = .git-module-status
|
||||
|
||||
BUILT_SOURCES = configmake.h
|
||||
CLEANFILES = configmake.h
|
||||
|
||||
distclean-local: clean-GNUmakefile
|
||||
clean-GNUmakefile:
|
||||
test '$(srcdir)' = . || rm -f $(top_builddir)/GNUmakefile
|
||||
|
||||
dist-hook: gen-AUTHORS
|
||||
|
||||
.PHONY: gen-AUTHORS
|
||||
gen-AUTHORS:
|
||||
$(AM_V_GEN)\
|
||||
if test -d $(srcdir)/.git; then \
|
||||
( \
|
||||
cd $(srcdir) && \
|
||||
git log --pretty=format:'%aN <%aE>' | sort -u \
|
||||
) > all.list && \
|
||||
sort -u $(srcdir)/AUTHORS.in > maint.list && \
|
||||
comm -23 all.list maint.list > contrib.list && \
|
||||
contrib="`cat contrib.list`" && \
|
||||
perl -p -e "s/#contributorslist#// and print '$$contrib'" \
|
||||
< $(srcdir)/AUTHORS.in > $(distdir)/AUTHORS-tmp && \
|
||||
mv -f $(distdir)/AUTHORS-tmp $(distdir)/AUTHORS && \
|
||||
rm -f all.list maint.list contrib.list; \
|
||||
fi
|
||||
|
||||
ci-%:
|
||||
$(MAKE) -C $(srcdir)/ci/ $@
|
||||
|
||||
# Listed in the same order as the GNU makefile conventions, and
|
||||
# provided by autoconf 2.59c+ or 2.70.
|
||||
# The Automake-defined pkg* macros are appended, in the order
|
||||
# listed in the Automake 1.10a+ documentation.
|
||||
configmake.h: Makefile
|
||||
$(AM_V_GEN)rm -f $@-t && \
|
||||
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
|
||||
echo '#if WIN32'; \
|
||||
echo '# include <winsock2.h> /* avoid mingw pollution on DATADIR */'; \
|
||||
echo '#endif'; \
|
||||
echo '#define PREFIX "$(prefix)"'; \
|
||||
echo '#define EXEC_PREFIX "$(exec_prefix)"'; \
|
||||
echo '#define BINDIR "$(bindir)"'; \
|
||||
echo '#define SBINDIR "$(sbindir)"'; \
|
||||
echo '#define LIBEXECDIR "$(libexecdir)"'; \
|
||||
echo '#define DATAROOTDIR "$(datarootdir)"'; \
|
||||
echo '#define DATADIR "$(datadir)"'; \
|
||||
echo '#define SYSCONFDIR "$(sysconfdir)"'; \
|
||||
echo '#define SHAREDSTATEDIR "$(sharedstatedir)"'; \
|
||||
echo '#define LOCALSTATEDIR "$(localstatedir)"'; \
|
||||
echo '#define RUNSTATEDIR "$(runstatedir)"'; \
|
||||
echo '#define INCLUDEDIR "$(includedir)"'; \
|
||||
echo '#define OLDINCLUDEDIR "$(oldincludedir)"'; \
|
||||
echo '#define DOCDIR "$(docdir)"'; \
|
||||
echo '#define INFODIR "$(infodir)"'; \
|
||||
echo '#define HTMLDIR "$(htmldir)"'; \
|
||||
echo '#define DVIDIR "$(dvidir)"'; \
|
||||
echo '#define PDFDIR "$(pdfdir)"'; \
|
||||
echo '#define PSDIR "$(psdir)"'; \
|
||||
echo '#define LIBDIR "$(libdir)"'; \
|
||||
echo '#define LISPDIR "$(lispdir)"'; \
|
||||
echo '#define LOCALEDIR "$(localedir)"'; \
|
||||
echo '#define MANDIR "$(mandir)"'; \
|
||||
echo '#define MANEXT "$(manext)"'; \
|
||||
echo '#define PKGDATADIR "$(pkgdatadir)"'; \
|
||||
echo '#define PKGINCLUDEDIR "$(pkgincludedir)"'; \
|
||||
echo '#define PKGLIBDIR "$(pkglibdir)"'; \
|
||||
echo '#define PKGLIBEXECDIR "$(pkglibexecdir)"'; \
|
||||
} | sed '/""/d' > $@-t && \
|
||||
mv -f $@-t $@
|
||||
@@ -1,127 +0,0 @@
|
||||
## Copyright (C) 2009-2010, 2013 Red Hat, Inc.
|
||||
##
|
||||
## This library is free software; you can redistribute it and/or
|
||||
## modify it under the terms of the GNU Lesser General Public
|
||||
## License as published by the Free Software Foundation; either
|
||||
## version 2.1 of the License, or (at your option) any later version.
|
||||
##
|
||||
## This library is distributed in the hope that it will be useful,
|
||||
## but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
## Lesser General Public License for more details.
|
||||
##
|
||||
## You should have received a copy of the GNU Lesser General Public
|
||||
## License along with this library. If not, see
|
||||
## <http://www.gnu.org/licenses/>.
|
||||
|
||||
#
|
||||
# Generated by running the following on Fedora 26:
|
||||
#
|
||||
# nm -D --defined-only /lib64/libc.so.6 \
|
||||
# | grep '_r$' \
|
||||
# | awk '{print $3}' \
|
||||
# | grep -v __ \
|
||||
# | grep -v qsort \ # Red herring since we don't need to pass extra args to qsort comparator
|
||||
# | grep -v readdir \ # This is safe as long as each DIR * instance is only used by one thread
|
||||
# | sort \
|
||||
# | uniq \
|
||||
# | sed -e 's/_r//'
|
||||
#
|
||||
# Also manually add in all inet_* functions some of which
|
||||
# are not threadsafe and do not have _r variants. They are
|
||||
# all deprecated in favour of getnameinfo/getaddrinfo
|
||||
#
|
||||
|
||||
NON_REENTRANT =
|
||||
NON_REENTRANT += asctime
|
||||
NON_REENTRANT += ctime
|
||||
NON_REENTRANT += drand48
|
||||
NON_REENTRANT += ecvt
|
||||
NON_REENTRANT += erand48
|
||||
NON_REENTRANT += ether_aton
|
||||
NON_REENTRANT += ether_ntoa
|
||||
NON_REENTRANT += fcvt
|
||||
NON_REENTRANT += fgetgrent
|
||||
NON_REENTRANT += fgetpwent
|
||||
NON_REENTRANT += fgetsgent
|
||||
NON_REENTRANT += fgetspent
|
||||
NON_REENTRANT += getaliasbyname
|
||||
NON_REENTRANT += getaliasent
|
||||
NON_REENTRANT += getdate
|
||||
NON_REENTRANT += getgrent
|
||||
NON_REENTRANT += getgrgid
|
||||
NON_REENTRANT += getgrnam
|
||||
NON_REENTRANT += gethostbyaddr
|
||||
NON_REENTRANT += gethostbyname2
|
||||
NON_REENTRANT += gethostbyname
|
||||
NON_REENTRANT += gethostent
|
||||
NON_REENTRANT += getlogin
|
||||
NON_REENTRANT += getmntent
|
||||
NON_REENTRANT += getnetbyaddr
|
||||
NON_REENTRANT += getnetbyname
|
||||
NON_REENTRANT += getnetent
|
||||
NON_REENTRANT += getnetgrent
|
||||
NON_REENTRANT += getprotobyname
|
||||
NON_REENTRANT += getprotobynumber
|
||||
NON_REENTRANT += getprotoent
|
||||
NON_REENTRANT += getpwent
|
||||
NON_REENTRANT += getpwnam
|
||||
NON_REENTRANT += getpwuid
|
||||
NON_REENTRANT += getrpcbyname
|
||||
NON_REENTRANT += getrpcbynumber
|
||||
NON_REENTRANT += getrpcent
|
||||
NON_REENTRANT += getservbyname
|
||||
NON_REENTRANT += getservbyport
|
||||
NON_REENTRANT += getservent
|
||||
NON_REENTRANT += getsgent
|
||||
NON_REENTRANT += getsgnam
|
||||
NON_REENTRANT += getspent
|
||||
NON_REENTRANT += getspnam
|
||||
NON_REENTRANT += getutent
|
||||
NON_REENTRANT += getutid
|
||||
NON_REENTRANT += getutline
|
||||
NON_REENTRANT += gmtime
|
||||
NON_REENTRANT += hcreate
|
||||
NON_REENTRANT += hdestroy
|
||||
NON_REENTRANT += hsearch
|
||||
NON_REENTRANT += initstate
|
||||
NON_REENTRANT += jrand48
|
||||
NON_REENTRANT += lcong48
|
||||
NON_REENTRANT += localtime
|
||||
NON_REENTRANT += lrand48
|
||||
NON_REENTRANT += mrand48
|
||||
NON_REENTRANT += nrand48
|
||||
NON_REENTRANT += ptsname
|
||||
NON_REENTRANT += qecvt
|
||||
NON_REENTRANT += qfcvt
|
||||
NON_REENTRANT += random
|
||||
NON_REENTRANT += rand
|
||||
NON_REENTRANT += seed48
|
||||
NON_REENTRANT += setstate
|
||||
NON_REENTRANT += sgetsgent
|
||||
NON_REENTRANT += sgetspent
|
||||
NON_REENTRANT += srand48
|
||||
NON_REENTRANT += srandom
|
||||
NON_REENTRANT += strerror
|
||||
NON_REENTRANT += strtok
|
||||
NON_REENTRANT += tmpnam
|
||||
NON_REENTRANT += ttyname
|
||||
NON_REENTRANT += inet_addr
|
||||
NON_REENTRANT += inet_aton
|
||||
NON_REENTRANT += inet_lnaof
|
||||
NON_REENTRANT += inet_makeaddr
|
||||
NON_REENTRANT += inet_netof
|
||||
NON_REENTRANT += inet_network
|
||||
NON_REENTRANT += inet_nsap_addr
|
||||
NON_REENTRANT += inet_nsap_ntoa
|
||||
NON_REENTRANT += inet_ntoa
|
||||
NON_REENTRANT += inet_ntop
|
||||
NON_REENTRANT += inet_pton
|
||||
|
||||
# Separate two nothings by space to get one space in a variable
|
||||
space =
|
||||
space +=
|
||||
# The space needs to be in a variable otherwise it would be ignored.
|
||||
# And there must be no spaces around the commas because they would
|
||||
# not be ignored, logically.
|
||||
NON_REENTRANT_RE=$(subst $(space),|,$(NON_REENTRANT))
|
||||
72
README.rst
72
README.rst
@@ -1,72 +0,0 @@
|
||||
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt/pipelines
|
||||
:alt: GitLab CI Build Status
|
||||
.. image:: https://travis-ci.org/libvirt/libvirt.svg
|
||||
:target: https://travis-ci.org/libvirt/libvirt
|
||||
:alt: Travis CI Build Status
|
||||
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
|
||||
:target: https://bestpractices.coreinfrastructure.org/projects/355
|
||||
:alt: CII Best Practices
|
||||
|
||||
==============================
|
||||
Libvirt API for virtualization
|
||||
==============================
|
||||
|
||||
Libvirt provides a portable, long term stable C API for managing the
|
||||
virtualization technologies provided by many operating systems. It
|
||||
includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
|
||||
vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
|
||||
Hypervisor.
|
||||
|
||||
For some of these hypervisors, it provides a stateful management
|
||||
daemon which runs on the virtualization host allowing access to the
|
||||
API both by non-privileged local users and remote users.
|
||||
|
||||
Layered packages provide bindings of the libvirt C API into other
|
||||
languages including Python, Perl, PHP, Go, Java, OCaml, as well as
|
||||
mappings into object systems such as GObject, CIM and SNMP.
|
||||
|
||||
Further information about the libvirt project can be found on the
|
||||
website:
|
||||
|
||||
https://libvirt.org
|
||||
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
The libvirt C API is distributed under the terms of GNU Lesser General
|
||||
Public License, version 2.1 (or later). Some parts of the code that are
|
||||
not part of the C library may have the more restrictive GNU General
|
||||
Public License, version 2.0 (or later). See the files ``COPYING.LESSER``
|
||||
and ``COPYING`` for full license terms & conditions.
|
||||
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Instructions on building and installing libvirt can be found on the website:
|
||||
|
||||
https://libvirt.org/compiling.html
|
||||
|
||||
Contributing
|
||||
============
|
||||
|
||||
The libvirt project welcomes contributions in many ways. For most components
|
||||
the best way to contribute is to send patches to the primary development
|
||||
mailing list. Further guidance on this can be found on the website:
|
||||
|
||||
https://libvirt.org/contribute.html
|
||||
|
||||
|
||||
Contact
|
||||
=======
|
||||
|
||||
The libvirt project has two primary mailing lists:
|
||||
|
||||
* libvirt-users@redhat.com (**for user discussions**)
|
||||
* libvir-list@redhat.com (**for development only**)
|
||||
|
||||
Further details on contacting the project are available on the website:
|
||||
|
||||
https://libvirt.org/contact.html
|
||||
44
autogen.sh
44
autogen.sh
@@ -1,44 +0,0 @@
|
||||
#!/bin/sh
|
||||
# Run this to generate all the initial makefiles, etc.
|
||||
test -n "$srcdir" || srcdir=$(dirname "$0")
|
||||
test -n "$srcdir" || srcdir=.
|
||||
|
||||
olddir=$(pwd)
|
||||
|
||||
cd "$srcdir"
|
||||
|
||||
(test -f src/libvirt.c) || {
|
||||
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
|
||||
echo " top-level libvirt directory"
|
||||
exit 1
|
||||
}
|
||||
|
||||
git submodule update --init || exit 1
|
||||
|
||||
autoreconf --verbose --force --install || exit 1
|
||||
|
||||
if test "x$1" = "x--system"; then
|
||||
shift
|
||||
prefix=/usr
|
||||
libdir=$prefix/lib
|
||||
sysconfdir=/etc
|
||||
localstatedir=/var
|
||||
if [ -d /usr/lib64 ]; then
|
||||
libdir=$prefix/lib64
|
||||
fi
|
||||
EXTRA_ARGS="--prefix=$prefix --sysconfdir=$sysconfdir --localstatedir=$localstatedir --libdir=$libdir"
|
||||
fi
|
||||
|
||||
cd "$olddir"
|
||||
|
||||
if [ "$NOCONFIGURE" = "" ]; then
|
||||
$srcdir/configure $EXTRA_ARGS "$@" || exit 1
|
||||
|
||||
if [ "$1" = "--help" ]; then
|
||||
exit 0
|
||||
else
|
||||
echo "Now type 'make' to compile libvirt" || exit 1
|
||||
fi
|
||||
else
|
||||
echo "Skipping configure process."
|
||||
fi
|
||||
@@ -1,198 +0,0 @@
|
||||
#!/usr/bin/env perl
|
||||
#
|
||||
# check-spacing.pl: Report any usage of 'function (..args..)'
|
||||
# Also check for other syntax issues, such as correct use of ';'
|
||||
#
|
||||
# This library is free software; you can redistribute it and/or
|
||||
# modify it under the terms of the GNU Lesser General Public
|
||||
# License as published by the Free Software Foundation; either
|
||||
# version 2.1 of the License, or (at your option) any later version.
|
||||
#
|
||||
# This library is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
# Lesser General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU Lesser General Public
|
||||
# License along with this library. If not, see
|
||||
# <http://www.gnu.org/licenses/>.
|
||||
|
||||
use strict;
|
||||
use warnings;
|
||||
|
||||
my $ret = 0;
|
||||
my $incomment = 0;
|
||||
|
||||
foreach my $file (@ARGV) {
|
||||
# Per-file variables for multiline Curly Bracket (cb_) check
|
||||
my $cb_linenum = 0;
|
||||
my $cb_code = "";
|
||||
my $cb_scolon = 0;
|
||||
|
||||
open FILE, $file;
|
||||
|
||||
while (defined (my $line = <FILE>)) {
|
||||
my $data = $line;
|
||||
# For temporary modifications
|
||||
my $tmpdata;
|
||||
|
||||
# Kill any quoted , ; = or "
|
||||
$data =~ s/'[";,=]'/'X'/g;
|
||||
|
||||
# Kill any quoted strings
|
||||
$data =~ s,"(?:[^\\\"]|\\.)*","XXX",g;
|
||||
|
||||
next if $data =~ /^#/;
|
||||
|
||||
# Kill contents of multi-line comments
|
||||
# and detect end of multi-line comments
|
||||
if ($incomment) {
|
||||
if ($data =~ m,\*/,) {
|
||||
$incomment = 0;
|
||||
$data =~ s,^.*\*/,*/,;
|
||||
} else {
|
||||
$data = "";
|
||||
}
|
||||
}
|
||||
|
||||
# Kill single line comments, and detect
|
||||
# start of multi-line comments
|
||||
if ($data =~ m,/\*.*\*/,) {
|
||||
$data =~ s,/\*.*\*/,/* */,;
|
||||
} elsif ($data =~ m,/\*,) {
|
||||
$incomment = 1;
|
||||
$data =~ s,/\*.*,/*,;
|
||||
}
|
||||
|
||||
# We need to match things like
|
||||
#
|
||||
# int foo (int bar, bool wizz);
|
||||
# foo (bar, wizz);
|
||||
#
|
||||
# but not match things like:
|
||||
#
|
||||
# typedef int (*foo)(bar wizz)
|
||||
#
|
||||
# we can't do this (efficiently) without
|
||||
# missing things like
|
||||
#
|
||||
# foo (*bar, wizz);
|
||||
#
|
||||
# We also don't want to spoil the $data so it can be used
|
||||
# later on.
|
||||
$tmpdata = $data;
|
||||
while ($tmpdata =~ /(\w+)\s\((?!\*)/) {
|
||||
my $kw = $1;
|
||||
|
||||
# Allow space after keywords only
|
||||
if ($kw =~ /^(?:if|for|while|switch|return)$/) {
|
||||
$tmpdata =~ s/(?:$kw\s\()/XXX(/;
|
||||
} else {
|
||||
print "Whitespace after non-keyword:\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
last;
|
||||
}
|
||||
}
|
||||
|
||||
# Require whitespace immediately after keywords
|
||||
if ($data =~ /\b(?:if|for|while|switch|return)\(/) {
|
||||
print "No whitespace after keyword:\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# Forbid whitespace between )( of a function typedef
|
||||
if ($data =~ /\(\*\w+\)\s+\(/) {
|
||||
print "Whitespace between ')' and '(':\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# Forbid whitespace following ( or prior to )
|
||||
# but allow whitespace before ) on a single line
|
||||
# (optionally followed by a semicolon)
|
||||
if (($data =~ /\s\)/ && not $data =~ /^\s+\);?$/) ||
|
||||
$data =~ /\((?!$)\s/) {
|
||||
print "Whitespace after '(' or before ')':\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# Forbid whitespace before ";" or ",". Things like below are allowed:
|
||||
#
|
||||
# 1) The expression is empty for "for" loop. E.g.
|
||||
# for (i = 0; ; i++)
|
||||
#
|
||||
# 2) An empty statement. E.g.
|
||||
# while (write(statuswrite, &status, 1) == -1 &&
|
||||
# errno == EINTR)
|
||||
# ;
|
||||
#
|
||||
if ($data =~ /\s[;,]/) {
|
||||
unless ($data =~ /\S; ; / ||
|
||||
$data =~ /^\s+;/) {
|
||||
print "Whitespace before semicolon or comma:\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
}
|
||||
|
||||
# Require EOL, macro line continuation, or whitespace after ";".
|
||||
# Allow "for (;;)" as an exception.
|
||||
if ($data =~ /;[^ \\\n;)]/) {
|
||||
print "Invalid character after semicolon:\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# Require EOL, space, or enum/struct end after comma.
|
||||
if ($data =~ /,[^ \\\n)}]/) {
|
||||
print "Invalid character after comma:\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# Require spaces around assignment '=', compounds and '=='
|
||||
if ($data =~ /[^ ]\b[!<>&|\-+*\/%\^=]?=/ ||
|
||||
$data =~ /=[^= \\\n]/) {
|
||||
print "Spacing around '=' or '==':\n";
|
||||
print "$file:$.: $line";
|
||||
$ret = 1;
|
||||
}
|
||||
|
||||
# One line conditional statements with one line bodies should
|
||||
# not use curly brackets.
|
||||
if ($data =~ /^\s*(if|while|for)\b.*\{$/) {
|
||||
$cb_linenum = $.;
|
||||
$cb_code = $line;
|
||||
$cb_scolon = 0;
|
||||
}
|
||||
|
||||
# We need to check for exactly one semicolon inside the body,
|
||||
# because empty statements (e.g. with comment only) are
|
||||
# allowed
|
||||
if ($cb_linenum == $. - 1 && $data =~ /^[^;]*;[^;]*$/) {
|
||||
$cb_code .= $line;
|
||||
$cb_scolon = 1;
|
||||
}
|
||||
|
||||
if ($data =~ /^\s*}\s*$/ &&
|
||||
$cb_linenum == $. - 2 &&
|
||||
$cb_scolon) {
|
||||
|
||||
print "Curly brackets around single-line body:\n";
|
||||
print "$file:$cb_linenum-$.:\n$cb_code$line";
|
||||
$ret = 1;
|
||||
|
||||
# There _should_ be no need to reset the values; but to
|
||||
# keep my inner peace...
|
||||
$cb_linenum = 0;
|
||||
$cb_scolon = 0;
|
||||
$cb_code = "";
|
||||
}
|
||||
}
|
||||
close FILE;
|
||||
}
|
||||
|
||||
exit $ret;
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,226 +0,0 @@
|
||||
#!/bin/sh
|
||||
#! -*-perl-*-
|
||||
|
||||
# Detect instances of "if (p) free (p);".
|
||||
# Likewise "if (p != 0)", "if (0 != p)", or with NULL; and with braces.
|
||||
|
||||
# Copyright (C) 2008-2019 Free Software Foundation, Inc.
|
||||
#
|
||||
# This program is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
#
|
||||
# Written by Jim Meyering
|
||||
|
||||
# This is a prologue that allows to run a perl script as an executable
|
||||
# on systems that are compliant to a POSIX version before POSIX:2017.
|
||||
# On such systems, the usual invocation of an executable through execlp()
|
||||
# or execvp() fails with ENOEXEC if it is a script that does not start
|
||||
# with a #! line. The script interpreter mentioned in the #! line has
|
||||
# to be /bin/sh, because on GuixSD systems that is the only program that
|
||||
# has a fixed file name. The second line is essential for perl and is
|
||||
# also useful for editing this file in Emacs. The next two lines below
|
||||
# are valid code in both sh and perl. When executed by sh, they re-execute
|
||||
# the script through the perl program found in $PATH. The '-x' option
|
||||
# is essential as well; without it, perl would re-execute the script
|
||||
# through /bin/sh. When executed by perl, the next two lines are a no-op.
|
||||
eval 'exec perl -wSx "$0" "$@"'
|
||||
if 0;
|
||||
|
||||
my $VERSION = '2018-03-07 03:47'; # UTC
|
||||
# The definition above must lie within the first 8 lines in order
|
||||
# for the Emacs time-stamp write hook (at end) to update it.
|
||||
# If you change this file with Emacs, please let the write hook
|
||||
# do its job. Otherwise, update this string manually.
|
||||
|
||||
use strict;
|
||||
use warnings;
|
||||
use Getopt::Long;
|
||||
|
||||
(my $ME = $0) =~ s|.*/||;
|
||||
|
||||
# use File::Coda; # https://meyering.net/code/Coda/
|
||||
END {
|
||||
defined fileno STDOUT or return;
|
||||
close STDOUT and return;
|
||||
warn "$ME: failed to close standard output: $!\n";
|
||||
$? ||= 1;
|
||||
}
|
||||
|
||||
sub usage ($)
|
||||
{
|
||||
my ($exit_code) = @_;
|
||||
my $STREAM = ($exit_code == 0 ? *STDOUT : *STDERR);
|
||||
if ($exit_code != 0)
|
||||
{
|
||||
print $STREAM "Try '$ME --help' for more information.\n";
|
||||
}
|
||||
else
|
||||
{
|
||||
print $STREAM <<EOF;
|
||||
Usage: $ME [OPTIONS] FILE...
|
||||
|
||||
Detect any instance in FILE of a useless "if" test before a free call, e.g.,
|
||||
"if (p) free (p);". Any such test may be safely removed without affecting
|
||||
the semantics of the C code in FILE. Use --name=FOO --name=BAR to also
|
||||
detect free-like functions named FOO and BAR.
|
||||
|
||||
OPTIONS:
|
||||
|
||||
--list print only the name of each matching FILE (\\0-terminated)
|
||||
--name=N add name N to the list of \'free\'-like functions to detect;
|
||||
may be repeated
|
||||
|
||||
--help display this help and exit
|
||||
--version output version information and exit
|
||||
|
||||
Exit status:
|
||||
|
||||
0 one or more matches
|
||||
1 no match
|
||||
2 an error
|
||||
|
||||
EXAMPLE:
|
||||
|
||||
For example, this command prints all removable "if" tests before "free"
|
||||
and "kfree" calls in the linux kernel sources:
|
||||
|
||||
git ls-files -z |xargs -0 $ME --name=kfree
|
||||
|
||||
EOF
|
||||
}
|
||||
exit $exit_code;
|
||||
}
|
||||
|
||||
sub is_NULL ($)
|
||||
{
|
||||
my ($expr) = @_;
|
||||
return ($expr eq 'NULL' || $expr eq '0');
|
||||
}
|
||||
|
||||
{
|
||||
sub EXIT_MATCH {0}
|
||||
sub EXIT_NO_MATCH {1}
|
||||
sub EXIT_ERROR {2}
|
||||
my $err = EXIT_NO_MATCH;
|
||||
|
||||
my $list;
|
||||
my @name = qw(free);
|
||||
GetOptions
|
||||
(
|
||||
help => sub { usage 0 },
|
||||
version => sub { print "$ME version $VERSION\n"; exit },
|
||||
list => \$list,
|
||||
'name=s@' => \@name,
|
||||
) or usage 1;
|
||||
|
||||
# Make sure we have the right number of non-option arguments.
|
||||
# Always tell the user why we fail.
|
||||
@ARGV < 1
|
||||
and (warn "$ME: missing FILE argument\n"), usage EXIT_ERROR;
|
||||
|
||||
my $or = join '|', @name;
|
||||
my $regexp = qr/(?:$or)/;
|
||||
|
||||
# Set the input record separator.
|
||||
# Note: this makes it impractical to print line numbers.
|
||||
$/ = '"';
|
||||
|
||||
my $found_match = 0;
|
||||
FILE:
|
||||
foreach my $file (@ARGV)
|
||||
{
|
||||
open FH, '<', $file
|
||||
or (warn "$ME: can't open '$file' for reading: $!\n"),
|
||||
$err = EXIT_ERROR, next;
|
||||
while (defined (my $line = <FH>))
|
||||
{
|
||||
# Skip non-matching lines early to save time
|
||||
$line =~ /\bif\b/
|
||||
or next;
|
||||
while ($line =~
|
||||
/\b(if\s*\(\s*([^)]+?)(?:\s*!=\s*([^)]+?))?\s*\)
|
||||
# 1 2 3
|
||||
(?: \s*$regexp\s*\((?:\s*\([^)]+\))?\s*([^)]+)\)\s*;|
|
||||
\s*\{\s*$regexp\s*\((?:\s*\([^)]+\))?\s*([^)]+)\)\s*;\s*\}))/sxg)
|
||||
{
|
||||
my $all = $1;
|
||||
my ($lhs, $rhs) = ($2, $3);
|
||||
my ($free_opnd, $braced_free_opnd) = ($4, $5);
|
||||
my $non_NULL;
|
||||
if (!defined $rhs) { $non_NULL = $lhs }
|
||||
elsif (is_NULL $rhs) { $non_NULL = $lhs }
|
||||
elsif (is_NULL $lhs) { $non_NULL = $rhs }
|
||||
else { next }
|
||||
|
||||
# Compare the non-NULL part of the "if" expression and the
|
||||
# free'd expression, without regard to white space.
|
||||
$non_NULL =~ tr/ \t//d;
|
||||
my $e2 = defined $free_opnd ? $free_opnd : $braced_free_opnd;
|
||||
$e2 =~ tr/ \t//d;
|
||||
if ($non_NULL eq $e2)
|
||||
{
|
||||
$found_match = 1;
|
||||
$list
|
||||
and (print "$file\0"), next FILE;
|
||||
print "$file: $all\n";
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
continue
|
||||
{
|
||||
close FH;
|
||||
}
|
||||
|
||||
$found_match && $err == EXIT_NO_MATCH
|
||||
and $err = EXIT_MATCH;
|
||||
|
||||
exit $err;
|
||||
}
|
||||
|
||||
my $foo = <<'EOF';
|
||||
# The above is to *find* them.
|
||||
# This adjusts them, removing the unnecessary "if (p)" part.
|
||||
|
||||
# FIXME: do something like this as an option (doesn't do braces):
|
||||
free=xfree
|
||||
git grep -l -z "$free *(" \
|
||||
| xargs -0 useless-if-before-free -l --name="$free" \
|
||||
| xargs -0 perl -0x3b -pi -e \
|
||||
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*(?:0|NULL))?\s*\)\s+('"$free"'\s*\((?:\s*\([^)]+\))?\s*\1\s*\)\s*;)/$2/s'
|
||||
|
||||
# Use the following to remove redundant uses of kfree inside braces.
|
||||
# Note that -0777 puts perl in slurp-whole-file mode;
|
||||
# but we have plenty of memory, these days...
|
||||
free=kfree
|
||||
git grep -l -z "$free *(" \
|
||||
| xargs -0 useless-if-before-free -l --name="$free" \
|
||||
| xargs -0 perl -0777 -pi -e \
|
||||
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*(?:0|NULL))?\s*\)\s*\{\s*('"$free"'\s*\((?:\s*\([^)]+\))?\s*\1\s*\);)\s*\}[^\n]*$/$2/gms'
|
||||
|
||||
Be careful that the result of the above transformation is valid.
|
||||
If the matched string is followed by "else", then obviously, it won't be.
|
||||
|
||||
When modifying files, refuse to process anything other than a regular file.
|
||||
EOF
|
||||
|
||||
## Local Variables:
|
||||
## mode: perl
|
||||
## indent-tabs-mode: nil
|
||||
## eval: (add-hook 'before-save-hook 'time-stamp)
|
||||
## time-stamp-line-limit: 50
|
||||
## time-stamp-start: "my $VERSION = '"
|
||||
## time-stamp-format: "%:y-%02m-%02d %02H:%02M"
|
||||
## time-stamp-time-zone: "UTC0"
|
||||
## time-stamp-end: "'; # UTC"
|
||||
## End:
|
||||
@@ -1,113 +0,0 @@
|
||||
#!/bin/sh
|
||||
# List version-controlled file names.
|
||||
|
||||
# Print a version string.
|
||||
scriptversion=2018-03-07.03; # UTC
|
||||
|
||||
# Copyright (C) 2006-2019 Free Software Foundation, Inc.
|
||||
|
||||
# This program is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
|
||||
# List the specified version-controlled files.
|
||||
# With no argument, list them all. With a single DIRECTORY argument,
|
||||
# list the version-controlled files in that directory.
|
||||
|
||||
# If there's an argument, it must be a single, "."-relative directory name.
|
||||
# cvsu is part of the cvsutils package: http://www.red-bean.com/cvsutils/
|
||||
|
||||
postprocess=
|
||||
case $1 in
|
||||
--help) cat <<EOF
|
||||
Usage: $0 [-C SRCDIR] [DIR...]
|
||||
|
||||
Output a list of version-controlled files in DIR (default .), relative to
|
||||
SRCDIR (default .). SRCDIR must be the top directory of a checkout.
|
||||
|
||||
Options:
|
||||
--help print this help, then exit
|
||||
--version print version number, then exit
|
||||
-C SRCDIR change directory to SRCDIR before generating list
|
||||
|
||||
Report bugs and patches to <bug-gnulib@gnu.org>.
|
||||
EOF
|
||||
exit ;;
|
||||
|
||||
--version)
|
||||
year=`echo "$scriptversion" | sed 's/[^0-9].*//'`
|
||||
cat <<EOF
|
||||
vc-list-files $scriptversion
|
||||
Copyright (C) $year Free Software Foundation, Inc,
|
||||
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
|
||||
This is free software: you are free to change and redistribute it.
|
||||
There is NO WARRANTY, to the extent permitted by law.
|
||||
EOF
|
||||
exit ;;
|
||||
|
||||
-C)
|
||||
test "$2" = . || postprocess="| sed 's|^|$2/|'"
|
||||
cd "$2" || exit 1
|
||||
shift; shift ;;
|
||||
esac
|
||||
|
||||
test $# = 0 && set .
|
||||
|
||||
for dir
|
||||
do
|
||||
if test -d .git || test -f .git; then
|
||||
test "x$dir" = x. \
|
||||
&& dir= sed_esc= \
|
||||
|| { dir="$dir/"; sed_esc=`echo "$dir"|env sed 's,\([\\/]\),\\\\\1,g'`; }
|
||||
# Ignore git symlinks - either they point into the tree, in which case
|
||||
# we don't need to visit the target twice, or they point somewhere
|
||||
# else (often into a submodule), in which case the content does not
|
||||
# belong to this package.
|
||||
eval exec git ls-tree -r 'HEAD:"$dir"' \
|
||||
\| sed -n '"s/^100[^ ]*./$sed_esc/p"' $postprocess
|
||||
elif test -d .hg; then
|
||||
eval exec hg locate '"$dir/*"' $postprocess
|
||||
elif test -d .bzr; then
|
||||
test "$postprocess" = '' && postprocess="| sed 's|^\./||'"
|
||||
eval exec bzr ls -R --versioned '"$dir"' $postprocess
|
||||
elif test -d CVS; then
|
||||
test "$postprocess" = '' && postprocess="| sed 's|^\./||'"
|
||||
if test -x build-aux/cvsu; then
|
||||
eval build-aux/cvsu --find --types=AFGM '"$dir"' $postprocess
|
||||
elif (cvsu --help) >/dev/null 2>&1; then
|
||||
eval cvsu --find --types=AFGM '"$dir"' $postprocess
|
||||
else
|
||||
eval awk -F/ \''{ \
|
||||
if (!$1 && $3 !~ /^-/) { \
|
||||
f=FILENAME; \
|
||||
if (f ~ /CVS\/Entries$/) \
|
||||
f = substr(f, 1, length(f)-11); \
|
||||
print f $2; \
|
||||
}}'\'' \
|
||||
`find "$dir" -name Entries -print` /dev/null' $postprocess
|
||||
fi
|
||||
elif test -d .svn; then
|
||||
eval exec svn list -R '"$dir"' $postprocess
|
||||
else
|
||||
echo "$0: Failed to determine type of version control used in `pwd`" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'before-save-hook 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC0"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
269
ci/Makefile
269
ci/Makefile
@@ -1,269 +0,0 @@
|
||||
# -*- makefile -*-
|
||||
# vim: filetype=make
|
||||
|
||||
# The root directory of the libvirt.git checkout
|
||||
CI_GIT_ROOT = $(shell git rev-parse --show-toplevel)
|
||||
|
||||
# The root directory for all CI-related contents
|
||||
CI_ROOTDIR = $(CI_GIT_ROOT)/ci
|
||||
|
||||
# The directory holding content on the host that we will
|
||||
# expose to the container.
|
||||
CI_SCRATCHDIR = $(CI_ROOTDIR)/scratch
|
||||
|
||||
# The directory holding the clone of the git repo that
|
||||
# we will expose to the container
|
||||
CI_HOST_SRCDIR = $(CI_SCRATCHDIR)/src
|
||||
|
||||
# The directory holding the source inside the
|
||||
# container, i.e. where we want to expose
|
||||
# the $(CI_HOST_SRCDIR) directory from the host
|
||||
CI_CONT_SRCDIR = $(CI_USER_HOME)/libvirt
|
||||
|
||||
# Relative directory to perform the build in. This
|
||||
# defaults to using a separate build dir, but can be
|
||||
# set to empty string for an in-source tree build.
|
||||
CI_VPATH = build
|
||||
|
||||
# The directory holding the build output inside the
|
||||
# container.
|
||||
CI_CONT_BUILDDIR = $(CI_CONT_SRCDIR)/$(CI_VPATH)
|
||||
|
||||
# Can be overridden with mingw{32,64}-configure if desired
|
||||
CI_CONFIGURE = $(CI_CONT_SRCDIR)/configure
|
||||
|
||||
# Default to using all possible CPUs
|
||||
CI_SMP = $(shell getconf _NPROCESSORS_ONLN)
|
||||
|
||||
# Any extra arguments to pass to make
|
||||
CI_MAKE_ARGS =
|
||||
|
||||
# Any extra arguments to pass to configure
|
||||
CI_CONFIGURE_ARGS =
|
||||
|
||||
# Script containing environment preparation steps
|
||||
CI_PREPARE_SCRIPT = $(CI_ROOTDIR)/prepare.sh
|
||||
|
||||
# Script containing build instructions
|
||||
CI_BUILD_SCRIPT = $(CI_ROOTDIR)/build.sh
|
||||
|
||||
# Location of the container images we're going to pull
|
||||
# Can be useful to overridde to use a locally built
|
||||
# image instead
|
||||
CI_IMAGE_PREFIX = quay.io/libvirt/buildenv-libvirt-
|
||||
|
||||
# The default tag is ':latest' but if the container
|
||||
# repo above uses different conventions this can override it
|
||||
CI_IMAGE_TAG = :latest
|
||||
|
||||
# We delete the virtual root after completion, set
|
||||
# to 0 if you need to keep it around for debugging
|
||||
CI_CLEAN = 1
|
||||
|
||||
# We'll always freshly clone the virtual root each
|
||||
# time in case it was not cleaned up before. Set
|
||||
# to 1 if you want to try restarting a previously
|
||||
# preserved env
|
||||
CI_REUSE = 0
|
||||
|
||||
# We need the container process to run with current host IDs
|
||||
# so that it can access the passed in build directory
|
||||
CI_UID = $(shell id -u)
|
||||
CI_GID = $(shell id -g)
|
||||
|
||||
# We also need the user's login and home directory to prepare the
|
||||
# environment the way some programs expect it
|
||||
CI_USER_LOGIN = $(shell echo "$$USER")
|
||||
CI_USER_HOME = $(shell echo "$$HOME")
|
||||
|
||||
CI_ENGINE = auto
|
||||
# Container engine we are going to use, can be overridden per make
|
||||
# invocation, if it is not we try podman and then default to docker.
|
||||
ifeq ($(CI_ENGINE),auto)
|
||||
override CI_ENGINE = $(shell podman version >/dev/null 2>&1 && echo podman || echo docker)
|
||||
endif
|
||||
|
||||
# IDs you run as do not need to exist in
|
||||
# the container's /etc/passwd & /etc/group files, but
|
||||
# if they do not, then libvirt's 'make check' will fail
|
||||
# many tests.
|
||||
|
||||
# We do not directly mount /etc/{passwd,group} as Docker
|
||||
# is liable to mess with SELinux labelling which will
|
||||
# then prevent the host accessing them. And podman cannot
|
||||
# relabel the files due to it running rootless. So
|
||||
# copying them first is safer and less error-prone.
|
||||
CI_PWDB_MOUNTS = \
|
||||
--volume $(CI_SCRATCHDIR)/group:/etc/group:ro,z \
|
||||
--volume $(CI_SCRATCHDIR)/passwd:/etc/passwd:ro,z \
|
||||
$(NULL)
|
||||
|
||||
CI_HOME_MOUNTS = \
|
||||
--volume $(CI_SCRATCHDIR)/home:$(CI_USER_HOME):z \
|
||||
$(NULL)
|
||||
|
||||
CI_SCRIPT_MOUNTS = \
|
||||
--volume $(CI_SCRATCHDIR)/prepare:$(CI_USER_HOME)/prepare:z \
|
||||
--volume $(CI_SCRATCHDIR)/build:$(CI_USER_HOME)/build:z \
|
||||
$(NULL)
|
||||
|
||||
# Docker containers can have very large ulimits
|
||||
# for nofiles - as much as 1048576. This makes
|
||||
# libvirt very slow at exec'ing programs.
|
||||
CI_ULIMIT_FILES = 1024
|
||||
|
||||
ifeq ($(CI_ENGINE),podman)
|
||||
# Podman cannot reuse host namespace when running non-root
|
||||
# containers. Until support for --keep-uid is added we can
|
||||
# just create another mapping that will do that for us.
|
||||
# Beware, that in {uid,git}map=container_id:host_id:range, the
|
||||
# host_id does actually refer to the uid in the first mapping
|
||||
# where 0 (root) is mapped to the current user and rest is
|
||||
# offset.
|
||||
#
|
||||
# In order to set up this mapping, we need to keep all the
|
||||
# user IDs to prevent possible errors as some images might
|
||||
# expect UIDs up to 90000 (looking at you fedora), so we don't
|
||||
# want the overflowuid to be used for them. For mapping all
|
||||
# the other users properly, some math needs to be done.
|
||||
# Don't worry, it's just addition and subtraction.
|
||||
#
|
||||
# 65536 ought to be enough (tm), but for really rare cases the
|
||||
# maximums might need to be higher, but that only happens when
|
||||
# your /etc/sub{u,g}id allow users to have more IDs. Unless
|
||||
# --keep-uid is supported, let's do this in a way that should
|
||||
# work for everyone.
|
||||
CI_MAX_UID = $(shell sed -n "s/^$(CI_USER_LOGIN):[^:]\+://p" /etc/subuid)
|
||||
CI_MAX_GID = $(shell sed -n "s/^$(CI_USER_LOGIN):[^:]\+://p" /etc/subgid)
|
||||
ifeq ($(CI_MAX_UID),)
|
||||
CI_MAX_UID = 65536
|
||||
endif
|
||||
ifeq ($(CI_MAX_GID),)
|
||||
CI_MAX_GID = 65536
|
||||
endif
|
||||
CI_UID_OTHER = $(shell echo $$(($(CI_UID)+1)))
|
||||
CI_GID_OTHER = $(shell echo $$(($(CI_GID)+1)))
|
||||
CI_UID_OTHER_RANGE = $(shell echo $$(($(CI_MAX_UID)-$(CI_UID))))
|
||||
CI_GID_OTHER_RANGE = $(shell echo $$(($(CI_MAX_GID)-$(CI_GID))))
|
||||
|
||||
CI_PODMAN_ARGS = \
|
||||
--uidmap 0:1:$(CI_UID) \
|
||||
--uidmap $(CI_UID):0:1 \
|
||||
--uidmap $(CI_UID_OTHER):$(CI_UID_OTHER):$(CI_UID_OTHER_RANGE) \
|
||||
--gidmap 0:1:$(CI_GID) \
|
||||
--gidmap $(CI_GID):0:1 \
|
||||
--gidmap $(CI_GID_OTHER):$(CI_GID_OTHER):$(CI_GID_OTHER_RANGE) \
|
||||
$(NULL)
|
||||
endif
|
||||
|
||||
# Args to use when cloning a git repo.
|
||||
# -c stop it complaining about checking out a random hash
|
||||
# -q stop it displaying progress info for local clone
|
||||
# --local ensure we don't actually copy files
|
||||
CI_GIT_ARGS = \
|
||||
-c advice.detachedHead=false \
|
||||
-q \
|
||||
--local \
|
||||
$(NULL)
|
||||
|
||||
# Args to use when running the container
|
||||
# --rm stop inactive containers getting left behind
|
||||
# --user we execute as the same user & group account
|
||||
# as dev so that file ownership matches host
|
||||
# instead of root:root
|
||||
# --volume to pass in the cloned git repo & config
|
||||
# --ulimit lower files limit for performance reasons
|
||||
# --interactive
|
||||
# --tty Ensure we have ability to Ctrl-C the build
|
||||
CI_ENGINE_ARGS = \
|
||||
--rm \
|
||||
--interactive \
|
||||
--tty \
|
||||
$(CI_PODMAN_ARGS) \
|
||||
$(CI_PWDB_MOUNTS) \
|
||||
$(CI_HOME_MOUNTS) \
|
||||
$(CI_SCRIPT_MOUNTS) \
|
||||
--volume $(CI_HOST_SRCDIR):$(CI_CONT_SRCDIR):z \
|
||||
--ulimit nofile=$(CI_ULIMIT_FILES):$(CI_ULIMIT_FILES) \
|
||||
--cap-add=SYS_PTRACE \
|
||||
$(NULL)
|
||||
|
||||
ci-check-engine:
|
||||
@echo -n "Checking if $(CI_ENGINE) is available..." && \
|
||||
$(CI_ENGINE) version 1>/dev/null && echo "yes"
|
||||
|
||||
ci-prepare-tree: ci-check-engine
|
||||
@test "$(CI_REUSE)" != "1" && rm -rf $(CI_SCRATCHDIR) || :
|
||||
@if ! test -d $(CI_SCRATCHDIR) ; then \
|
||||
mkdir -p $(CI_SCRATCHDIR); \
|
||||
cp /etc/passwd $(CI_SCRATCHDIR); \
|
||||
cp /etc/group $(CI_SCRATCHDIR); \
|
||||
mkdir -p $(CI_SCRATCHDIR)/home; \
|
||||
cp "$(CI_PREPARE_SCRIPT)" $(CI_SCRATCHDIR)/prepare; \
|
||||
cp "$(CI_BUILD_SCRIPT)" $(CI_SCRATCHDIR)/build; \
|
||||
chmod +x "$(CI_SCRATCHDIR)/prepare" "$(CI_SCRATCHDIR)/build"; \
|
||||
echo "Cloning $(CI_GIT_ROOT) to $(CI_HOST_SRCDIR)"; \
|
||||
git clone $(CI_GIT_ARGS) $(CI_GIT_ROOT) $(CI_HOST_SRCDIR) || exit 1; \
|
||||
for mod in $$(git submodule | awk '{ print $$2 }' | sed -E 's,^../,,g') ; \
|
||||
do \
|
||||
test -f $(CI_GIT_ROOT)/$$mod/.git || continue ; \
|
||||
echo "Cloning $(CI_GIT_ROOT)/$$mod to $(CI_HOST_SRCDIR)/$$mod"; \
|
||||
git clone $(CI_GIT_ARGS) $(CI_GIT_ROOT)/$$mod $(CI_HOST_SRCDIR)/$$mod || exit 1; \
|
||||
done ; \
|
||||
fi
|
||||
|
||||
ci-run-command@%: ci-prepare-tree
|
||||
$(CI_ENGINE) run $(CI_ENGINE_ARGS) $(CI_IMAGE_PREFIX)$*$(CI_IMAGE_TAG) \
|
||||
/bin/bash -c ' \
|
||||
$(CI_USER_HOME)/prepare || exit 1; \
|
||||
sudo \
|
||||
--login \
|
||||
--user="#$(CI_UID)" \
|
||||
--group="#$(CI_GID)" \
|
||||
CONFIGURE_OPTS="$$CONFIGURE_OPTS" \
|
||||
CI_CONT_SRCDIR="$(CI_CONT_SRCDIR)" \
|
||||
CI_CONT_BUILDDIR="$(CI_CONT_BUILDDIR)" \
|
||||
CI_SMP="$(CI_SMP)" \
|
||||
CI_CONFIGURE="$(CI_CONFIGURE)" \
|
||||
CI_CONFIGURE_ARGS="$(CI_CONFIGURE_ARGS)" \
|
||||
CI_MAKE_ARGS="$(CI_MAKE_ARGS)" \
|
||||
$(CI_COMMAND) || exit 1'
|
||||
@test "$(CI_CLEAN)" = "1" && rm -rf $(CI_SCRATCHDIR) || :
|
||||
|
||||
ci-shell@%:
|
||||
$(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="/bin/bash"
|
||||
|
||||
ci-build@%:
|
||||
$(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="$(CI_USER_HOME)/build"
|
||||
|
||||
ci-check@%:
|
||||
$(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="check"
|
||||
|
||||
ci-list-images:
|
||||
@echo
|
||||
@echo "Available x86 container images:"
|
||||
@echo
|
||||
@sh list-images.sh "$(CI_ENGINE)" "$(CI_IMAGE_PREFIX)" | grep -v cross
|
||||
@echo
|
||||
@echo "Available cross-compiler container images:"
|
||||
@echo
|
||||
@sh list-images.sh "$(CI_ENGINE)" "$(CI_IMAGE_PREFIX)" | grep cross
|
||||
@echo
|
||||
|
||||
ci-help:
|
||||
@echo "Build libvirt inside containers used for CI"
|
||||
@echo
|
||||
@echo "Available targets:"
|
||||
@echo
|
||||
@echo " ci-build@\$$IMAGE - run a default 'make'"
|
||||
@echo " ci-check@\$$IMAGE - run a 'make check'"
|
||||
@echo " ci-shell@\$$IMAGE - run an interactive shell"
|
||||
@echo " ci-list-images - list available images"
|
||||
@echo " ci-help - show this help message"
|
||||
@echo
|
||||
@echo "Available make variables:"
|
||||
@echo
|
||||
@echo " CI_CLEAN=0 - do not delete '$(CI_SCRATCHDIR)' after completion"
|
||||
@echo " CI_REUSE=1 - re-use existing '$(CI_SCRATCHDIR)' content"
|
||||
@echo " CI_ENGINE=auto - container engine to use (podman, docker)"
|
||||
@echo
|
||||
38
ci/build.sh
38
ci/build.sh
@@ -1,38 +0,0 @@
|
||||
# This script is used to build libvirt inside the container.
|
||||
#
|
||||
# You can customize it to your liking, or alternatively use a
|
||||
# completely different script by passing
|
||||
#
|
||||
# CI_BUILD_SCRIPT=/path/to/your/build/script
|
||||
#
|
||||
# to make.
|
||||
|
||||
mkdir -p "$CI_CONT_BUILDDIR" || exit 1
|
||||
cd "$CI_CONT_BUILDDIR"
|
||||
|
||||
export VIR_TEST_DEBUG=1
|
||||
NOCONFIGURE=1 "$CI_CONT_SRCDIR/autogen.sh" || exit 1
|
||||
|
||||
# $CONFIGURE_OPTS is a env that can optionally be set in the container,
|
||||
# populated at build time from the Dockerfile. A typical use case would
|
||||
# be to pass --host/--target args to trigger cross-compilation
|
||||
#
|
||||
# This can be augmented by make local args in $CI_CONFIGURE_ARGS
|
||||
"$CI_CONFIGURE" $CONFIGURE_OPTS $CI_CONFIGURE_ARGS
|
||||
if test $? != 0; then
|
||||
test -f config.log && cat config.log
|
||||
exit 1
|
||||
fi
|
||||
find -name test-suite.log -delete
|
||||
|
||||
make -j"$CI_SMP" $CI_MAKE_ARGS
|
||||
|
||||
if test $? != 0; then \
|
||||
LOGS=$(find -name test-suite.log)
|
||||
if test "$LOGS"; then
|
||||
echo "=== LOG FILE(S) START ==="
|
||||
cat $LOGS
|
||||
echo "=== LOG FILE(S) END ==="
|
||||
fi
|
||||
exit 1
|
||||
fi
|
||||
@@ -1,26 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
engine="$1"
|
||||
prefix="$2"
|
||||
|
||||
do_podman() {
|
||||
# Podman freaks out if the search term ends with a dash, which ours
|
||||
# by default does, so let's strip it. The repository name is the
|
||||
# second field in the output, and it already starts with the registry
|
||||
podman search --limit 100 "${prefix%-}" | while read _ repo _; do
|
||||
echo "$repo"
|
||||
done
|
||||
}
|
||||
|
||||
do_docker() {
|
||||
# Docker doesn't include the registry name in the output, so we have
|
||||
# to add it. The repository name is the first field in the output
|
||||
registry="${prefix%%/*}"
|
||||
docker search --limit 100 "$prefix" | while read repo _; do
|
||||
echo "$registry/$repo"
|
||||
done
|
||||
}
|
||||
|
||||
"do_$engine" | grep "^$prefix" | sed "s,^$prefix,,g" | while read repo; do
|
||||
echo " $repo"
|
||||
done | sort -u
|
||||
@@ -1,13 +0,0 @@
|
||||
# This script is used to prepare the environment that will be used
|
||||
# to build libvirt inside the container.
|
||||
#
|
||||
# You can customize it to your liking, or alternatively use a
|
||||
# completely different script by passing
|
||||
#
|
||||
# CI_PREPARE_SCRIPT=/path/to/your/prepare/script
|
||||
#
|
||||
# to make.
|
||||
#
|
||||
# Note that this script will have root privileges inside the
|
||||
# container, so it can be used for things like installing additional
|
||||
# packages.
|
||||
@@ -1,58 +0,0 @@
|
||||
/*
|
||||
* Copyright (C) 2013 Red Hat, Inc.
|
||||
*
|
||||
* This library is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU Lesser General Public
|
||||
* License as published by the Free Software Foundation; either
|
||||
* version 2.1 of the License, or (at your option) any later version.
|
||||
*
|
||||
* This library is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
* Lesser General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU Lesser General Public
|
||||
* License along with this library. If not, see
|
||||
* <http://www.gnu.org/licenses/>.
|
||||
*/
|
||||
|
||||
#ifndef __GNUC__
|
||||
# error "Libvirt requires GCC >= 4.8, or CLang"
|
||||
#endif
|
||||
|
||||
/*
|
||||
* Define __GNUC_PREREQ to a sane default if it isn't yet defined.
|
||||
* This is done here so that it's included as early as possible;
|
||||
*/
|
||||
#ifndef __GNUC_PREREQ
|
||||
# define __GNUC_PREREQ(maj, min) \
|
||||
((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
|
||||
#endif
|
||||
|
||||
#if defined(__clang_major__) && defined(__clang_minor__)
|
||||
# ifdef __apple_build_version__
|
||||
# if __clang_major__ < 5 || (__clang_major__ == 5 && __clang_minor__ < 1)
|
||||
# error You need at least XCode Clang v5.1 to compile QEMU
|
||||
# endif
|
||||
# else
|
||||
# if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ < 4)
|
||||
# error You need at least Clang v3.4 to compile QEMU
|
||||
# endif
|
||||
# endif
|
||||
#elif defined(__GNUC__) && defined(__GNUC_MINOR__)
|
||||
# if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
|
||||
# error You need at least GCC v4.8 to compile QEMU
|
||||
# endif
|
||||
#else
|
||||
# error You either need at least GCC 4.8 or Clang 3.4 or XCode Clang 5.1 to compile libvirt
|
||||
#endif
|
||||
|
||||
/* Ask for warnings for anything that was marked deprecated in
|
||||
* the defined version, or before. It is a candidate for rewrite.
|
||||
*/
|
||||
#define GLIB_VERSION_MIN_REQUIRED GLIB_VERSION_2_48
|
||||
|
||||
/* Ask for warnings if code tries to use function that did not
|
||||
* exist in the defined version. These risk breaking builds
|
||||
*/
|
||||
#define GLIB_VERSION_MAX_ALLOWED GLIB_VERSION_2_48
|
||||
1060
configure.ac
1060
configure.ac
File diff suppressed because it is too large
Load Diff
@@ -1,19 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>404 page not found</h1>
|
||||
|
||||
<p>
|
||||
Someone appears to have eaten the <del>penguin</del>
|
||||
page you were looking for. You might want to try
|
||||
</p>
|
||||
<ul>
|
||||
<li>going back to the <a href="https://libvirt.org/">home page</a> to find
|
||||
a collection of links to interesting pages on this site</li>
|
||||
<li>using the search box at the top right corner of the screen to
|
||||
locate the content on this site or mailing list archives</li>
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
537
docs/Makefile.am
537
docs/Makefile.am
@@ -1,537 +0,0 @@
|
||||
## Process this file with automake to produce Makefile.in
|
||||
|
||||
## Copyright (C) 2005-2016 Red Hat, Inc.
|
||||
##
|
||||
## This library is free software; you can redistribute it and/or
|
||||
## modify it under the terms of the GNU Lesser General Public
|
||||
## License as published by the Free Software Foundation; either
|
||||
## version 2.1 of the License, or (at your option) any later version.
|
||||
##
|
||||
## This library is distributed in the hope that it will be useful,
|
||||
## but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
## Lesser General Public License for more details.
|
||||
##
|
||||
## You should have received a copy of the GNU Lesser General Public
|
||||
## License along with this library. If not, see
|
||||
## <http://www.gnu.org/licenses/>.
|
||||
|
||||
HTML_DIR = $(docdir)/html
|
||||
|
||||
modules = \
|
||||
libvirt-common \
|
||||
libvirt-domain \
|
||||
libvirt-domain-checkpoint \
|
||||
libvirt-domain-snapshot \
|
||||
libvirt-event \
|
||||
libvirt-host \
|
||||
libvirt-interface \
|
||||
libvirt-network \
|
||||
libvirt-nodedev \
|
||||
libvirt-nwfilter \
|
||||
libvirt-secret \
|
||||
libvirt-storage \
|
||||
libvirt-stream \
|
||||
virterror \
|
||||
$(NULL)
|
||||
|
||||
modules_admin = libvirt-admin
|
||||
modules_qemu = libvirt-qemu
|
||||
modules_lxc = libvirt-lxc
|
||||
|
||||
all: vpathhack
|
||||
|
||||
# This hack enables us to view the web pages
|
||||
# from within the uninstalled build tree
|
||||
vpathhack:
|
||||
@for dir in fonts js logos; \
|
||||
do \
|
||||
test -e $$dir || ln -s $(srcdir)/$$dir $$dir ; \
|
||||
done
|
||||
@for file in $(assets); \
|
||||
do \
|
||||
test -e $$file || ln -s $(srcdir)/$$file $$file ; \
|
||||
done
|
||||
|
||||
clean-local:
|
||||
for dir in fonts js logos; \
|
||||
do \
|
||||
rm -f $$dir ; \
|
||||
done
|
||||
for file in $(assets); \
|
||||
do \
|
||||
rm -f $$file ; \
|
||||
done
|
||||
|
||||
apihtml = \
|
||||
html/index.html \
|
||||
$(apihtml_generated)
|
||||
|
||||
apihtml_generated = \
|
||||
$(addprefix html/libvirt-,$(addsuffix .html,$(modules))) \
|
||||
$(NULL)
|
||||
|
||||
apiadminhtml = \
|
||||
html/index-admin.html \
|
||||
$(apiadminhtml_generated)
|
||||
|
||||
apiadminhtml_generated = \
|
||||
$(addprefix html/libvirt-,$(addsuffix .html,$(modules_admin))) \
|
||||
$(NULL)
|
||||
|
||||
apiqemuhtml = \
|
||||
html/index-qemu.html \
|
||||
$(apiqemuhtml_generated)
|
||||
|
||||
apiqemuhtml_generated = \
|
||||
$(addprefix html/libvirt-,$(addsuffix .html,$(modules_qemu))) \
|
||||
$(NULL)
|
||||
|
||||
apilxchtml = \
|
||||
html/index-lxc.html \
|
||||
$(apilxchtml_generated)
|
||||
|
||||
apilxchtml_generated = \
|
||||
$(addprefix html/libvirt-,$(addsuffix .html,$(modules_lxc))) \
|
||||
$(NULL)
|
||||
|
||||
apipng = \
|
||||
html/left.png \
|
||||
html/up.png \
|
||||
html/home.png \
|
||||
html/right.png
|
||||
|
||||
apirefdir = $(HTML_DIR)/html
|
||||
apiref_DATA = $(apihtml) $(apiadminhtml) $(apiqemuhtml) $(apilxchtml) $(apipng)
|
||||
|
||||
javascript = \
|
||||
js/main.js \
|
||||
$(NULL)
|
||||
|
||||
javascriptdir = $(HTML_DIR)/js
|
||||
javascript_DATA = $(javascript)
|
||||
|
||||
fonts = \
|
||||
fonts/LICENSE.rst \
|
||||
fonts/stylesheet.css \
|
||||
fonts/overpass-bold-italic.woff \
|
||||
fonts/overpass-bold.woff \
|
||||
fonts/overpass-italic.woff \
|
||||
fonts/overpass-light-italic.woff \
|
||||
fonts/overpass-light.woff \
|
||||
fonts/overpass-mono-bold.woff \
|
||||
fonts/overpass-mono-light.woff \
|
||||
fonts/overpass-mono-regular.woff \
|
||||
fonts/overpass-mono-semibold.woff \
|
||||
fonts/overpass-regular.woff
|
||||
|
||||
fontsdir = $(HTML_DIR)/fonts
|
||||
fonts_DATA = $(fonts)
|
||||
|
||||
logofiles = \
|
||||
logos/logo-base.svg \
|
||||
logos/logo-square.svg \
|
||||
logos/logo-square-powered.svg \
|
||||
logos/logo-banner-dark.svg \
|
||||
logos/logo-banner-light.svg \
|
||||
logos/logo-square-96.png \
|
||||
logos/logo-square-128.png \
|
||||
logos/logo-square-192.png \
|
||||
logos/logo-square-256.png \
|
||||
logos/logo-square-powered-96.png \
|
||||
logos/logo-square-powered-128.png \
|
||||
logos/logo-square-powered-192.png \
|
||||
logos/logo-square-powered-256.png \
|
||||
logos/logo-banner-dark-256.png \
|
||||
logos/logo-banner-dark-800.png \
|
||||
logos/logo-banner-light-256.png \
|
||||
logos/logo-banner-light-800.png
|
||||
|
||||
logofilesdir = $(HTML_DIR)/logos
|
||||
logofiles_DATA = $(logofiles)
|
||||
|
||||
assets = \
|
||||
android-chrome-192x192.png \
|
||||
android-chrome-256x256.png \
|
||||
apple-touch-icon.png \
|
||||
architecture.gif \
|
||||
browserconfig.xml \
|
||||
favicon.ico \
|
||||
favicon-16x16.png \
|
||||
favicon-32x32.png \
|
||||
generic.css \
|
||||
libvirt.css \
|
||||
libvirt-daemon-arch.png \
|
||||
libvirt-driver-arch.png \
|
||||
libvirt-object-model.png \
|
||||
libvirt-virConnect-example.png \
|
||||
main.css \
|
||||
manifest.json \
|
||||
migration-managed-direct.png \
|
||||
migration-managed-p2p.png \
|
||||
migration-native.png \
|
||||
migration-tunnel.png \
|
||||
migration-unmanaged-direct.png \
|
||||
mobile.css \
|
||||
mstile-150x150.png \
|
||||
node.gif \
|
||||
$(NULL)
|
||||
|
||||
internals_html_in = \
|
||||
$(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.html.in))
|
||||
internals_rst = \
|
||||
$(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.rst))
|
||||
internals_rst_html_in = \
|
||||
$(internals_rst:%.rst=%.html.in)
|
||||
internals_html = \
|
||||
$(internals_html_in:%.html.in=%.html) \
|
||||
$(internals_rst_html_in:%.html.in=%.html)
|
||||
|
||||
internalsdir = $(HTML_DIR)/internals
|
||||
internals_DATA = $(internals_html)
|
||||
|
||||
kbase_html_in = \
|
||||
$(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.html.in))
|
||||
kbase_rst = \
|
||||
$(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.rst))
|
||||
kbase_rst_html_in = \
|
||||
$(kbase_rst:%.rst=%.html.in)
|
||||
kbase_html = \
|
||||
$(kbase_html_in:%.html.in=%.html) \
|
||||
$(kbase_rst_html_in:%.html.in=%.html)
|
||||
|
||||
kbasedir = $(HTML_DIR)/kbase
|
||||
kbase_DATA = $(kbase_html)
|
||||
|
||||
# Sync with src/util/
|
||||
KEYCODES = linux osx atset1 atset2 atset3 xtkbd usb win32 qnum
|
||||
KEYNAMES = linux osx win32
|
||||
|
||||
manpages_rst = \
|
||||
manpages/index.rst \
|
||||
$(NULL)
|
||||
manpages1_rst = \
|
||||
manpages/virt-pki-validate.rst \
|
||||
manpages/virt-xml-validate.rst \
|
||||
manpages/virt-admin.rst \
|
||||
manpages/virsh.rst \
|
||||
$(NULL)
|
||||
manpages7_rst = \
|
||||
$(KEYCODES:%=manpages/virkeycode-%.rst) \
|
||||
$(KEYNAMES:%=manpages/virkeyname-%.rst) \
|
||||
$(NULL)
|
||||
manpages8_rst = $(NULL)
|
||||
manpages_rst += \
|
||||
$(manpages1_rst) \
|
||||
$(manpages7_rst) \
|
||||
$(manpages8_rst) \
|
||||
$(NULL)
|
||||
if WITH_LIBVIRTD
|
||||
manpages8_rst += \
|
||||
manpages/libvirtd.rst \
|
||||
manpages/virtlockd.rst \
|
||||
manpages/virtlogd.rst \
|
||||
$(NULL)
|
||||
else ! WITH_LIBVIRTD
|
||||
manpages_rst += \
|
||||
manpages/libvirtd.rst \
|
||||
manpages/virtlockd.rst \
|
||||
manpages/virtlogd.rst \
|
||||
$(NULL)
|
||||
endif ! WITH_LIBVIRTD
|
||||
if WITH_HOST_VALIDATE
|
||||
manpages1_rst += manpages/virt-host-validate.rst
|
||||
else ! WITH_HOST_VALIDATE
|
||||
manpages_rst += manpages/virt-host-validate.rst
|
||||
endif ! WITH_HOST_VALIDATE
|
||||
if WITH_LOGIN_SHELL
|
||||
manpages1_rst += manpages/virt-login-shell.rst
|
||||
else ! WITH_LOGIN_SHELL
|
||||
manpages_rst += manpages/virt-login-shell.rst
|
||||
endif ! WITH_LOGIN_SHELL
|
||||
if WITH_SANLOCK
|
||||
manpages8_rst += manpages/virt-sanlock-cleanup.rst
|
||||
else ! WITH_SANLOCK
|
||||
manpages_rst += manpages/virt-sanlock-cleanup.rst
|
||||
endif ! WITH_SANLOCK
|
||||
if WITH_QEMU
|
||||
manpages1_rst += manpages/virt-qemu-run.rst
|
||||
else ! WITH_QEMU
|
||||
manpages_rst += manpages/virt-qemu-run.rst
|
||||
endif ! WITH_QEMU
|
||||
manpages_rst_html_in = \
|
||||
$(manpages_rst:%.rst=%.html.in)
|
||||
manpages_html = \
|
||||
$(manpages_rst_html_in:%.html.in=%.html)
|
||||
|
||||
man1_MANS = $(manpages1_rst:%.rst=%.1)
|
||||
man7_MANS = $(manpages7_rst:%.rst=%.7)
|
||||
man8_MANS = $(manpages8_rst:%.rst=%.8)
|
||||
|
||||
%.1: %.rst
|
||||
$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
|
||||
grep -v '^\.\. contents::' < $< | \
|
||||
sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
|
||||
-e 's|RUNSTATEDIR|$(runstatedir)|g' | \
|
||||
$(RST2MAN) --strict > $@ || { rm $@ && exit 1; }
|
||||
|
||||
%.7: %.rst
|
||||
$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
|
||||
grep -v '^\.\. contents::' < $< | \
|
||||
sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
|
||||
-e 's|RUNSTATEDIR|$(runstatedir)|g' | \
|
||||
$(RST2MAN) --strict > $@ || { rm $@ && exit 1; }
|
||||
|
||||
%.8: %.rst
|
||||
$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
|
||||
grep -v '^\.\. contents::' < $< | \
|
||||
sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
|
||||
-e 's|RUNSTATEDIR|$(runstatedir)|g' | \
|
||||
$(RST2MAN) --strict > $@ || { rm $@ && exit 1; }
|
||||
|
||||
manpages/virkeycode-%.rst: $(top_srcdir)/src/keycodemapdb/data/keymaps.csv \
|
||||
$(top_srcdir)/src/keycodemapdb/tools/keymap-gen Makefile.am
|
||||
$(AM_V_GEN)export NAME=`echo $@ | \
|
||||
sed -e 's,manpages/virkeycode-,,' -e 's,\.rst,,'` && \
|
||||
$(MKDIR_P) manpages/ && \
|
||||
$(RUNUTF8) $(PYTHON) $(top_srcdir)/src/keycodemapdb/tools/keymap-gen \
|
||||
code-docs \
|
||||
--lang rst \
|
||||
--title "virkeycode-$$NAME" \
|
||||
--subtitle "Key code values for $$NAME" \
|
||||
$(top_srcdir)/src/keycodemapdb/data/keymaps.csv $$NAME > $@
|
||||
|
||||
manpages/virkeyname-%.rst: $(top_srcdir)/src/keycodemapdb/data/keymaps.csv \
|
||||
$(top_srcdir)/src/keycodemapdb/tools/keymap-gen Makefile.am
|
||||
$(AM_V_GEN)export NAME=`echo $@ | \
|
||||
sed -e 's,manpages/virkeyname-,,' -e 's,\.rst,,'` && \
|
||||
$(MKDIR_P) manpages/ && \
|
||||
$(RUNUTF8) $(PYTHON) $(top_srcdir)/src/keycodemapdb/tools/keymap-gen \
|
||||
name-docs \
|
||||
--lang rst \
|
||||
--title "virkeyname-$$NAME" \
|
||||
--subtitle "Key name values for $$NAME" \
|
||||
$(top_srcdir)/src/keycodemapdb/data/keymaps.csv $$NAME > $@
|
||||
|
||||
manpagesdir = $(HTML_DIR)/manpages
|
||||
manpages_DATA = $(manpages_html)
|
||||
|
||||
# Generate hvsupport.html and news.html first, since they take one extra step.
|
||||
dot_html_generated_in = \
|
||||
hvsupport.html.in \
|
||||
news.html.in
|
||||
dot_html_in = \
|
||||
$(notdir $(wildcard $(srcdir)/*.html.in))
|
||||
dot_rst = \
|
||||
$(notdir $(wildcard $(srcdir)/*.rst))
|
||||
dot_rst_html_in = \
|
||||
$(dot_rst:%.rst=%.html)
|
||||
dot_html = \
|
||||
$(dot_html_generated_in:%.html.in=%.html) \
|
||||
$(dot_html_in:%.html.in=%.html) \
|
||||
$(dot_rst_html_in:%.html.in=%.html)
|
||||
|
||||
htmldir = $(HTML_DIR)
|
||||
html_DATA = $(assets) $(dot_html)
|
||||
|
||||
apidir = $(pkgdatadir)/api
|
||||
api_DATA = \
|
||||
libvirt-api.xml \
|
||||
libvirt-qemu-api.xml \
|
||||
libvirt-lxc-api.xml \
|
||||
libvirt-admin-api.xml
|
||||
|
||||
fig = \
|
||||
libvirt-daemon-arch.fig \
|
||||
libvirt-driver-arch.fig \
|
||||
libvirt-object-model.fig \
|
||||
migration-managed-direct.fig \
|
||||
migration-managed-p2p.fig \
|
||||
migration-native.fig \
|
||||
migration-tunnel.fig \
|
||||
migration-unmanaged-direct.fig
|
||||
|
||||
schemadir = $(pkgdatadir)/schemas
|
||||
schema_DATA = $(wildcard $(srcdir)/schemas/*.rng)
|
||||
|
||||
EXTRA_DIST= \
|
||||
site.xsl subsite.xsl newapi.xsl page.xsl \
|
||||
wrapstring.xsl \
|
||||
$(dot_html_in) $(dot_rst) $(apipng) \
|
||||
$(fig) $(assets) \
|
||||
$(javascript) $(logofiles) \
|
||||
$(internals_html_in) $(internals_rst) $(fonts) \
|
||||
$(kbase_html_in) $(kbase_rst) \
|
||||
$(manpages_rst) \
|
||||
aclperms.htmlinc \
|
||||
$(schema_DATA)
|
||||
|
||||
acl_generated = aclperms.htmlinc
|
||||
|
||||
aclperms.htmlinc: $(top_srcdir)/src/access/viraccessperm.h \
|
||||
$(top_srcdir)/scripts/genaclperms.py Makefile.am
|
||||
$(AM_V_GEN)$(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/genaclperms.py $< > $@
|
||||
|
||||
CLEANFILES = \
|
||||
$(dot_html) \
|
||||
$(apihtml) \
|
||||
$(apiadminhtml) \
|
||||
$(apiqemuhtml) \
|
||||
$(apilxchtml) \
|
||||
$(internals_html) \
|
||||
$(kbase_html) \
|
||||
$(manpages_html) \
|
||||
$(man1_MANS) \
|
||||
$(man7_MANS) \
|
||||
$(manpages7_rst) \
|
||||
$(man8_MANS) \
|
||||
$(api_DATA) \
|
||||
$(dot_html_generated_in) \
|
||||
aclperms.htmlinc
|
||||
|
||||
timestamp="$(shell if test -n "$$SOURCE_DATE_EPOCH"; \
|
||||
then \
|
||||
date -u --date="@$$SOURCE_DATE_EPOCH"; \
|
||||
else \
|
||||
date -u; \
|
||||
fi)"
|
||||
|
||||
hvsupport.html: hvsupport.html.in
|
||||
|
||||
hvsupport.html.in: $(top_srcdir)/scripts/hvsupport.py $(api_DATA) \
|
||||
$(top_srcdir)/src/libvirt_public.syms \
|
||||
$(top_srcdir)/src/libvirt_qemu.syms $(top_srcdir)/src/libvirt_lxc.syms \
|
||||
$(top_srcdir)/src/driver.h
|
||||
$(AM_V_GEN)$(RUNUTF8) $(PYTHON) $(top_srcdir)/scripts/hvsupport.py \
|
||||
$(top_srcdir) $(top_builddir) > $@ || { rm $@ && exit 1; }
|
||||
|
||||
news.html.in: \
|
||||
$(srcdir)/news.xml \
|
||||
$(srcdir)/news-html.xsl
|
||||
$(AM_V_GEN)$(XSLTPROC) --nonet \
|
||||
$(srcdir)/news-html.xsl \
|
||||
$(srcdir)/news.xml \
|
||||
>$@ \
|
||||
|| { rm -f $@; exit 1; };
|
||||
EXTRA_DIST += \
|
||||
$(srcdir)/news.xml \
|
||||
$(srcdir)/news.rng \
|
||||
$(srcdir)/news-html.xsl
|
||||
|
||||
%.png: %.fig
|
||||
convert -rotate 90 $< $@
|
||||
|
||||
manpages/%.html.in: manpages/%.rst
|
||||
$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
|
||||
grep -v '^:Manual ' < $< | \
|
||||
sed -e 's|SYSCONFDIR|$(sysconfdir)|g' \
|
||||
-e 's|RUNSTATEDIR|$(runstatedir)|g' | \
|
||||
$(RST2HTML) --strict > $@ || { rm $@ && exit 1; }
|
||||
|
||||
%.html.in: %.rst
|
||||
$(AM_V_GEN)$(MKDIR_P) `dirname $@` && \
|
||||
$(RST2HTML) --strict $< > $@ || { rm $@ && exit 1; }
|
||||
|
||||
%.html.tmp: %.html.in site.xsl subsite.xsl page.xsl \
|
||||
$(acl_generated)
|
||||
$(AM_V_GEN)name=`echo $@ | sed -e 's/.tmp//'`; \
|
||||
genhtmlin=`echo $@ | sed -e 's/.tmp/.in/'`; \
|
||||
rst=`echo $@ | sed -e 's/.html.tmp/.rst/'`; \
|
||||
src="$$genhtmlin"; \
|
||||
test -f "$$genhtmlin" && src="$$rst"; \
|
||||
dir=`dirname $@` ; \
|
||||
if test "$$dir" = "."; \
|
||||
then \
|
||||
style=site.xsl; \
|
||||
else \
|
||||
$(MKDIR_P) $$dir; \
|
||||
style=subsite.xsl; \
|
||||
fi; \
|
||||
$(XSLTPROC) --stringparam pagename $$name \
|
||||
--stringparam pagesrc $$src \
|
||||
--stringparam builddir '$(abs_top_builddir)' \
|
||||
--stringparam timestamp $(timestamp) --nonet \
|
||||
$(top_srcdir)/docs/$$style $< > $@ \
|
||||
|| { rm $@ && exit 1; }
|
||||
|
||||
%.html: %.html.tmp
|
||||
$(AM_V_GEN)$(XMLLINT) --nonet --format $< > $@ \
|
||||
|| { rm $@ && exit 1; }
|
||||
|
||||
$(apihtml_generated): html/index.html
|
||||
$(apiadminhtml_generated): html/index-admin.html
|
||||
$(apiqemuhtml_generated): html/index-qemu.html
|
||||
$(apilxchtml_generated): html/index-lxc.html
|
||||
|
||||
html/index.html: libvirt-api.xml newapi.xsl page.xsl $(APIBUILD_STAMP)
|
||||
$(AM_V_GEN)$(XSLTPROC) --nonet -o ./ \
|
||||
--stringparam builddir '$(abs_top_builddir)' \
|
||||
--stringparam timestamp $(timestamp) \
|
||||
$(srcdir)/newapi.xsl libvirt-api.xml
|
||||
|
||||
html/index-%.html: libvirt-%-api.xml newapi.xsl page.xsl $(APIBUILD_STAMP)
|
||||
$(AM_V_GEN)$(XSLTPROC) --nonet -o ./ \
|
||||
--stringparam builddir '$(abs_top_builddir)' \
|
||||
--stringparam timestamp $(timestamp) \
|
||||
--stringparam indexfile $(@:html/%=%) \
|
||||
$(srcdir)/newapi.xsl $<
|
||||
|
||||
check-html:
|
||||
$(XMLLINT) --nonet --noout html/*.html
|
||||
|
||||
check-local: check-html
|
||||
|
||||
python_generated_files = \
|
||||
html/libvirt-libvirt-lxc.html \
|
||||
html/libvirt-libvirt-qemu.html \
|
||||
html/libvirt-libvirt-admin.html \
|
||||
html/libvirt-virterror.html \
|
||||
$(api_DATA) \
|
||||
$(NULL)
|
||||
|
||||
APIBUILD=$(top_srcdir)/scripts/apibuild.py
|
||||
APIBUILD_STAMP=apibuild.py.stamp
|
||||
CLEANFILES += $(APIBUILD_STAMP)
|
||||
|
||||
$(python_generated_files): $(APIBUILD_STAMP)
|
||||
|
||||
$(APIBUILD_STAMP): $(top_srcdir)/scripts/apibuild.py \
|
||||
$(top_srcdir)/include/libvirt/libvirt.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-common.h.in \
|
||||
$(top_srcdir)/include/libvirt/libvirt-domain-checkpoint.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-domain-snapshot.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-domain.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-event.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-host.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-interface.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-network.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-nodedev.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-nwfilter.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-secret.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-storage.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-stream.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-lxc.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-qemu.h \
|
||||
$(top_srcdir)/include/libvirt/libvirt-admin.h \
|
||||
$(top_srcdir)/include/libvirt/virterror.h \
|
||||
$(top_srcdir)/src/libvirt.c \
|
||||
$(top_srcdir)/src/libvirt-domain-checkpoint.c \
|
||||
$(top_srcdir)/src/libvirt-domain-snapshot.c \
|
||||
$(top_srcdir)/src/libvirt-domain.c \
|
||||
$(top_srcdir)/src/libvirt-host.c \
|
||||
$(top_srcdir)/src/libvirt-interface.c \
|
||||
$(top_srcdir)/src/libvirt-network.c \
|
||||
$(top_srcdir)/src/libvirt-nodedev.c \
|
||||
$(top_srcdir)/src/libvirt-nwfilter.c \
|
||||
$(top_srcdir)/src/libvirt-secret.c \
|
||||
$(top_srcdir)/src/libvirt-storage.c \
|
||||
$(top_srcdir)/src/libvirt-stream.c \
|
||||
$(top_srcdir)/src/libvirt-lxc.c \
|
||||
$(top_srcdir)/src/libvirt-qemu.c \
|
||||
$(top_srcdir)/src/admin/libvirt-admin.c \
|
||||
$(top_srcdir)/src/util/virerror.c \
|
||||
$(top_srcdir)/src/util/virevent.c \
|
||||
$(top_srcdir)/src/util/virtypedparam-public.c
|
||||
$(AM_V_GEN)srcdir=$(srcdir) builddir=$(builddir) \
|
||||
$(RUNUTF8) $(PYTHON) $(APIBUILD)
|
||||
touch $@
|
||||
100
docs/acl.html.in
100
docs/acl.html.in
@@ -1,100 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Client access control</h1>
|
||||
<p>
|
||||
Libvirt's client access control framework allows administrators
|
||||
to setup fine grained permission rules across client users,
|
||||
managed objects and API operations. This allows client connections
|
||||
to be locked down to a minimal set of privileges.
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="intro">Access control introduction</a></h2>
|
||||
|
||||
<p>
|
||||
In a default configuration, the libvirtd daemon has three levels
|
||||
of access control. All connections start off in an unauthenticated
|
||||
state, where the only API operations allowed are those required
|
||||
to complete authentication. After successful authentication, a
|
||||
connection either has full, unrestricted access to all libvirt
|
||||
API calls, or is locked down to only "read only" operations,
|
||||
according to what socket a client connection originated on.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The access control framework allows authenticated connections to
|
||||
have fine grained permission rules to be defined by the administrator.
|
||||
Every API call in libvirt has a set of permissions that will
|
||||
be validated against the object being used. For example, the
|
||||
<code>virDomainSetSchedulerParametersFlags</code> method will
|
||||
check whether the client user has the <code>write</code>
|
||||
permission on the <code>domain</code> object instance passed
|
||||
in as a parameter. Further permissions will also be checked
|
||||
if certain flags are set in the API call. In addition to
|
||||
checks on the object passed in to an API call, some methods
|
||||
will filter their results. For example the <code>virConnectListAllDomains</code>
|
||||
method will check the <code>search_domains</code> on the <code>connect</code>
|
||||
object, but will also filter the returned <code>domain</code>
|
||||
objects to only those on which the client user has the
|
||||
<code>getattr</code> permission.
|
||||
</p>
|
||||
|
||||
<h2><a id="drivers">Access control drivers</a></h2>
|
||||
|
||||
<p>
|
||||
The access control framework is designed as a pluggable
|
||||
system to enable future integration with arbitrary access
|
||||
control technologies. By default, the <code>none</code>
|
||||
driver is used, which does no access control checks at
|
||||
all. At this time, libvirt ships with support for using
|
||||
<a href="http://www.freedesktop.org/wiki/Software/polkit/">polkit</a> as a real access
|
||||
control driver. To learn how to use the polkit access
|
||||
driver consult <a href="aclpolkit.html">the configuration
|
||||
docs</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The access driver is configured in the <code>libvirtd.conf</code>
|
||||
configuration file, using the <code>access_drivers</code>
|
||||
parameter. This parameter accepts an array of access control
|
||||
driver names. If more than one access driver is requested,
|
||||
then all must succeed in order for access to be granted.
|
||||
To enable 'polkit' as the driver:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# augtool -s set '/files/etc/libvirt/libvirtd.conf/access_drivers[1]' polkit
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
And to reset back to the default (no-op) driver
|
||||
</p>
|
||||
|
||||
|
||||
<pre>
|
||||
# augtool -s rm /files/etc/libvirt/libvirtd.conf/access_drivers
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<strong>Note:</strong> changes to libvirtd.conf require that
|
||||
the libvirtd daemon be restarted.
|
||||
</p>
|
||||
|
||||
<h2><a id="perms">Objects and permissions</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt applies access control to all the main object
|
||||
types in its API. Each object type, in turn, has a set
|
||||
of permissions defined. To determine what permissions
|
||||
are checked for specific API call, consult the
|
||||
<a href="html/index.html">API reference manual</a>
|
||||
documentation for the API in question.
|
||||
</p>
|
||||
|
||||
<div id="include" filename="aclperms.htmlinc"/>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,523 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Polkit access control</h1>
|
||||
|
||||
<p>
|
||||
Libvirt's client <a href="acl.html">access control framework</a> allows
|
||||
administrators to setup fine grained permission rules across client users,
|
||||
managed objects and API operations. This allows client connections
|
||||
to be locked down to a minimal set of privileges. The polkit driver
|
||||
provides a simple implementation of the access control framework.
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="intro">Introduction</a></h2>
|
||||
|
||||
<p>
|
||||
A default install of libvirt will typically use
|
||||
<a href="http://www.freedesktop.org/wiki/Software/polkit/">polkit</a>
|
||||
to authenticate the initial user connection to libvirtd. This is a
|
||||
very coarse grained check though, either allowing full read-write
|
||||
access to all APIs, or just read-only access. The polkit access
|
||||
control driver in libvirt builds on this capability to allow for
|
||||
fine grained control over the operations a user may perform on an
|
||||
object.
|
||||
</p>
|
||||
|
||||
<h2><a id="perms">Permission names</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt <a href="acl.html#perms">object names and permission names</a>
|
||||
are mapped onto polkit action names using the simple pattern:
|
||||
</p>
|
||||
|
||||
<pre>org.libvirt.api.$object.$permission
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The only caveat is that any underscore characters in the
|
||||
object or permission names are converted to hyphens. So,
|
||||
for example, the <code>search_storage_vols</code> permission
|
||||
on the <code>storage_pool</code> object maps to the polkit
|
||||
action:
|
||||
</p>
|
||||
<pre>org.libvirt.api.storage-pool.search-storage-vols
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The default policy for any permission which corresponds to
|
||||
a "read only" operation, is to allow access. All other
|
||||
permissions default to deny access.
|
||||
</p>
|
||||
|
||||
<h2><a id="attrs">Object identity attributes</a></h2>
|
||||
|
||||
<p>
|
||||
To allow polkit authorization rules to be written to match
|
||||
against individual object instances, libvirt provides a number
|
||||
of authorization detail attributes when performing a permission
|
||||
check. The set of attributes varies according to the type
|
||||
of object being checked
|
||||
</p>
|
||||
|
||||
<h3><a id="object_connect">virConnectPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_domain">virDomainPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>domain_name</td>
|
||||
<td>Name of the domain, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>domain_uuid</td>
|
||||
<td>UUID of the domain, globally unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_interface">virInterfacePtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>interface_name</td>
|
||||
<td>Name of the network interface, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>interface_macaddr</td>
|
||||
<td>MAC address of the network interface, not unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_network">virNetworkPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>network_name</td>
|
||||
<td>Name of the network, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>network_uuid</td>
|
||||
<td>UUID of the network, globally unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_node_device">virNodeDevicePtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>node_device_name</td>
|
||||
<td>Name of the node device, unique to the local host</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_nwfilter">virNWFilterPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>nwfilter_name</td>
|
||||
<td>Name of the network filter, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>nwfilter_uuid</td>
|
||||
<td>UUID of the network filter, globally unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_secret">virSecretPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret_uuid</td>
|
||||
<td>UUID of the secret, globally unique</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret_usage_volume</td>
|
||||
<td>Name of the associated volume, if any</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret_usage_ceph</td>
|
||||
<td>Name of the associated Ceph server, if any</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret_usage_target</td>
|
||||
<td>Name of the associated iSCSI target, if any</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret_usage_name</td>
|
||||
<td>Name of the associated TLS secret, if any</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_storage_pool">virStoragePoolPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>pool_name</td>
|
||||
<td>Name of the storage pool, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>pool_uuid</td>
|
||||
<td>UUID of the storage pool, globally unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a id="object_storage_vol">virStorageVolPtr</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Attribute</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>connect_driver</td>
|
||||
<td>Name of the libvirt connection driver</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>pool_name</td>
|
||||
<td>Name of the storage pool, unique to the local host</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>pool_uuid</td>
|
||||
<td>UUID of the storage pool, globally unique</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vol_name</td>
|
||||
<td>Name of the storage volume, unique to the pool</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vol_key</td>
|
||||
<td>Key of the storage volume, globally unique</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2><a id="connect_driver">Hypervisor Driver connect_driver</a></h2>
|
||||
<p>
|
||||
The <code>connect_driver</code> parameter describes the
|
||||
client's <a href="remote.html">remote Connection Driver</a>
|
||||
name based on the <a href="uri.html">URI</a> used for the
|
||||
connection.
|
||||
</p>
|
||||
<p>
|
||||
<span class="since">Since 4.1.0</span>, when calling an API
|
||||
outside the scope of the primary connection driver, the
|
||||
primary driver will attempt to open a secondary connection
|
||||
to the specific API driver in order to process the API. For
|
||||
example, when hypervisor domain processing needs to make an
|
||||
API call within the storage driver or the network filter driver
|
||||
an attempt to open a connection to the "storage" or "nwfilter"
|
||||
driver will be made. Similarly, a "storage" primary connection
|
||||
may need to create a connection to the "secret" driver in order
|
||||
to process secrets for the API. If successful, then calls to
|
||||
those API's will occur in the <code>connect_driver</code> context
|
||||
of the secondary connection driver rather than in the context of
|
||||
the primary driver. This affects the <code>connect_driver</code>
|
||||
returned from rule generation from the <code>action.loookup</code>
|
||||
function. The following table provides a list of the various
|
||||
connection drivers and the <code>connect_driver</code> name
|
||||
used by each regardless of primary or secondary connection.
|
||||
The access denied error message from libvirt will list the
|
||||
connection driver by name that denied the access.
|
||||
</p>
|
||||
|
||||
<h3><a id="object_connect_driver">Connection Driver Name</a></h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Connection Driver</th>
|
||||
<th><code>connect_driver</code> name</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>bhyve</td>
|
||||
<td>bhyve</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>esx</td>
|
||||
<td>ESX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>hyperv</td>
|
||||
<td>Hyper-V</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>interface</td>
|
||||
<td>interface</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>xen</td>
|
||||
<td>Xen</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>lxc</td>
|
||||
<td>LXC</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>network</td>
|
||||
<td>network</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>nodedev</td>
|
||||
<td>nodedev</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>nwfilter</td>
|
||||
<td>NWFilter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>openvz</td>
|
||||
<td>OPENVZ</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>qemu</td>
|
||||
<td>QEMU</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>secret</td>
|
||||
<td>secret</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>storage</td>
|
||||
<td>storage</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vbox</td>
|
||||
<td>VBOX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vmware</td>
|
||||
<td>VMWARE</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vz</td>
|
||||
<td>vz</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<h2><a id="user">User identity attributes</a></h2>
|
||||
|
||||
<p>
|
||||
At this point in time, the only attribute provided by
|
||||
libvirt to identify the user invoking the operation
|
||||
is the PID of the client program. This means that the
|
||||
polkit access control driver is only useful if connections
|
||||
to libvirt are restricted to its UNIX domain socket. If
|
||||
connections are being made to a TCP socket, no identifying
|
||||
information is available and access will be denied.
|
||||
Also note that if the client is connecting via an SSH
|
||||
tunnel, it is the local SSH user that will be identified.
|
||||
In future versions, it is expected that more information
|
||||
about the client user will be provided, including the
|
||||
SASL / Kerberos username and/or x509 distinguished
|
||||
name obtained from the authentication provider in use.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="checks">Writing access control policies</a></h2>
|
||||
|
||||
<p>
|
||||
If using versions of polkit prior to 0.106 then it is only
|
||||
possible to validate (user, permission) pairs via the <code>.pkla</code>
|
||||
files. Fully validation of the (user, permission, object) triple
|
||||
requires the new JavaScript <code>.rules</code> support that
|
||||
was introduced in version 0.106. The latter is what will be
|
||||
described here.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Libvirt does not ship any rules files by default. It merely
|
||||
provides a definition of the default behaviour for each
|
||||
action (permission). As noted earlier, permissions which
|
||||
correspond to read-only operations in libvirt will be allowed
|
||||
to all users by default; everything else is denied by default.
|
||||
Defining custom rules requires creation of a file in the
|
||||
<code>/etc/polkit-1/rules.d</code> directory with a name
|
||||
chosen by the administrator (<code>100-libvirt-acl.rules</code>
|
||||
would be a reasonable choice). See the <code>polkit(8)</code>
|
||||
manual page for a description of how to write these files
|
||||
in general. The key idea is to create a file containing
|
||||
something like
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
polkit.addRule(function(action, subject) {
|
||||
....logic to check 'action' and 'subject'...
|
||||
});
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In this code snippet above, the <code>action</code> object
|
||||
instance will represent the libvirt permission being checked
|
||||
along with identifying attributes for the object it is being
|
||||
applied to. The <code>subject</code> meanwhile will identify
|
||||
the libvirt client app (with the caveat above about it only
|
||||
dealing with local clients connected via the UNIX socket).
|
||||
On the <code>action</code> object, the permission name is
|
||||
accessible via the <code>id</code> attribute, while the
|
||||
object identifying attributes are exposed via the
|
||||
<code>lookup</code> method.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
See
|
||||
<a href="https://libvirt.org/git/?p=libvirt.git;a=tree;f=examples/polkit;hb=HEAD">source code</a>
|
||||
for a more complex example.
|
||||
</p>
|
||||
|
||||
<h3><a id="exconnect">Example: restricting ability to connect to drivers</a></h3>
|
||||
|
||||
<p>
|
||||
Consider a local user <code>berrange</code>
|
||||
who has been granted permission to connect to libvirt in
|
||||
full read-write mode. The goal is to only allow them to
|
||||
use the <code>QEMU</code> driver and not the Xen or LXC
|
||||
drivers which are also available in libvirtd.
|
||||
To achieve this we need to write a rule which checks
|
||||
whether the <code>connect_driver</code> attribute
|
||||
is <code>QEMU</code>, and match on an action
|
||||
name of <code>org.libvirt.api.connect.getattr</code>. Using
|
||||
the javascript rules format, this ends up written as
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
polkit.addRule(function(action, subject) {
|
||||
if (action.id == "org.libvirt.api.connect.getattr" &&
|
||||
subject.user == "berrange") {
|
||||
if (action.lookup("connect_driver") == 'QEMU') {
|
||||
return polkit.Result.YES;
|
||||
} else {
|
||||
return polkit.Result.NO;
|
||||
}
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
|
||||
<h3><a id="exdomain">Example: restricting access to a single domain</a></h3>
|
||||
|
||||
<p>
|
||||
Consider a local user <code>berrange</code>
|
||||
who has been granted permission to connect to libvirt in
|
||||
full read-write mode. The goal is to only allow them to
|
||||
see the domain called <code>demo</code> on the LXC driver.
|
||||
To achieve this we need to write a rule which checks
|
||||
whether the <code>connect_driver</code> attribute
|
||||
is <code>LXC</code> and the <code>domain_name</code>
|
||||
attribute is <code>demo</code>, and match on an action
|
||||
name of <code>org.libvirt.api.domain.getattr</code>. Using
|
||||
the javascript rules format, this ends up written as
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
polkit.addRule(function(action, subject) {
|
||||
if (action.id == "org.libvirt.api.domain.getattr" &&
|
||||
subject.user == "berrange") {
|
||||
if (action.lookup("connect_driver") == 'LXC' &&
|
||||
action.lookup("domain_name") == 'demo') {
|
||||
return polkit.Result.YES;
|
||||
} else {
|
||||
return polkit.Result.NO;
|
||||
}
|
||||
}
|
||||
});
|
||||
</pre>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,178 +0,0 @@
|
||||
=========================
|
||||
Advanced test suite usage
|
||||
=========================
|
||||
|
||||
The basic requirement before submitting changes to libvirt is that
|
||||
|
||||
::
|
||||
|
||||
$ make check
|
||||
$ make syntax-check
|
||||
|
||||
succeed after each commit.
|
||||
|
||||
The libvirt test suite, however, support additional features: for
|
||||
example, it's possible to look for memory leaks and similar issues
|
||||
by running
|
||||
|
||||
::
|
||||
|
||||
$ 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
|
||||
|
||||
If you encounter any failing tests, the VIR_TEST_DEBUG
|
||||
environment variable may provide extra information to debug the
|
||||
failures. Larger values of 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 VIR_TEST_RANGE.
|
||||
I.e. to run all tests from 3 to 20 with the exception of tests
|
||||
6 and 16, use:
|
||||
|
||||
::
|
||||
|
||||
$ VIR_TEST_DEBUG=1 VIR_TEST_RANGE=3-5,7-20,^16 ./run 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.
|
||||
|
||||
When running our test suite it may happen that the test result
|
||||
is nondeterministic because of the test suite relying on a
|
||||
particular file in the system being accessible or having some
|
||||
specific value. To catch this kind of errors, the test suite
|
||||
has a module for that prints any path touched that fulfils
|
||||
constraints described above into a file. To enable it just set
|
||||
``VIR_TEST_FILE_ACCESS`` environment variable. Then
|
||||
``VIR_TEST_FILE_ACCESS_OUTPUT`` environment variable can alter
|
||||
location where the file is stored.
|
||||
|
||||
::
|
||||
|
||||
$ VIR_TEST_FILE_ACCESS=1 VIR_TEST_FILE_ACCESS_OUTPUT="/tmp/file_access.txt" ./qemuxml2argvtest
|
||||
|
||||
#. 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*
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
380
docs/api.html.in
380
docs/api.html.in
@@ -1,380 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>The libvirt API concepts</h1>
|
||||
|
||||
<p> This page describes the main principles and architecture choices
|
||||
behind the definition of the libvirt API:</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="Objects">Objects Exposed</a></h2>
|
||||
<p> As defined in the <a href="goals.html">goals section</a>, the libvirt
|
||||
API is designed to expose all the resources needed to manage the
|
||||
virtualization support of recent operating systems. The first object
|
||||
manipulated through the API is the <code>virConnectPtr</code>, which
|
||||
represents the connection to a hypervisor. Any application using libvirt
|
||||
is likely to start using the
|
||||
API by calling one of <a href="html/libvirt-libvirt-host.html#virConnectOpen"
|
||||
>the virConnectOpen functions</a>. You will note that those functions take
|
||||
a name argument which is actually a <a href="uri.html">connection URI</a>
|
||||
to select the right hypervisor to open.
|
||||
A URI is needed to allow remote connections and also select between
|
||||
different possible hypervisors. For example, on a Linux system it may be
|
||||
possible to use both KVM and LinuxContainers on the same node. A NULL
|
||||
name will default to a preselected hypervisor, but it's probably not a
|
||||
wise thing to do in most cases. See the <a href="uri.html">connection
|
||||
URI</a> page for a full descriptions of the values allowed.</p>
|
||||
<p> OnDevice the application obtains a
|
||||
<a href="/html/libvirt-libvirt-host.html#virConnectPtr">
|
||||
<code>virConnectPtr</code>
|
||||
</a>
|
||||
connection to the hypervisor it can then use it to manage the hypervisor's
|
||||
available domains and related virtualization
|
||||
resources, such as storage and networking. All those are
|
||||
exposed as first class objects and connected to the hypervisor connection
|
||||
(and the node or cluster where it is available).</p>
|
||||
<p class="image">
|
||||
<img alt="first class objects exposed by the API"
|
||||
src="libvirt-object-model.png"/>
|
||||
</p>
|
||||
<p> The figure above shows the five main objects exported by the API:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-host.html#virConnectPtr">
|
||||
<code>virConnectPtr</code>
|
||||
</a>
|
||||
<p>Represents the connection to a hypervisor. Use one of the
|
||||
<a href="html/libvirt-libvirt-host.html#virConnectOpen">virConnectOpen</a>
|
||||
functions to obtain connection to the hypervisor which is then used
|
||||
as a parameter to other connection API's.</p></li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainPtr">
|
||||
<code>virDomainPtr</code>
|
||||
</a>
|
||||
<p>Represents one domain either active or defined (i.e. existing as
|
||||
permanent config file and storage but not currently running on that
|
||||
node). The function
|
||||
<a href="html/libvirt-libvirt-domain.html#virConnectListAllDomains">
|
||||
<code>virConnectListAllDomains</code>
|
||||
</a>
|
||||
lists all the domains for the hypervisor.</p></li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virNetworkPtr">
|
||||
<code>virNetworkPtr</code>
|
||||
</a>
|
||||
<p>Represents one network either active or defined (i.e. existing
|
||||
as permanent config file and storage but not currently activated).
|
||||
The function
|
||||
<a href="html/libvirt-libvirt-network.html#virConnectListAllNetworks">
|
||||
<code>virConnectListAllNetworks</code>
|
||||
</a>
|
||||
lists all the virtualization networks for the hypervisor.</p></li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStorageVolPtr">
|
||||
<code>virStorageVolPtr</code>
|
||||
</a>
|
||||
<p>Represents one storage volume generally used
|
||||
as a block device available to one of the domains. The function
|
||||
<a href="html/libvirt-libvirt-storage.html#virStorageVolLookupByPath">
|
||||
<code>virStorageVolLookupByPath</code>
|
||||
</a>
|
||||
finds the storage volume object based on its path on the node.</p></li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStoragePoolPtr">
|
||||
<code>virStoragePoolPtr</code>
|
||||
</a>
|
||||
<p>Represents a storage pool, which is a logical area
|
||||
used to allocate and store storage volumes. The function
|
||||
<a href="html/libvirt-libvirt-storage.html#virConnectListAllStoragePools">
|
||||
<code>virConnectListAllStoragePools</code>
|
||||
</a>
|
||||
lists all of the virtualization storage pools on the hypervisor.
|
||||
The function
|
||||
<a href="html/libvirt-libvirt-storage.html#virStoragePoolLookupByVolume">
|
||||
<code>virStoragePoolLookupByVolume</code>
|
||||
</a>
|
||||
finds the storage pool containing a given storage volume.</p></li>
|
||||
</ul>
|
||||
<p> Most objects manipulated by the library can also be represented using
|
||||
XML descriptions. This is used primarily to create those object, but is
|
||||
also helpful to modify or save their description back.</p>
|
||||
<p> Domains, networks, and storage pools can be either <code>active</code>
|
||||
i.e. either running or available for immediate use, or
|
||||
<code>defined</code> in which case they are inactive but there is
|
||||
a permanent definition available in the system for them. Based on this
|
||||
they can be activated dynamically in order to be used.</p>
|
||||
<p> Most objects can also be named in various ways:</p>
|
||||
<ul>
|
||||
<li><code>name</code>
|
||||
<p>A user friendly identifier but whose uniqueness
|
||||
cannot be guaranteed between two nodes.</p></li>
|
||||
<li><code>ID</code>
|
||||
<p>A runtime unique identifier
|
||||
provided by the hypervisor for one given activation of the object;
|
||||
however, it becomes invalid once the resource is deactivated.</p></li >
|
||||
<li><code>UUID</code>
|
||||
<p> A 16 byte unique identifier
|
||||
as defined in <a href="http://www.ietf.org/rfc/rfc4122.txt">RFC 4122</a>,
|
||||
which is guaranteed to be unique for long term usage and across a
|
||||
set of nodes.</p></li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="Functions">Functions and Naming Conventions</a></h2>
|
||||
<p> The naming of the functions present in the library is usually
|
||||
composed by a prefix describing the object associated to the function
|
||||
and a verb describing the action on that object.</p>
|
||||
<p> For each first class object you will find APIs
|
||||
for the following actions:</p>
|
||||
<ul>
|
||||
<li><b>Lookup</b> [...LookupBy...]
|
||||
<p>Used to perform lookups on objects by some type of identifier,
|
||||
such as:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainLookupByID">
|
||||
<code>virDomainLookupByID</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainLookupByName">
|
||||
<code>virDomainLookupByName</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainLookupByUUID">
|
||||
<code>virDomainLookupByUUID</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainLookupByUUIDString">
|
||||
<code>virDomainLookupByUUIDString</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><b>Enumeration</b> [virConnectList..., virConnectNumOf...]
|
||||
<p>Used to enumerate a set of object available to a given
|
||||
hypervisor connection such as:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virConnectListDomains">
|
||||
<code>virConnectListDomains</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virConnectNumOfDomains">
|
||||
<code>virConnectNumOfDomains</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virConnectListNetworks">
|
||||
<code>virConnectListNetworks</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virConnectListStoragePools">
|
||||
<code>virConnectListStoragePools</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><b>Description</b> [...GetInfo]
|
||||
<p>Generic accessor providing a set of generic information about an
|
||||
object, such as: </p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-host.html#virNodeGetInfo">
|
||||
<code>virNodeGetInfo</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainGetInfo">
|
||||
<code>virDomainGetInfo</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStoragePoolGetInfo">
|
||||
<code>virStoragePoolGetInfo</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStorageVolGetInfo">
|
||||
<code>virStorageVolGetInfo</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><b>Accessors</b> [...Get..., ...Set...]
|
||||
<p>Specific accessors used to query or modify data for the given object,
|
||||
such as: </p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-host.html#virConnectGetType">
|
||||
<code>virConnectGetType</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainGetMaxMemory">
|
||||
<code>virDomainGetMaxMemory</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainSetMemory">
|
||||
<code>virDomainSetMemory</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainGetVcpus">
|
||||
<code>virDomainGetVcpus</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStoragePoolSetAutostart">
|
||||
<code>virStoragePoolSetAutostart</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virNetworkGetBridgeName">
|
||||
<code>virNetworkGetBridgeName</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><b>Creation</b> [...Create, ...CreateXML]
|
||||
<p>Used to create and start objects. The ...CreateXML APIs will create
|
||||
the object based on an XML description, while the ...Create APIs will
|
||||
create the object based on existing object pointer, such as: </p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainCreate">
|
||||
<code>virDomainCreate</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainCreateXML">
|
||||
<code>virDomainCreateXML</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virNetworkCreate">
|
||||
<code>virNetworkCreate</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virNetworkCreateXML">
|
||||
<code>virNetworkCreateXML</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><b>Destruction</b> [...Destroy]
|
||||
<p>Used to shutdown or deactivate and destroy objects, such as: </p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-domain.html#virDomainDestroy">
|
||||
<code>virDomainDestroy</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-network.html#virNetworkDestroy">
|
||||
<code>virNetworkDestroy</code>
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="html/libvirt-libvirt-storage.html#virStoragePoolDestroy">
|
||||
<code>virStoragePoolDestroy</code>
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<p>Note: functions returning vir*Ptr (like the virDomainLookup functions)
|
||||
allocate memory which needs to be freed by the caller by the corresponding
|
||||
vir*Free function (e.g. virDomainFree for a virDomainPtr object).
|
||||
</p>
|
||||
<p> For more in-depth details of the storage related APIs see
|
||||
<a href="storage.html">the storage management page</a>.
|
||||
</p>
|
||||
<h2><a id="Drivers">The libvirt Drivers</a></h2>
|
||||
<p>Drivers are the basic building block for libvirt functionality
|
||||
to support the capability to handle specific hypervisor driver calls.
|
||||
Drivers are discovered and registered during connection processing as
|
||||
part of the
|
||||
<a href="html/libvirt-libvirt-host.html#virInitialize">
|
||||
<code>virInitialize</code>
|
||||
</a>
|
||||
API. Each driver
|
||||
has a registration API which loads up the driver specific function
|
||||
references for the libvirt APIs to call. The following is a simplistic
|
||||
view of the hypervisor driver mechanism. Consider the stacked list of
|
||||
drivers as a series of modules that can be plugged into the architecture
|
||||
depending on how libvirt is configured to be built.</p>
|
||||
<p class="image">
|
||||
<img alt="The libvirt driver architecture"
|
||||
src="libvirt-driver-arch.png"/>
|
||||
</p>
|
||||
<p>The driver architecture is also used to support other virtualization
|
||||
components such as storage, storage pools, host device, networking,
|
||||
network interfaces, and network filters.</p>
|
||||
<p>See the <a href="drivers.html">libvirt drivers</a> page for more
|
||||
information on hypervisor and storage specific drivers.</p>
|
||||
<p>Not all drivers support every virtualization function possible.
|
||||
The <a href="hvsupport.html">libvirt API support matrix</a> lists
|
||||
the various functions and support found in each driver by the version
|
||||
support was added into libvirt.
|
||||
</p>
|
||||
<h2><a id="Remote">Daemon and Remote Access</a></h2>
|
||||
<p>Access to libvirt drivers is primarily handled by the libvirtd
|
||||
daemon through the <a href="remote.html">remote</a> driver via an
|
||||
<a href="internals/rpc.html">RPC</a>. Some hypervisors do support
|
||||
client-side connections and responses, such as Test, OpenVZ, VMware,
|
||||
VirtualBox (vbox), ESX, Hyper-V, Xen, and Virtuozzo.
|
||||
The libvirtd daemon service is started on the host at system boot
|
||||
time and can also be restarted at any time by a properly privileged
|
||||
user, such as root. The libvirtd daemon uses the same libvirt API
|
||||
<a href="html/libvirt-libvirt-host.html#virInitialize">
|
||||
<code>virInitialize</code>
|
||||
</a>
|
||||
sequence as applications
|
||||
for client-side driver registrations, but then extends the registered
|
||||
driver list to encompass all known drivers supported for all driver
|
||||
types supported on the host. </p>
|
||||
<p>The libvirt client <a href="apps.html">applications</a> use a
|
||||
<a href="uri.html">URI</a> to obtain the <code>virConnectPtr</code>.
|
||||
The <code>virConnectPtr</code> keeps track of the driver connection
|
||||
plus a variety of other connections (network, interface, storage, etc.).
|
||||
The <code>virConnectPtr</code> is then used as a parameter to other
|
||||
virtualization <a href="#Functions">functions</a>. Depending upon the
|
||||
driver being used, calls will be routed through the remote driver to
|
||||
the libvirtd daemon. The daemon will reference the connection specific
|
||||
driver in order to retrieve the requested information and then pass
|
||||
back status and/or data through the connection back to the application.
|
||||
The application can then decide what to do with that data, such as
|
||||
display, write log data, etc. <a href="migration.html">Migration</a>
|
||||
is an example of many facets of the architecture in use.</p>
|
||||
|
||||
<p class="image">
|
||||
<img alt="The libvirt daemon and remote architecture"
|
||||
src="libvirt-daemon-arch.png"/>
|
||||
</p>
|
||||
<p>
|
||||
The key takeaway from the above diagram is that there is a remote driver
|
||||
which handles transactions for a majority of the drivers. The libvirtd
|
||||
daemon running on the host will receive transaction requests from the
|
||||
remote driver and will then query the hypervisor driver as specified in
|
||||
the <code>virConnectPtr</code> in order to fetch the data. The data will
|
||||
then be returned through the remote driver to the client application
|
||||
for processing.
|
||||
</p>
|
||||
<p>If you are interested in contributing to libvirt, read the
|
||||
<a href="http://wiki.libvirt.org/page/FAQ">FAQ</a> and
|
||||
<a href="hacking.html">hacking</a> guidelines to gain an understanding
|
||||
of basic rules and guidelines. In order to add new API functionality
|
||||
follow the instructions regarding
|
||||
<a href="api_extension.html">implementing a new API in libvirt</a>.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,371 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Implementing a new API in Libvirt</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
This document walks you through the process of implementing a new
|
||||
API in libvirt. Remember that new API consists of any new public
|
||||
functions, as well as the addition of flags or extensions of XML used by
|
||||
existing functions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Before you begin coding, it is critical that you propose your
|
||||
changes on the libvirt mailing list and get feedback on your ideas to
|
||||
make sure what you're proposing fits with the general direction of the
|
||||
project. Even before doing a proof of concept implementation, send an
|
||||
email giving an overview of the functionality you think should be
|
||||
added to libvirt. Someone may already be working on the feature you
|
||||
want. Also, recognize that everything you write is likely to undergo
|
||||
significant rework as you discuss it with the other developers, so
|
||||
don't wait too long before getting feedback.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Adding a new API to libvirt is not difficult, but there are quite a
|
||||
few steps. This document assumes that you are familiar with C
|
||||
programming and have checked out the libvirt code from the source code
|
||||
repository and successfully built the existing tree. Instructions on
|
||||
how to check out and build the code can be found at:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<a href="https://libvirt.org/downloads.html">https://libvirt.org/downloads.html</a>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Once you have a working development environment, the steps to create a
|
||||
new API are:
|
||||
</p>
|
||||
<ol>
|
||||
<li>define the public API</li>
|
||||
<li>define the internal driver API</li>
|
||||
<li>implement the public API</li>
|
||||
<li>implement the remote protocol:
|
||||
<ol>
|
||||
<li>define the wire protocol format</li>
|
||||
<li>implement the RPC client</li>
|
||||
<li>implement the server side dispatcher</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li>use new API where appropriate in drivers</li>
|
||||
<li>add virsh support</li>
|
||||
<li>add common handling for new API</li>
|
||||
<li>for each driver that can support the new API:
|
||||
<ol>
|
||||
<li>add prerequisite support</li>
|
||||
<li>fully implement new API</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
It is, of course, possible to implement the pieces in any order, but
|
||||
if the development tasks are completed in the order listed, the code
|
||||
will compile after each step. Given the number of changes required,
|
||||
verification after each step is highly recommended.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Submit new code in the form of one patch per step. That's not to say
|
||||
submit patches before you have working functionality--get the whole thing
|
||||
working and make sure you're happy with it. Then use git to break the
|
||||
changes into pieces so you don't drop a big blob of code on the
|
||||
mailing list in one go. Also, you should follow the upstream tree, and
|
||||
rebase your series to adapt your patches to work with any other changes
|
||||
that were accepted upstream during your development.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Don't mix anything else into the patches you submit. The patches
|
||||
should be the minimal changes required to implement the functionality
|
||||
you're adding. If you notice a bug in unrelated code (i.e., code you
|
||||
don't have to touch to implement your API change) during development,
|
||||
create a patch that just addresses that bug and submit it
|
||||
separately.
|
||||
</p>
|
||||
|
||||
<h2><a id='publicapi'>Defining the public API</a></h2>
|
||||
|
||||
<p>The first task is to define the public API. If the new API
|
||||
involves an XML extension, you have to enhance the RelaxNG
|
||||
schema and document the new elements or attributes:</p>
|
||||
|
||||
<p><code>
|
||||
docs/schemas/domaincommon.rng<br/>
|
||||
docs/formatdomain.html.in
|
||||
</code></p>
|
||||
|
||||
<p>If the API extension involves a new function, you have to add a
|
||||
declaration in the public header, and arrange to export the
|
||||
function name (symbol) so other programs can link against the
|
||||
libvirt library and call the new function:</p>
|
||||
|
||||
<p><code>
|
||||
include/libvirt/libvirt-$MODULE.h.in
|
||||
src/libvirt_public.syms
|
||||
</code></p>
|
||||
|
||||
<p>
|
||||
This task is in many ways the most important to get right, since once
|
||||
the API has been committed to the repository, it's libvirt's policy
|
||||
never to change it. Mistakes in the implementation are bugs that you
|
||||
can fix. Make a mistake in the API definition and you're stuck with
|
||||
it, so think carefully about the interface and don't be afraid to
|
||||
rework it as you go through the process of implementing it.
|
||||
</p>
|
||||
|
||||
<h2><a id='internalapi'>Defining the internal API</a></h2>
|
||||
|
||||
<p>
|
||||
Each public API call is associated with a driver, such as a host
|
||||
virtualization driver, a network virtualization driver, a storage
|
||||
virtualization driver, a state driver, or a device monitor. Adding
|
||||
the internal API is ordinarily a matter of adding a new member to the
|
||||
struct representing one of these drivers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Of course, it's possible that the new API will involve the creation of
|
||||
an entirely new driver type, in which case the changes will include the
|
||||
creation of a new struct type to represent the new driver type.
|
||||
</p>
|
||||
|
||||
<p>The driver structs are defined in:</p>
|
||||
|
||||
<p><code>src/driver-$MODULE.h</code></p>
|
||||
|
||||
<p>
|
||||
To define the internal API, first typedef the driver function
|
||||
prototype and then add a new field for it to the relevant driver
|
||||
struct. Then, update all existing instances of the driver to
|
||||
provide a <code>NULL</code> stub for the new function.
|
||||
</p>
|
||||
|
||||
<h2><a id='implpublic'>Implementing the public API</a></h2>
|
||||
|
||||
<p>
|
||||
Implementing the public API is largely a formality in which we wire up
|
||||
public API to the internal driver API. The public API implementation
|
||||
takes care of some basic validity checks before passing control to the
|
||||
driver implementation. In RFC 2119 vocabulary, this function:
|
||||
</p>
|
||||
|
||||
<ol class="ordinarylist">
|
||||
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
|
||||
being called and its parameters;</li>
|
||||
<li>MUST call virResetLastError();</li>
|
||||
<li>SHOULD confirm that the connection is valid with
|
||||
virCheckConnectReturn() or virCheckConnectGoto();</li>
|
||||
<li><strong>SECURITY: If the API requires a connection with write
|
||||
privileges, MUST confirm that the connection flags do not
|
||||
indicate that the connection is read-only with
|
||||
virCheckReadOnlyGoto();</strong></li>
|
||||
<li>SHOULD do basic validation of the parameters that are being
|
||||
passed in, using helpers like virCheckNonNullArgGoto();</li>
|
||||
<li>MUST confirm that the driver for this connection exists and that
|
||||
it implements this function;</li>
|
||||
<li>MUST call the internal API;</li>
|
||||
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
|
||||
returning, its return value, and status.</li>
|
||||
<li>MUST return status to the caller.</li>
|
||||
</ol>
|
||||
|
||||
<p>The public API calls are implemented in:</p>
|
||||
|
||||
<p><code>src/libvirt-$MODULE.c</code></p>
|
||||
|
||||
<h2><a id='remoteproto'>Implementing the remote protocol</a></h2>
|
||||
|
||||
<p>
|
||||
Implementing the remote protocol is essentially a
|
||||
straightforward exercise which is probably most easily
|
||||
understood by referring to the existing code.
|
||||
</p>
|
||||
|
||||
<h3><a id='wireproto'>Defining the wire protocol format</a></h3>
|
||||
|
||||
<p>
|
||||
Defining the wire protocol involves making additions to:
|
||||
</p>
|
||||
|
||||
<p><code>src/remote/remote_protocol.x</code></p>
|
||||
|
||||
<p>
|
||||
First, create two new structs for each new function that you're adding
|
||||
to the API. One struct describes the parameters to be passed to the
|
||||
remote function, and a second struct describes the value returned by
|
||||
the remote function. The one exception to this rule is that functions
|
||||
that return only 0 or -1 for status do not require a struct for returned
|
||||
data.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Second, add values to the remote_procedure enum for each new function
|
||||
added to the API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Once these changes are in place, it's necessary to run 'make rpcgen'
|
||||
in the src directory to create the .c and .h files required by the
|
||||
remote protocol code. This must be done on a Linux host using the
|
||||
GLibC rpcgen program. Other rpcgen versions may generate code which
|
||||
results in bogus compile time warnings. This regenerates the
|
||||
following files:
|
||||
</p>
|
||||
|
||||
<p><code>
|
||||
src/remote/remote_daemon_dispatch_stubs.h
|
||||
src/remote/remote_daemon_dispatch.h
|
||||
src/remote/remote_daemon_dispatch.c
|
||||
src/remote/remote_protocol.c
|
||||
src/remote/remote_protocol.h
|
||||
</code></p>
|
||||
|
||||
<h3><a id='rpcclient'>Implement the RPC client</a></h3>
|
||||
|
||||
<p>
|
||||
Implementing the RPC client uses the rpcgen generated .h files.
|
||||
The remote method calls go in:
|
||||
</p>
|
||||
|
||||
<p><code>src/remote/remote_driver.c</code></p>
|
||||
|
||||
<p>Each remote method invocation does the following:</p>
|
||||
|
||||
<ol class="ordinarylist">
|
||||
<li>locks the remote driver;</li>
|
||||
<li>sets up the method arguments;</li>
|
||||
<li>invokes the remote function;</li>
|
||||
<li>checks the return value, if necessary;</li>
|
||||
<li>extracts any returned data;</li>
|
||||
<li>frees any returned data;</li>
|
||||
<li>unlocks the remote driver.</li>
|
||||
</ol>
|
||||
|
||||
<h3><a id="serverdispatch">Implement the server side dispatcher</a></h3>
|
||||
|
||||
<p>
|
||||
Implementing the server side of the remote function call is simply a
|
||||
matter of deserializing the parameters passed in from the remote
|
||||
caller and passing them to the corresponding internal API function.
|
||||
The server side dispatchers are implemented in:
|
||||
</p>
|
||||
|
||||
<p><code>src/remote/remote_daemon_dispatch.c</code></p>
|
||||
|
||||
<p>Again, this step uses the .h files generated by make rpcgen.</p>
|
||||
|
||||
<p>
|
||||
After all three pieces of the remote protocol are complete, and
|
||||
the generated files have been updated, it will be necessary to
|
||||
update the file:</p>
|
||||
|
||||
<p><code>src/remote_protocol-structs</code></p>
|
||||
|
||||
<p>
|
||||
This file should only have new lines added; modifications to
|
||||
existing lines probably imply a backwards-incompatible API change.
|
||||
</p>
|
||||
|
||||
<h2><a id="internaluseapi">Use the new API internally</a></h2>
|
||||
|
||||
<p>
|
||||
Sometimes, a new API serves as a superset of existing API, by
|
||||
adding more granularity in what can be managed. When this is
|
||||
the case, it makes sense to share a common implementation by
|
||||
making the older API become a trivial wrapper around the new
|
||||
API, rather than duplicating the common code. This step should
|
||||
not introduce any semantic differences for the old API, and is
|
||||
not necessary if the new API has no relation to existing API.
|
||||
</p>
|
||||
|
||||
<h2><a id="virshuseapi">Expose the new API in virsh</a></h2>
|
||||
|
||||
<p>
|
||||
All new API should be manageable from the virsh command line
|
||||
shell. This proves that the API is sufficient for the intended
|
||||
purpose, and helps to identify whether the proposed API needs
|
||||
slight changes for easier usage. However, remember that virsh
|
||||
is used to connect to hosts running older versions of libvirtd,
|
||||
so new commands should have fallbacks to an older API if
|
||||
possible; implementing the virsh hooks at this point makes it
|
||||
very easy to test these fallbacks. Also remember to document
|
||||
virsh additions.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A virsh command is composed of a few pieces of code. You need to
|
||||
define an array of vshCmdInfo structs for each new command that
|
||||
contain the help text and the command description text. You also need
|
||||
an array of vshCmdOptDef structs to describe the command options.
|
||||
Once you have those pieces in place you can write the function
|
||||
implementing the virsh command. Finally, you need to add the new
|
||||
command to the commands[] array. The following files need changes:
|
||||
</p>
|
||||
|
||||
<p><code>
|
||||
tools/virsh-$MODULE.c<br/>
|
||||
tools/virsh.pod
|
||||
</code></p>
|
||||
|
||||
<h2><a id="driverimpl">Implement the driver methods</a></h2>
|
||||
|
||||
<p>
|
||||
So, after all that, we get to the fun part. All functionality in
|
||||
libvirt is implemented inside a driver. Thus, here is where you
|
||||
implement whatever functionality you're adding to libvirt. You'll
|
||||
either need to add additional files to the src directory or extend
|
||||
files that are already there, depending on what functionality you're
|
||||
adding.
|
||||
</p>
|
||||
|
||||
<h3><a id="commonimpl">Implement common handling</a></h3>
|
||||
|
||||
<p>
|
||||
If the new API is applicable to more than one driver, it may
|
||||
make sense to provide some utility routines, or to factor some
|
||||
of the work into the dispatcher, to avoid reimplementing the
|
||||
same code in every driver. In the example code, this involved
|
||||
adding a member to the virDomainDefPtr struct for mapping
|
||||
between the XML API addition and the in-memory representation of
|
||||
a domain, along with updating all clients to use the new member.
|
||||
Up to this point, there have been no changes to existing
|
||||
semantics, and the new APIs will fail unless they are used in
|
||||
the same way as the older API wrappers.
|
||||
</p>
|
||||
|
||||
<h3><a id="drivercode">Implement driver handling</a></h3>
|
||||
|
||||
<p>
|
||||
The remaining patches should only touch one driver at a time.
|
||||
It is possible to implement all changes for a driver in one
|
||||
patch, but for review purposes it may still make sense to break
|
||||
things into simpler steps. Here is where the new APIs finally
|
||||
start working.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
It is always a good idea to patch the test driver in addition to the
|
||||
target driver, to prove that the API can be used for more than one
|
||||
driver.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Any cleanups resulting from the changes should be added as separate
|
||||
patches at the end of the series.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Once you have working functionality, run make check and make
|
||||
syntax-check on each patch of the series before submitting
|
||||
patches. It may also be worth writing tests for the libvirt-TCK
|
||||
testsuite to exercise your new API, although those patches are
|
||||
not kept in the libvirt repository.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
@@ -1,481 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Applications using libvirt</h1>
|
||||
|
||||
<p>
|
||||
This page provides an illustration of the wide variety of
|
||||
applications using the libvirt management API.
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="add">Add an application</a></h2>
|
||||
|
||||
<p>
|
||||
To add an application not listed on this page, send a message
|
||||
to the <a href="contact.html">mailing list</a>, requesting it
|
||||
be added here, or simply send a patch against the documentation
|
||||
in the libvirt.git docs subdirectory.
|
||||
If your application uses libvirt as its API,
|
||||
the following graphics are available for your website to advertise
|
||||
support for libvirt:
|
||||
</p>
|
||||
|
||||
<p class="image">
|
||||
<img src="logos/logo-square-powered-96.png" alt="libvirt powered"/>
|
||||
<img src="logos/logo-square-powered-128.png" alt="libvirt powered"/>
|
||||
<img src="logos/logo-square-powered-192.png" alt="libvirt powered"/>
|
||||
<img src="logos/logo-square-powered-256.png" alt="libvirt powered"/>
|
||||
</p>
|
||||
|
||||
<h2><a id="command">Command line tools</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org">guestfish</a></dt>
|
||||
<dd>
|
||||
Guestfish is an interactive shell and command-line tool for examining
|
||||
and modifying virtual machine filesystems. It uses libvirt to find
|
||||
guests and their associated disks.
|
||||
</dd>
|
||||
<dt>virsh</dt>
|
||||
<dd>
|
||||
An interactive shell, and batch scriptable tool for performing
|
||||
management tasks on all libvirt managed domains, networks and
|
||||
storage. This is part of the libvirt core distribution.
|
||||
</dd>
|
||||
<dt><a href="https://virt-manager.org/">virt-clone</a></dt>
|
||||
<dd>
|
||||
Allows the disk image(s) and configuration for an existing
|
||||
virtual machine to be cloned to form a new virtual machine.
|
||||
It automates copying of data across to new disk images, and
|
||||
updates the UUID, MAC address, and name in the configuration.
|
||||
</dd>
|
||||
<dt><a href="https://people.redhat.com/rjones/virt-df/">virt-df</a></dt>
|
||||
<dd>
|
||||
Examine the utilization of each filesystem in a virtual machine
|
||||
from the comfort of the host machine. This tool peeks into the
|
||||
guest disks and determines how much space is used. It can cope
|
||||
with common Linux filesystems and LVM volumes.
|
||||
</dd>
|
||||
<dt><a href="https://virt-manager.org/">virt-image</a></dt>
|
||||
<dd>
|
||||
Provides a way to deploy virtual appliances. It defines a
|
||||
simplified portable XML format describing the pre-requisites
|
||||
of a virtual machine. At time of deployment this is translated
|
||||
into the domain XML format for execution under any libvirt
|
||||
hypervisor meeting the pre-requisites.
|
||||
</dd>
|
||||
<dt><a href="https://virt-manager.org/">virt-install</a></dt>
|
||||
<dd>
|
||||
Provides a way to provision new virtual machines from a
|
||||
OS distribution install tree. It supports provisioning from
|
||||
local CD images, and the network over NFS, HTTP and FTP.
|
||||
</dd>
|
||||
<dt><a href="https://people.redhat.com/rjones/virt-top/">virt-top</a></dt>
|
||||
<dd>
|
||||
Watch the CPU, memory, network and disk utilization of all
|
||||
virtual machines running on a host.
|
||||
</dd>
|
||||
<dt>
|
||||
<a href="https://people.redhat.com/~rjones/virt-what/">virt-what</a>
|
||||
</dt>
|
||||
<dd>
|
||||
virt-what is a shell script for detecting if the program is running
|
||||
in a virtual machine. It prints out a list of facts about the
|
||||
virtual machine, derived from heuristics.
|
||||
</dd>
|
||||
<dt><a href="https://sourceware.org/systemtap/">stap</a></dt>
|
||||
<dd>
|
||||
SystemTap is a tool used to gather rich information about a running
|
||||
system through the use of scripts. Starting from v2.4, the front-end
|
||||
application stap can use libvirt to gather data within virtual
|
||||
machines.
|
||||
</dd>
|
||||
<dt><a href="https://github.com/pradels/vagrant-libvirt/">vagrant-libvirt</a></dt>
|
||||
<dd>
|
||||
Vagrant-Libvirt is a Vagrant plugin that uses libvirt to manage virtual
|
||||
machines. It is a command line tool for developers that makes it very
|
||||
fast and easy to deploy and re-deploy an environment of vm's.
|
||||
</dd>
|
||||
<dt><a href="https://github.com/virt-lightning/virt-lightning">virt-lightning</a></dt>
|
||||
<dd>
|
||||
Virt-Lightning uses libvirt, cloud-init and libguestfs to allow anyone
|
||||
to quickly start a new VM. Very much like a container CLI, but with a
|
||||
virtual machine.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="configmgmt">Configuration Management</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://wiki.lcfg.org/bin/view/LCFG/LcfgLibvirt">LCFG</a></dt>
|
||||
<dd>
|
||||
LCFG is a system for automatically installing and managing the
|
||||
configuration of large numbers of Unix systems. It is particularly
|
||||
suitable for sites with very diverse and rapidly changing
|
||||
configurations.
|
||||
</dd>
|
||||
<dd>
|
||||
The lcfg-libvirt package adds support for virtualized systems to
|
||||
LCFG, with both Xen and KVM known to work. Cloning guests is
|
||||
supported, as are the bridged, routed, and isolated modes for
|
||||
Virtual Networking.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="continuousintegration">Continuous Integration</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html">BuildBot</a></dt>
|
||||
<dd>
|
||||
BuildBot is a system to automate the compile/test cycle required
|
||||
by most software projects. CVS commits trigger new builds, run on
|
||||
a variety of client machines. Build status (pass/fail/etc) are
|
||||
displayed on a web page or through other protocols.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://wiki.jenkins-ci.org/display/JENKINS/Libvirt+Slaves+Plugin">Jenkins</a></dt>
|
||||
<dd>
|
||||
This plugin for Jenkins adds a way to control guest domains hosted
|
||||
on Xen or QEMU/KVM. You configure a Jenkins Slave,
|
||||
selecting the guest domain and hypervisor. When you need to build a
|
||||
job on a specific Slave, its guest domain is started, then the job is
|
||||
run. When the build process is finished, the guest domain is shut
|
||||
down, ready to be used again as required.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="conversion">Conversion</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org/virt-p2v.1.html">virt-p2v</a></dt>
|
||||
<dd>
|
||||
Convert a physical machine to run on KVM. It is a LiveCD
|
||||
which is booted on the machine to be converted. It collects a
|
||||
little information from the user, then copies the disks over
|
||||
to a remote machine and defines the XML for a domain to run
|
||||
the guest. (Note this tool is included with libguestfs)
|
||||
</dd>
|
||||
<dt><a href="http://libguestfs.org/virt-v2v.1.html">virt-v2v</a></dt>
|
||||
<dd>
|
||||
virt-v2v converts guests from a foreign hypervisor to run on
|
||||
KVM, managed by libvirt. It can convert guests from VMware or
|
||||
Xen to run on OpenStack, oVirt (RHEV-M), or local libvirt. It
|
||||
will enable VirtIO drivers in the converted guest if possible.
|
||||
(Note this tool is included with libguestfs)
|
||||
</dd>
|
||||
<dd>
|
||||
For RHEL customers of Red Hat, conversion of Windows guests is also
|
||||
possible. This conversion requires some Microsoft signed pieces,
|
||||
that Red Hat can provide.
|
||||
</dd>
|
||||
<dt><a href="https://launchpad.net/virt-goodies">vmware2libvirt</a></dt>
|
||||
<dd>
|
||||
Part of the <i>virt-goodies</i> package, vmware2libvirt is a python
|
||||
script for migrating a vmware image to libvirt.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="desktop">Desktop applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://virt-manager.org/">virt-manager</a></dt>
|
||||
<dd>
|
||||
A general purpose desktop management tool, able to manage
|
||||
virtual machines across both local and remotely accessed
|
||||
hypervisors. It is targeted at home and small office usage
|
||||
up to managing 10-20 hosts and their VMs.
|
||||
</dd>
|
||||
<dt><a href="https://virt-manager.org/">virt-viewer</a></dt>
|
||||
<dd>
|
||||
A lightweight tool for accessing the graphical console
|
||||
associated with a virtual machine. It can securely connect
|
||||
to remote consoles supporting the VNC protocol. Also provides
|
||||
an optional mozilla browser plugin.
|
||||
</dd>
|
||||
<dt><a href="https://f1ash.github.io/qt-virt-manager">qt-virt-manager</a></dt>
|
||||
<dd>
|
||||
The Qt GUI for create and control VMs and another virtual entities
|
||||
(aka networks, storages, interfaces, secrets, network filters).
|
||||
Contains integrated LXC/SPICE/VNC viewer for accessing the graphical or
|
||||
text console associated with a virtual machine or container.
|
||||
</dd>
|
||||
<dt><a href="https://f1ash.github.io/qt-virt-manager/#virtual-machines-viewer">qt-remote-viewer</a></dt>
|
||||
<dd>
|
||||
The Qt VNC/SPICE viewer for access to remote desktops or VMs.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="iaas">Infrastructure as a Service (IaaS)</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://cc1.ifj.edu.pl">Cracow Cloud One</a></dt>
|
||||
<dd>The CC1 system provides a complete solution for Private
|
||||
Cloud Computing. An intuitive web access interface with an
|
||||
administration module and simple installation procedure make
|
||||
it easy to benefit from private Cloud Computing technology.
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://github.com/eucalyptus/eucalyptus">Eucalyptus</a></dt>
|
||||
<dd>
|
||||
Eucalyptus is an on-premise Infrastructure as a Service cloud
|
||||
software platform that is open source and
|
||||
AWS-compatible. Eucalyptus uses libvirt virtualization API to
|
||||
directly interact with Xen and KVM hypervisors.
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://www.nimbusproject.org">Nimbus</a></dt>
|
||||
<dd>
|
||||
Nimbus is an open-source toolkit focused on providing
|
||||
Infrastructure-as-a-Service (IaaS) capabilities to the scientific
|
||||
community. It uses libvirt for communication with all KVM and Xen
|
||||
virtual machines.
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://snooze.inria.fr">Snooze</a></dt>
|
||||
<dd>
|
||||
Snooze is an open-source scalable, autonomic, and energy-efficient
|
||||
virtual machine (VM) management framework for private clouds. It
|
||||
integrates libvirt for VM monitoring, live migration, and life-cycle
|
||||
management.
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://www.openstack.org">OpenStack</a></dt>
|
||||
<dd>
|
||||
OpenStack is a "cloud operating system" usable for both public
|
||||
and private clouds. Its various parts take care of compute,
|
||||
storage and networking resources and interface with the user
|
||||
using a dashboard. Compute part uses libvirt to manage VM
|
||||
life-cycle, monitoring and so on.
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://github.com/gustavfranssonnyvell/cherrypop">Cherrypop</a></dt>
|
||||
<dd>
|
||||
A cloud software with no masters or central points. Nodes
|
||||
autodetect other nodes and autodistribute virtual
|
||||
machines and autodivide up the workload. Also there is no
|
||||
minimum limit for hosts, well, one might be nice. It's
|
||||
perfect for setting up low-end servers in a cloud or a
|
||||
cloud where you want the most bang for the bucks.
|
||||
</dd>
|
||||
|
||||
<dt><a href="http://en.zstack.io/">ZStack</a></dt>
|
||||
<dd>
|
||||
ZStack is an open source IaaS software that aims to automate the
|
||||
management of all resources (compute, storage, networking, etc.) in a
|
||||
datacenter by using APIs, thus conforming to the principles of a
|
||||
software-defined datacenter. The key strengths of ZStack in terms of
|
||||
management are scalability, performance, and a fast, user-friendly
|
||||
deployment.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="libraries">Libraries</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org">libguestfs</a></dt>
|
||||
<dd>
|
||||
A library and set of tools for accessing and modifying virtual
|
||||
machine disk images. It can be linked with C and C++ management
|
||||
programs, and has bindings for Perl, Python, Ruby, Java, OCaml,
|
||||
PHP, Haskell, and C#.
|
||||
</dd>
|
||||
<dd>
|
||||
Using its FUSE module, you can also mount guest filesystems on the
|
||||
host, and there is a subproject to allow merging changes into the
|
||||
Windows Registry in Windows guests.
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://sandbox.libvirt.org">libvirt-sandbox</a></dt>
|
||||
<dd>
|
||||
A library and command line tools for simplifying the creation of
|
||||
application sandboxes using virtualization technology. It currently
|
||||
supports either KVM, QEMU or LXC as backends. Integration with
|
||||
systemd facilitates sandboxing of system services like apache.
|
||||
</dd>
|
||||
<dt><a href="https://github.com/ohadlevy/virt#readme">Ruby
|
||||
Libvirt Object bindings</a></dt>
|
||||
<dd>
|
||||
Allows using simple ruby objects to manipulate
|
||||
hypervisors, guests, storage, network etc. It is
|
||||
based on top of
|
||||
the <a href="https://libvirt.org/ruby">native ruby bindings</a>.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="livecd">LiveCD / Appliances</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org/virt-v2v/">virt-p2v</a></dt>
|
||||
<dd>
|
||||
An older tool for converting a physical machine into a virtual
|
||||
machine. It is a LiveCD which is booted on the machine to be
|
||||
converted. It collects a little information from the user, then
|
||||
copies the disks over to a remote machine and defines the XML for a
|
||||
domain to run the guest.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="monitoring">Monitoring</a></h2>
|
||||
<dl>
|
||||
<dt><a href="https://collectd.org/plugins/libvirt.shtml">collectd</a></dt>
|
||||
<dd>
|
||||
The libvirt-plugin is part of <a href="http://collectd.org/">collectd</a>
|
||||
and gathers statistics about virtualized guests on a system. This
|
||||
way, you can collect CPU, network interface and block device usage
|
||||
for each guest without installing collectd on the guest systems.
|
||||
For a full description, please refer to the libvirt section in the
|
||||
collectd.conf(5) manual page.
|
||||
</dd>
|
||||
<dt><a href="http://www.sflow.net/">Host sFlow</a></dt>
|
||||
<dd>
|
||||
Host sFlow is a lightweight agent running on KVM hypervisors that
|
||||
links to libvirt library and exports standardized cpu, memory, network
|
||||
and disk metrics for all virtual machines.
|
||||
</dd>
|
||||
<dt><a href="https://honk.sigxcpu.org/projects/libvirt/#munin">Munin</a></dt>
|
||||
<dd>
|
||||
The plugins provided by Guido Günther allow to monitor various things
|
||||
like network and block I/O with
|
||||
<a href="http://munin.projects.linpro.no/">Munin</a>.
|
||||
</dd>
|
||||
<dt><a href="http://people.redhat.com/rjones/nagios-virt/">Nagios-virt</a></dt>
|
||||
<dd>
|
||||
Nagios-virt is a configuration tool to add monitoring of your
|
||||
virtualised domains to <a href="http://www.nagios.org/">Nagios</a>.
|
||||
You can use this tool to either set up a new Nagios installation for
|
||||
your Xen or QEMU/KVM guests, or to integrate with your existing Nagios
|
||||
installation.
|
||||
</dd>
|
||||
<dt><a href="http://www.pcp.io/man/man1/pmdalibvirt.1.html">PCP</a></dt>
|
||||
<dd>
|
||||
The PCP libvirt PMDA (plugin) is part of the
|
||||
<a href="http://pcp.io/">PCP</a> toolkit and provides
|
||||
hypervisor and guest information and complete set of guest performance
|
||||
metrics. It supports pCPU, vCPU, memory, block device, network interface,
|
||||
and performance event metrics for each virtual guest.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="provisioning">Provisioning</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli+Provisioning+Manager">Tivoli Provisioning Manager</a></dt>
|
||||
<dd>
|
||||
Part of the IBM Tivoli family, Tivoli Provisioning Manager (TPM) is
|
||||
an IT lifecycle automation product. It
|
||||
<a href="http://publib.boulder.ibm.com/infocenter/tivihelp/v38r1/index.jsp?topic=/com.ibm.tivoli.tpm.apk.doc/libvirt_package.html">uses libvirt</a>
|
||||
for communication with virtualization hosts and guest domains.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://theforeman.org">Foreman</a></dt>
|
||||
<dd>
|
||||
Foreman is an open source web based application aimed to be a
|
||||
Single Address For All Machines Life Cycle Management. Foreman:
|
||||
|
||||
<ul>
|
||||
<li>Creates everything you need when adding a new machine to
|
||||
your network, its goal being automatically managing
|
||||
everything you would normally manage manually (DNS, DHCP,
|
||||
TFTP, Virtual Machines,CA, CMDB...)</li>
|
||||
<li>Integrates with Puppet (and acts as web front end to it).</li>
|
||||
<li>Takes care of provisioning until the point puppet is
|
||||
running, allowing Puppet to do what it does best.</li>
|
||||
<li>Shows you Systems Inventory (based on Facter) and
|
||||
provides real time information about hosts status based on
|
||||
Puppet reports.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h2><a id="web">Web applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://www.abiquo.com/">AbiCloud</a></dt>
|
||||
<dd>
|
||||
AbiCloud is an open source cloud platform manager which allows to
|
||||
easily deploy a private cloud in your datacenter. One of the key
|
||||
differences of AbiCloud is the web rich interface for managing the
|
||||
infrastructure. You can deploy a new service just dragging and
|
||||
dropping a VM.
|
||||
</dd>
|
||||
<dt><a href="https://kimchi-project.github.io/kimchi/">Kimchi</a></dt>
|
||||
<dd>
|
||||
Kimchi is an HTML5 based management tool for KVM. It is designed to
|
||||
make it as easy as possible to get started with KVM and create your first guest.
|
||||
|
||||
Kimchi manages KVM guests through libvirt. The management interface is accessed
|
||||
over the web using a browser that supports HTML5.
|
||||
</dd>
|
||||
<dt><a href="https://ovirt.org/">oVirt</a></dt>
|
||||
<dd>
|
||||
oVirt provides the ability to manage large numbers of virtual
|
||||
machines across an entire data center of hosts. It integrates
|
||||
with FreeIPA for Kerberos authentication, and in the future,
|
||||
certificate management.
|
||||
</dd>
|
||||
<dt><a href="https://ispsystem.com/en/software/vmmanager">VMmanager</a></dt>
|
||||
<dd>
|
||||
VMmanager is a software solution for virtualization management
|
||||
that can be used both for hosting virtual machines and
|
||||
building a cloud. VMmanager can manage not only one server,
|
||||
but a large cluster of hypervisors. It delivers a number of
|
||||
functions, such as live migration that allows for load
|
||||
balancing between cluster nodes, monitoring CPU, memory.
|
||||
</dd>
|
||||
<dt><a href="https://mist.io/">mist.io</a></dt>
|
||||
<dd>
|
||||
Mist.io is an open source project and a service that can assist you in
|
||||
managing your virtual machines on a unified way, providing a simple
|
||||
interface for all of your infrastructure (multiple public cloud
|
||||
providers, OpenStack based public/private clouds, Docker servers, bare
|
||||
metal servers and now KVM hypervisors).
|
||||
</dd>
|
||||
<dt><a href="https://ravada.upc.edu/">Ravada</a></dt>
|
||||
<dd>
|
||||
Ravada is an open source tool for managing Virtual Desktop
|
||||
Infrastructure (VDI). It is very easy to install and use. Following
|
||||
the documentation, you'll be ready to deploy virtual machines in
|
||||
minutes. The only requirements for the users are a Web browser and
|
||||
a lightweight remote viewer.
|
||||
</dd>
|
||||
<dt><a href="https://github.com/cutelyst/Virtlyst">Virtlyst</a></dt>
|
||||
<dd>
|
||||
Virtlyst is an open source web application built with C++11, Cutelyst and Qt.
|
||||
It features:
|
||||
<ul>
|
||||
<li>Low memory usage (around 5 MiB of RAM)</li>
|
||||
<li>Look and feel easily customized with HTML templates that use the Django syntax</li>
|
||||
<li>VNC/Spice console directly in the browser using websockets on the same HTTP port</li>
|
||||
<li>Host and Domain statistics graphs (CPU, Memory, IO, Network)</li>
|
||||
<li>Connect to multiple libvirtd instances (over local Unix domain socket, SSH, TCP and TLS)</li>
|
||||
<li>Manage Storage Pools, Storage Volumes, Networks, Interfaces, and Secrets</li>
|
||||
<li>Create and launch VMs</li>
|
||||
<li>Configure VMs with easy panels or go pro and edit the VM's XML</li>
|
||||
</ul>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a id="other">Other</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://cuckoosandbox.org/">Cuckoo Sandbox</a></dt>
|
||||
<dd>
|
||||
Cuckoo Sandbox is a malware analysis system. You can throw
|
||||
any suspicious file at it and in a matter of seconds Cuckoo
|
||||
will provide you back some detailed results outlining what
|
||||
such file did when executed inside an isolated environment.
|
||||
And libvirt is one of the backends that can be used for the
|
||||
isolated environment.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,87 +0,0 @@
|
||||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
1050 7500 9375 7500 9375 8700 1050 8700 1050 7500
|
||||
2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
|
||||
3525 7275 3525 4125 1050 4125 1050 7275 3525 7275
|
||||
2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
|
||||
1050 6540 3540 6525
|
||||
2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
|
||||
1590 6900 1590 6645 1140 6645 1140 6900 1590 6900
|
||||
2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
|
||||
1590 7185 1590 6930 1140 6930 1140 7185 1590 7185
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
|
||||
1 1 2.00 120.00 240.00
|
||||
1 1 2.00 120.00 240.00
|
||||
1875 7725 8625 7725
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
1650 5625 3000 5625 3000 6375 1650 6375 1650 5625
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
2850 7725 2850 6375
|
||||
2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
|
||||
6450 7275 6450 4125 3975 4125 3975 7275 6450 7275
|
||||
2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
|
||||
9300 7275 9300 4125 6825 4125 6825 7275 9300 7275
|
||||
2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
|
||||
3975 6540 6465 6525
|
||||
2 1 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 2
|
||||
6825 6540 9315 6525
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
5400 7725 5400 7050
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
8025 7725 8025 7050
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
1050 8925 9375 8925 9375 9900 1050 9900 1050 8925
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
2100 4575 3450 4575 3450 5325 2100 5325 2100 4575
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
3225 5325 3225 8325
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
6225 6900 6225 8250
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
8925 6900 8925 8250
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
1725 7125 1725 8325
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
|
||||
1 1 2.00 120.00 240.00
|
||||
1 1 2.00 120.00 240.00
|
||||
2850 5850 2850 5025
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
5175 8475 5175 9375
|
||||
2 1 1 3 0 7 50 -1 -1 2.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
1350 7125 1350 9450
|
||||
2 1 0 4 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
1 1 2.00 120.00 240.00
|
||||
2325 7725 2325 7200
|
||||
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 1
|
||||
900 3975
|
||||
2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 1
|
||||
9525 9975
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 870 4350 7980 XenBus\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 780 1680 6870 drivers\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 1050 1800 6075 XenStore\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 900 1875 7125 Kernel0\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 960 4875 6975 KernelU\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 960 7650 6975 KernelU\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 255 1740 4050 8400 Xen Hypervisor\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 585 2325 4950 Xend\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 690 1200 4725 Dom0\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 750 4875 5325 DomU\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 750 7650 5325 DomU\001
|
||||
4 0 0 50 -1 0 18 0.0000 4 195 1080 3750 9450 Hardware\001
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 5.4 KiB |
@@ -1,82 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1 >libvirt architecture</h1>
|
||||
|
||||
<p>
|
||||
Currently libvirt supports 2 kind of virtualization, and its
|
||||
internal structure is based on a driver model which simplifies
|
||||
adding new
|
||||
engines:
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="Xen">Xen support</a></h2>
|
||||
|
||||
<p>When running in a Xen environment, programs using libvirt have to execute
|
||||
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
|
||||
kernel provides most if not all of the actual drivers used by the set of
|
||||
domains. It also runs the Xen Store, a database of information shared by the
|
||||
hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
|
||||
libxl provides a set of APIs for creating and managing domains, which can be used
|
||||
by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
|
||||
drivers, kernels and daemons communicate though a shared system bus
|
||||
implemented in the hypervisor. The figure below tries to provide a view of
|
||||
this environment:</p>
|
||||
<img src="architecture.gif" alt="The Xen architecture" />
|
||||
<p>The library will interact with libxl for all management operations
|
||||
on a Xen system.</p>
|
||||
<p>Note that the libvirt libxl driver only supports root access.</p>
|
||||
|
||||
<h2><a id="QEMU">QEMU and KVM support</a></h2>
|
||||
|
||||
<p>The model for QEMU and KVM is completely similar, basically KVM is based
|
||||
on QEMU for the process controlling a new domain, only small details differs
|
||||
between the two. In both case the libvirt API is provided by a controlling
|
||||
process forked by libvirt in the background and which launch and control the
|
||||
QEMU or KVM process. That program called libvirt_qemud talks though a specific
|
||||
protocol to the library, and connects to the console of the QEMU process in
|
||||
order to control and report on its status. Libvirt tries to expose all the
|
||||
emulations models of QEMU, the selection is done when creating the new
|
||||
domain, by specifying the architecture and machine type targeted.</p>
|
||||
<p>The code controlling the QEMU process is available in the
|
||||
<code>qemud/</code> directory.</p>
|
||||
|
||||
<h2><a id="drivers">Driver based architecture</a></h2>
|
||||
|
||||
<p>As the previous section explains, libvirt can communicate using different
|
||||
channels with the current hypervisor, and should also be able to use
|
||||
different kind of hypervisor. To simplify the internal design, code, ease
|
||||
maintenance and simplify the support of other virtualization engine the
|
||||
internals have been structured as one core component, the libvirt.c module
|
||||
acting as a front-end for the library API and a set of hypervisor drivers
|
||||
defining a common set of routines. That way the Xen Daemon access, the Xen
|
||||
Store one, the Hypervisor hypercall are all isolated in separate C modules
|
||||
implementing at least a subset of the common operations defined by the
|
||||
drivers present in driver.h:</p>
|
||||
<ul>
|
||||
<li>xend_internal: implements the driver functions though the Xen
|
||||
Daemon</li>
|
||||
<li>xs_internal: implements the subset of the driver available though the
|
||||
Xen Store</li>
|
||||
<li>xen_internal: provide the implementation of the functions possible via
|
||||
direct hypervisor access</li>
|
||||
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
|
||||
is in the <code>proxy/</code> directory.</li>
|
||||
<li>xm_internal: provide support for Xen defined but not running
|
||||
domains.</li>
|
||||
<li>qemu_internal: implement the driver functions for QEMU and
|
||||
KVM virtualization engines. It also uses a qemud/ specific daemon
|
||||
which interacts with the QEMU process to implement libvirt API.</li>
|
||||
<li>test: this is a test driver useful for regression tests of the
|
||||
front-end part of libvirt.</li>
|
||||
</ul>
|
||||
<p>Note that a given driver may only implement a subset of those functions,
|
||||
(for example saving a Xen domain state to disk and restoring it is only
|
||||
possible though the Xen Daemon), in that case the driver entry points for
|
||||
unsupported functions are initialized to NULL.</p>
|
||||
<p></p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,375 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Audit log</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="intro">Introduction</a></h2>
|
||||
|
||||
<p>
|
||||
A number of the libvirt virtualization drivers (QEMU/KVM and LXC) include
|
||||
support for logging details of important operations to the host's audit
|
||||
subsystem. This provides administrators / auditors with a canonical historical
|
||||
record of changes to virtual machines' / containers' lifecycle states and
|
||||
their configuration. On hosts which are running the Linux audit daemon,
|
||||
the logs will usually end up in <code>/var/log/audit/audit.log</code>
|
||||
</p>
|
||||
|
||||
<h2><a id="config">Configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt audit integration is enabled by default on any host which has
|
||||
the Linux audit subsystem active, and disabled otherwise. It is possible
|
||||
to alter this behaviour in the <code>/etc/libvirt/libvirtd.conf</code>
|
||||
configuration file, via the <code>audit_level</code> parameter
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>audit_level=0</code> - libvirt auditing is disabled regardless
|
||||
of host audit subsystem enablement.</li>
|
||||
<li><code>audit_level=1</code> - libvirt auditing is enabled if the host
|
||||
audit subsystem is enabled, otherwise it is disabled. This is the
|
||||
default behaviour.</li>
|
||||
<li><code>audit_level=2</code> - libvirt auditing is enabled regardless
|
||||
of host audit subsystem enablement. If the host audit subsystem is
|
||||
disabled, then libvirtd will refuse to complete startup and exit with
|
||||
an error.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
In addition to have formal messages sent to the audit subsystem it is
|
||||
possible to tell libvirt to inject messages into its own logging
|
||||
layer. This will result in messages ending up in the systemd journal
|
||||
or <code>/var/log/libvirt/libvirtd.log</code> on non-systemd hosts.
|
||||
This is disabled by default, but can be requested by setting the
|
||||
<code>audit_logging=1</code> configuration parameter in the same file
|
||||
mentioned above.
|
||||
</p>
|
||||
|
||||
<h2><a id="types">Message types</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt defines three core audit message types each of which will
|
||||
be described below. There are a number of common fields that will
|
||||
be reported for all message types.
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>pid</code></dt>
|
||||
<dd>Process ID of the libvirtd daemon generating the audit record.</dd>
|
||||
<dt><code>uid</code></dt>
|
||||
<dd>User ID of the libvirtd daemon process generating the audit record.</dd>
|
||||
<dt><code>subj</code></dt>
|
||||
<dd>Security context of the libvirtd daemon process generating the audit record.</dd>
|
||||
<dt><code>msg</code></dt>
|
||||
<dd>String containing a list of key=value pairs specific to the type of audit record being reported.</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
Some fields in the <code>msg</code> string are common to audit records
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>virt</code></dt>
|
||||
<dd>Type of virtualization driver used. One of <code>qemu</code> or <code>lxc</code></dd>
|
||||
<dt><code>vm</code></dt>
|
||||
<dd>Host driver unique name of the guest</dd>
|
||||
<dt><code>uuid</code></dt>
|
||||
<dd>Globally unique identifier for the guest</dd>
|
||||
<dt><code>exe</code></dt>
|
||||
<dd>Path of the libvirtd daemon</dd>
|
||||
<dt><code>hostname</code></dt>
|
||||
<dd>Currently unused</dd>
|
||||
<dt><code>addr</code></dt>
|
||||
<dd>Currently unused</dd>
|
||||
<dt><code>terminal</code></dt>
|
||||
<dd>Currently unused</dd>
|
||||
<dt><code>res</code></dt>
|
||||
<dd>Result of the action, either <code>success</code> or <code>failed</code></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a id="typecontrol">VIRT_CONTROL</a></h3>
|
||||
|
||||
<p>
|
||||
Reports change in the lifecycle state of a virtual machine. The <code>msg</code>
|
||||
field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>op</code></dt>
|
||||
<dd>Type of operation performed. One of <code>start</code>, <code>stop</code> or <code>init</code></dd>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the operation to happen</dd>
|
||||
<dt><code>vm-pid</code></dt>
|
||||
<dd>ID of the primary/leading process associated with the guest</dd>
|
||||
<dt><code>init-pid</code></dt>
|
||||
<dd>ID of the <code>init</code> process in a container. Only if <code>op=init</code> and <code>virt=lxc</code></dd>
|
||||
<dt><code>pid-ns</code></dt>
|
||||
<dd>Namespace ID of the <code>init</code> process in a container. Only if <code>op=init</code> and <code>virt=lxc</code></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a id="typemachine">VIRT_MACHINE_ID</a></h3>
|
||||
|
||||
<p>
|
||||
Reports the association of a security context with a guest. The <code>msg</code>
|
||||
field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>model</code></dt>
|
||||
<dd>The security driver type. One of <code>selinux</code> or <code>apparmor</code></dd>
|
||||
<dt><code>vm-ctx</code></dt>
|
||||
<dd>Security context for the guest process</dd>
|
||||
<dt><code>img-ctx</code></dt>
|
||||
<dd>Security context for the guest disk images and other assigned host resources</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a id="typeresource">VIRT_RESOURCE</a></h3>
|
||||
|
||||
<p>
|
||||
Reports the usage of a host resource by a guest. The fields include will
|
||||
vary according to the type of device being reported. When the guest is
|
||||
initially booted records will be generated for all assigned resources.
|
||||
If any changes are made to the running guest configuration, for example
|
||||
hotplug devices, or adjust resources allocation, further records will
|
||||
be generated.
|
||||
</p>
|
||||
|
||||
<h4><a id="typeresourcevcpu">Virtual CPU</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>vcpu</code></dd>
|
||||
<dt><code>old-vcpu</code></dt>
|
||||
<dd>Original vCPU count, or 0</dd>
|
||||
<dt><code>new-vcpu</code></dt>
|
||||
<dd>Updated vCPU count</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a id="typeresourcemem">Memory</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>mem</code></dd>
|
||||
<dt><code>old-mem</code></dt>
|
||||
<dd>Original memory size in bytes, or 0</dd>
|
||||
<dt><code>new-mem</code></dt>
|
||||
<dd>Updated memory size in bytes</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcedisk">Disk</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>disk</code></dd>
|
||||
<dt><code>old-disk</code></dt>
|
||||
<dd>Original host file or device path acting as the disk backing file</dd>
|
||||
<dt><code>new-disk</code></dt>
|
||||
<dd>Updated host file or device path acting as the disk backing file</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcenic">Network interface</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>net</code></dd>
|
||||
<dt><code>old-net</code></dt>
|
||||
<dd>Original MAC address of the guest network interface</dd>
|
||||
<dt><code>new-net</code></dt>
|
||||
<dd>Updated MAC address of the guest network interface</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
If there is a host network interface associated with the guest NIC then
|
||||
further records may be generated
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>net</code></dd>
|
||||
<dt><code>net</code></dt>
|
||||
<dd>MAC address of the host network interface</dd>
|
||||
<dt><code>rdev</code></dt>
|
||||
<dd>Name of the host network interface</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcefs">Filesystem</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>fs</code></dd>
|
||||
<dt><code>old-fs</code></dt>
|
||||
<dd>Original host directory, file or device path backing the filesystem </dd>
|
||||
<dt><code>new-fs</code></dt>
|
||||
<dd>Updated host directory, file or device path backing the filesystem</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcehost">Host device</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>hostdev</code> or <code>dev</code></dd>
|
||||
<dt><code>dev</code></dt>
|
||||
<dd>The unique bus identifier of the USB, PCI or SCSI device, if <code>resrc=dev</code></dd>
|
||||
<dt><code>disk</code></dt>
|
||||
<dd>The path of the block device assigned to the guest, if <code>resrc=hostdev</code></dd>
|
||||
<dt><code>chardev</code></dt>
|
||||
<dd>The path of the character device assigned to the guest, if <code>resrc=hostdev</code></dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcetpm">TPM</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>tpm</code> or <code>tpm-emulator</code></dd>
|
||||
<dt><code>device</code></dt>
|
||||
<dd>The path of the host TPM device assigned to the guest</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcerng">RNG</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>rng</code></dd>
|
||||
<dt><code>old-rng</code></dt>
|
||||
<dd>Original path of the host entropy source for the RNG</dd>
|
||||
<dt><code>new-rng</code></dt>
|
||||
<dd>Updated path of the host entropy source for the RNG</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcechardev">console/serial/parallel/channel</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>chardev</code></dd>
|
||||
<dt><code>old-chardev</code></dt>
|
||||
<dd>Original path of the backing character device for given emulated device</dd>
|
||||
<dt><code>new-chardev</code></dt>
|
||||
<dd>Updated path of the backing character device for given emulated device</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcesmartcard">smartcard</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>smartcard</code></dd>
|
||||
<dt><code>old-smartcard</code></dt>
|
||||
<dd>Original path of the backing character device, certificate store or
|
||||
"nss-smartcard-device" for host smartcard passthrough.
|
||||
</dd>
|
||||
<dt><code>new-smartcard</code></dt>
|
||||
<dd>Updated path of the backing character device, certificate store or
|
||||
"nss-smartcard-device" for host smartcard passthrough.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourceredir">Redirected device</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>redir</code></dd>
|
||||
<dt><code>bus</code></dt>
|
||||
<dd>The bus type, only <code>usb</code> allowed</dd>
|
||||
<dt><code>device</code></dt>
|
||||
<dd>The device type, only <code>USB redir</code> allowed</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a id="typeresourcecgroup">Control group</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>cgroup</code></dd>
|
||||
<dt><code>cgroup</code></dt>
|
||||
<dd>The name of the cgroup controller</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a id="typeresourceshmem">Shared memory</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>resrc</code></dt>
|
||||
<dd>The type of resource assigned. Set to <code>shmem</code></dd>
|
||||
<dt><code>reason</code></dt>
|
||||
<dd>The reason which caused the resource to be assigned to happen</dd>
|
||||
<dt><code>size</code></dt>
|
||||
<dd>The size of the shared memory region</dd>
|
||||
<dt><code>shmem</code></dt>
|
||||
<dd>Name of the shared memory region</dd>
|
||||
<dt><code>source</code></dt>
|
||||
<dd>Path of the backing character device for given emulated device</dd>
|
||||
</dl>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,366 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Connection authentication</h1>
|
||||
<p>
|
||||
When connecting to libvirt, some connections may require client
|
||||
authentication before allowing use of the APIs. The set of possible
|
||||
authentication mechanisms is administrator controlled, independent
|
||||
of applications using libvirt. Once authenticated, libvirt can apply
|
||||
fine grained <a href="acl.html">access control</a> to the operations
|
||||
performed by a client.
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="Auth_client_config">Client configuration</a></h2>
|
||||
|
||||
<p>
|
||||
When connecting to a remote hypervisor which requires authentication,
|
||||
most libvirt applications will prompt the user for the credentials. It is
|
||||
also possible to provide a client configuration file containing all the
|
||||
authentication credentials, avoiding any interaction. Libvirt will look
|
||||
for the authentication file using the following sequence:
|
||||
</p>
|
||||
<ol>
|
||||
<li>The file path specified by the $LIBVIRT_AUTH_FILE environment
|
||||
variable.</li>
|
||||
<li>The file path specified by the "authfile=/some/file" URI
|
||||
query parameter</li>
|
||||
<li>The file $XDG_CONFIG_HOME/libvirt/auth.conf</li>
|
||||
<li>The file /etc/libvirt/auth.conf</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
The auth configuration file uses the traditional <code>".ini"</code>
|
||||
style syntax. There are two types of groups that can be present in
|
||||
the config. First there are one or more <strong>credential</strong>
|
||||
sets, which provide the actual authentication credentials. The keys
|
||||
within the group may be:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>username</code>: the user login name to act as. This
|
||||
is relevant for ESX, Xen, HyperV and SSH, but probably not
|
||||
the one you want to libvirtd with SASL.</li>
|
||||
<li><code>authname</code>: the name to authorize as. This is
|
||||
what is commonly required for libvirtd with SASL.</li>
|
||||
<li><code>password</code>: the secret password</li>
|
||||
<li><code>realm</code>: the domain realm for SASL, mostly
|
||||
unused</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Each set of credentials has a name, which is part of the group
|
||||
entry name. Overall the syntax is
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[credentials-$NAME]
|
||||
credname1=value1
|
||||
credname2=value2</pre>
|
||||
|
||||
<p>
|
||||
For example, to define two sets of credentials used for production
|
||||
and test machines, using libvirtd, and a further ESX server for dev:
|
||||
</p>
|
||||
<pre>
|
||||
[credentials-test]
|
||||
authname=fred
|
||||
password=123456
|
||||
|
||||
[credentials-prod]
|
||||
authname=bar
|
||||
password=letmein
|
||||
|
||||
[credentials-dev]
|
||||
username=joe
|
||||
password=hello
|
||||
|
||||
[credentials-defgrp]
|
||||
username=defuser
|
||||
password=defpw</pre>
|
||||
|
||||
<p>
|
||||
The second set of groups provide mappings of credentials to
|
||||
specific machine services. The config file group names compromise
|
||||
the service type and host:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[auth-$SERVICE-$HOSTNAME]
|
||||
credentials=$CREDENTIALS</pre>
|
||||
|
||||
<p>
|
||||
For example, following the previous example, here is how to
|
||||
map some machines. For convenience libvirt supports a default
|
||||
mapping of credentials to machines:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[auth-libvirt-test1.example.com]
|
||||
credentials=test
|
||||
|
||||
[auth-libvirt-test2.example.com]
|
||||
credentials=test
|
||||
|
||||
[auth-libvirt-demo3.example.com]
|
||||
credentials=test
|
||||
|
||||
[auth-libvirt-prod1.example.com]
|
||||
credentials=prod
|
||||
|
||||
[auth-libvirt-default]
|
||||
credentials=defgrp
|
||||
|
||||
[auth-esx-dev1.example.com]
|
||||
credentials=dev
|
||||
|
||||
[auth-esx-default]
|
||||
credentials=defgrp</pre>
|
||||
|
||||
|
||||
<p>
|
||||
The following service types are known to libvirt
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li><code>libvirt</code> - used for connections to a libvirtd
|
||||
server, which is configured with SASL auth</li>
|
||||
<li><code>ssh</code> - used for connections to a Phyp server
|
||||
over SSH, but the Phyp driver has been removed</li>
|
||||
<li><code>esx</code> - used for connections to an ESX or
|
||||
VirtualCenter server</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
Applications using libvirt are free to use this same configuration
|
||||
file for storing other credentials. For example, it can be used
|
||||
to storage VNC or SPICE login credentials
|
||||
</p>
|
||||
|
||||
<h2><a id="ACL_server_config">Server configuration</a></h2>
|
||||
<p>
|
||||
The libvirt daemon allows the administrator to choose the authentication
|
||||
mechanisms used for client connections on each network socket independently.
|
||||
This is primarily controlled via the libvirt daemon master config file in
|
||||
<code>/etc/libvirt/libvirtd.conf</code>. Each of the libvirt sockets can
|
||||
have its authentication mechanism configured independently. There is
|
||||
currently a choice of <code>none</code>, <code>polkit</code>, and <code>sasl</code>.
|
||||
The SASL scheme can be further configured to choose between a large
|
||||
number of different mechanisms.
|
||||
</p>
|
||||
<h2><a id="ACL_server_unix_perms">UNIX socket permissions/group</a></h2>
|
||||
<p>
|
||||
If libvirt does not contain support for PolicyKit, then access control for
|
||||
the UNIX domain socket is done using traditional file user/group ownership
|
||||
and permissions. There are 2 sockets, one for full read-write access, the
|
||||
other for read-only access. The RW socket will be restricted (mode 0700) to
|
||||
only allow the <code>root</code> user to connect. The read-only socket will
|
||||
be open access (mode 0777) to allow any user to connect.
|
||||
</p>
|
||||
<p>
|
||||
To allow non-root users greater access, the <code>libvirtd.conf</code> file
|
||||
can be edited to change the permissions via the <code>unix_sock_rw_perms</code>,
|
||||
config parameter and to set a user group via the <code>unix_sock_group</code>
|
||||
parameter. For example, setting the former to mode <code>0770</code> and the
|
||||
latter <code>wheel</code> would let any user in the wheel group connect to
|
||||
the libvirt daemon.
|
||||
</p>
|
||||
<h2><a id="ACL_server_polkit">UNIX socket PolicyKit auth</a></h2>
|
||||
<p>
|
||||
If libvirt contains support for PolicyKit, then access control options are
|
||||
more advanced. The <code>auth_unix_rw</code> parameter will default to
|
||||
<code>polkit</code>, and the file permissions will default to <code>0777</code>
|
||||
even on the RW socket. Upon connecting to the socket, the client application
|
||||
will be required to identify itself with PolicyKit. The default policy for the
|
||||
RW daemon socket will require any application running in the current desktop
|
||||
session to authenticate using the user's password. This is akin to <code>sudo</code>
|
||||
auth, but does not require that the client application ultimately run as root.
|
||||
Default policy will still allow any application to connect to the RO socket.
|
||||
</p>
|
||||
<p>
|
||||
The default policy can be overridden by creating a new policy file in the
|
||||
<code>/etc/polkit-1/rules.d</code> directory. Information on the options
|
||||
available can be found by reading the <code>polkit(8)</code> man page. The
|
||||
two libvirt actions are named <code>org.libvirt.unix.manage</code> for full
|
||||
management access, and <code>org.libvirt.unix.monitor</code> for read-only
|
||||
access.
|
||||
</p>
|
||||
<p>
|
||||
As an example, creating <code>/etc/polkit-1/rules.d/80-libvirt-manage.rules</code>
|
||||
with the following gives the user <code>fred</code> full management access
|
||||
when accessing from an active local session:
|
||||
</p>
|
||||
<pre>polkit.addRule(function(action, subject) {
|
||||
if (action.id == "org.libvirt.unix.manage" &&
|
||||
subject.local && subject.active && subject.user == "fred") {
|
||||
return polkit.Result.YES;
|
||||
}
|
||||
});</pre>
|
||||
<p>
|
||||
Older versions of PolicyKit used policy files ending with .pkla in the
|
||||
local override directory <code>/etc/polkit-1/localauthority/50-local.d/</code>.
|
||||
Compatibility with this older format is provided by <a
|
||||
href="https://pagure.io/polkit-pkla-compat">polkit-pkla-compat</a>. As an
|
||||
example, this gives the user <code>fred</code> full management access:
|
||||
</p>
|
||||
<pre>[Allow fred libvirt management permissions]
|
||||
Identity=unix-user:fred
|
||||
Action=org.libvirt.unix.manage
|
||||
ResultAny=yes
|
||||
ResultInactive=yes
|
||||
ResultActive=yes</pre>
|
||||
<h2><a id="ACL_server_sasl">SASL pluggable authentication</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt integrates with the cyrus-sasl library to provide a pluggable authentication
|
||||
system using the SASL protocol. SASL can be used in combination with libvirtd's TLS
|
||||
or TCP socket listeners. When used with the TCP listener, the SASL mechanism is
|
||||
rqeuired to provide session encryption in addition to authentication. Only a very
|
||||
few SASL mechanisms are able to do this, and of those that can do it, only the
|
||||
GSSAPI plugin is considered acceptably secure by modern standards:
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt>GSSAPI</dt>
|
||||
<dd><strong>This is the current default mechanism to use with libvirtd</strong>.
|
||||
It uses the Kerberos v5 authentication protocol underneath, and assuming
|
||||
the Kerberos client/server are configured with modern ciphers (AES),
|
||||
it provides strong session encryption capabilities.</dd>
|
||||
|
||||
<dt>DIGEST-MD5</dt>
|
||||
<dd>This was previously set as the default mechanism to use with libvirtd.
|
||||
It provides a simple username/password based authentication mechanism
|
||||
that includes session encryption.
|
||||
<a href="https://tools.ietf.org/html/rfc6331">RFC 6331</a>, however,
|
||||
documents a number of serious security flaws with DIGEST-MD5 and as a
|
||||
result marks it as <code>OBSOLETE</code>. Specific concerns are that
|
||||
it is vulnerable to MITM attacks and the MD5 hash can be brute-forced
|
||||
to reveal the password. A replacement is provided via the SCRAM mechanism,
|
||||
however, note that this does not provide encryption, so the SCRAM
|
||||
mechanism can only be used on the libvirtd TLS listener.
|
||||
</dd>
|
||||
|
||||
<dt>PASSDSS-3DES-1</dt>
|
||||
<dd>This provides a simple username/password based authentication
|
||||
mechanism that includes session encryption. The current cyrus-sasl
|
||||
implementation does not provide a way to validate the server's
|
||||
public key identity, thus it is susceptible to a MITM attacker
|
||||
impersonating the server. It is also not enabled in many OS
|
||||
distros when building SASL libraries.</dd>
|
||||
|
||||
<dt>KERBEROS_V4</dt>
|
||||
<dd>This uses the obsolete Kerberos v4 protocol to provide both authentication
|
||||
and session encryption. Kerberos v4 protocol has been obsolete since the
|
||||
early 1990's and has known security vulnerabilities so this will never be
|
||||
used in practice.</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
Other SASL mechanisms, not listed above, can only be used when the libvirtd
|
||||
TLS or UNIX socket listeners.
|
||||
</p>
|
||||
|
||||
<h3><a id="ACL_server_username">Username/password auth</a></h3>
|
||||
<p>
|
||||
As noted above, the DIGEST-MD5 mechanism is considered obsolete and should
|
||||
not be used anymore. To provide a simple username/password auth scheme on
|
||||
the libvirt UNIX socket or TLS listeners, however, it is possible to use
|
||||
the SCRAM mechanism. The <code>auth_unix_ro</code>, <code>auth_unix_rw</code>,
|
||||
<code>auth_tls</code> config params in <code>libvirt.conf</code> can be used
|
||||
to turn on SASL auth in these listeners.
|
||||
</p>
|
||||
<p>
|
||||
Since the libvirt SASL config file defaults to using GSSAPI (Kerberos), a
|
||||
config change is required to enable plain password auth. This is done by
|
||||
editting <code>/etc/sasl2/libvirt.conf</code> to set the <code>mech_list</code>
|
||||
parameter to <code>scram-sha-1</code>.
|
||||
</p>
|
||||
<p>
|
||||
Out of the box, no user accounts are defined, so no clients will be able to authenticate
|
||||
on the TCP socket. Adding users and setting their passwords is done with the <code>saslpasswd2</code>
|
||||
command. When running this command it is important to tell it that the appname is <code>libvirt</code>.
|
||||
As an example, to add a user <code>fred</code>, run
|
||||
</p>
|
||||
<pre>
|
||||
# saslpasswd2 -a libvirt fred
|
||||
Password: xxxxxx
|
||||
Again (for verification): xxxxxx
|
||||
</pre>
|
||||
<p>
|
||||
To see a list of all accounts the <code>sasldblistusers2</code> command can be used.
|
||||
This command expects to be given the path to the libvirt user database, which is kept
|
||||
in <code>/etc/libvirt/passwd.db</code>
|
||||
</p>
|
||||
<pre>
|
||||
# sasldblistusers2 -f /etc/libvirt/passwd.db
|
||||
fred@t60wlan.home.berrange.com: userPassword
|
||||
</pre>
|
||||
<p>
|
||||
Finally, to disable a user's access, the <code>saslpasswd2</code> command can be used
|
||||
again:
|
||||
</p>
|
||||
<pre>
|
||||
# saslpasswd2 -a libvirt -d fred
|
||||
</pre>
|
||||
<h3><a id="ACL_server_kerberos">GSSAPI/Kerberos auth</a></h3>
|
||||
<p>
|
||||
The plain TCP listener of the libvirt daemon defaults to using SASL for authentication.
|
||||
The libvirt SASL config also defaults to GSSAPI, so there is no need to edit the
|
||||
SASL config when using GSSAPI. If the libvirtd TLS or UNIX listeners are used,
|
||||
then the Kerberos session encryption will be disabled since it is not required
|
||||
in these scenarios - only the plain TCP listener needs encryption
|
||||
</p>
|
||||
<p>
|
||||
Some operating systems do not install the SASL kerberos plugin by default. It
|
||||
may be necessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>.
|
||||
To check whether the Kerberos plugin is installed run the <code>pluginviewer</code>
|
||||
program and verify that <code>gssapi</code> is listed, e.g.:
|
||||
</p>
|
||||
<pre>
|
||||
# pluginviewer
|
||||
...snip...
|
||||
Plugin "gssapiv2" [loaded], API version: 4
|
||||
SASL mechanism: GSSAPI, best SSF: 56
|
||||
security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
|
||||
features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN
|
||||
</pre>
|
||||
<p>
|
||||
Next it is necessary for the administrator of the Kerberos realm to
|
||||
issue a principal for the libvirt server. There needs to be one
|
||||
principal per host running the libvirt daemon. The principal should be
|
||||
named <code>libvirt/full.hostname@KERBEROS.REALM</code>. This is
|
||||
typically done by running the <code>kadmin.local</code> command on the
|
||||
Kerberos server, though some Kerberos servers have alternate ways of
|
||||
setting up service principals. Once created, the principal should be
|
||||
exported to a keytab, copied to the host running the libvirt daemon
|
||||
and placed in <code>/etc/libvirt/krb5.tab</code>
|
||||
</p>
|
||||
<pre>
|
||||
# kadmin.local
|
||||
kadmin.local: add_principal libvirt/foo.example.com
|
||||
Enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
|
||||
Re-enter password for principal "libvirt/foo.example.com@EXAMPLE.COM":
|
||||
Principal "libvirt/foo.example.com@EXAMPLE.COM" created.
|
||||
|
||||
kadmin.local: ktadd -k /root/libvirt-foo-example.tab libvirt/foo.example.com@EXAMPLE.COM
|
||||
Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/root/libvirt-foo-example.tab.
|
||||
Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
|
||||
Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES with HMAC/sha1 added to keytab WRFILE:/root/libvirt-foo-example.tab.
|
||||
Entry for principal libvirt/foo.example.com@EXAMPLE.COM with kvno 4, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/root/libvirt-foo-example.tab.
|
||||
|
||||
kadmin.local: quit
|
||||
|
||||
# scp /root/libvirt-foo-example.tab root@foo.example.com:/etc/libvirt/krb5.tab
|
||||
# rm /root/libvirt-foo-example.tab
|
||||
</pre>
|
||||
<p>
|
||||
Any client application wishing to connect to a Kerberos enabled libvirt server
|
||||
merely needs to run <code>kinit</code> to gain a user principal. This may well
|
||||
be done automatically when a user logs into a desktop session, if PAM is set up
|
||||
to authenticate against Kerberos.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,38 +0,0 @@
|
||||
==============
|
||||
Best practices
|
||||
==============
|
||||
|
||||
These are a few guidelines to keep in mind when submitting patches
|
||||
to libvirt: following them will maximise the chance of your patches
|
||||
being reviewed in a timely manner and being accepted into libvirt
|
||||
with minimal back-and-forth.
|
||||
|
||||
- Discuss any large changes on the mailing list first. Post
|
||||
patches early and listen to feedback.
|
||||
|
||||
- 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
|
||||
upstream bug reported in GitLab, put "Fixes: #NNN" in the commit
|
||||
message. For a downstream bug, mention the URL of the bug instead.
|
||||
In both cases 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.
|
||||
|
||||
- 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 syntax-check``) after each
|
||||
patch. A feature does not have to work until the end of a
|
||||
series, but intermediate patches must compile and not cause
|
||||
test-suite failures (this is to preserve the usefulness of
|
||||
``git bisect``, among other things).
|
||||
|
||||
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/>`__.
|
||||
@@ -1,101 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1 >Bindings for other languages and integration API modules</h1>
|
||||
|
||||
<p>
|
||||
Libvirt supports C and C++ directly, and has bindings available
|
||||
for other languages:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>C#</strong>: Arnaud Champion develops
|
||||
<a href="csharp.html">C# bindings</a>.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Go</strong>: Daniel Berrange develops
|
||||
<a href="https://godoc.org/github.com/libvirt/libvirt-go">Go bindings</a>.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Java</strong>: Daniel Veillard develops
|
||||
<a href="java.html">Java bindings</a>.
|
||||
</li>
|
||||
<li>
|
||||
<strong>OCaml</strong>: Richard Jones develops
|
||||
<a href="https://libvirt.org/ocaml/">OCaml bindings</a>.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Perl</strong>: Daniel Berrange develops
|
||||
<a href="http://search.cpan.org/dist/Sys-Virt/">Perl bindings</a>.
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
<strong>PHP</strong>: Radek Hladik started developing
|
||||
<a href="https://libvirt.org/php">PHP bindings</a> in 2010.
|
||||
</p>
|
||||
<p>
|
||||
In February 2011 the binding development has been moved to the libvirt.org website as
|
||||
libvirt-php project.
|
||||
</p>
|
||||
<p>
|
||||
The project is now maintained by Michal Novotny and it's heavily based
|
||||
on Radek's version. For more information, including
|
||||
information on posting patches to libvirt-php, please refer
|
||||
to the <a href="https://libvirt.org/php">PHP bindings</a> site.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
<strong>Python</strong>: Libvirt's python bindings are split to a
|
||||
separate <a href="https://libvirt.org/git/?p=libvirt-python.git">package</a>
|
||||
since version 1.2.0, older versions came with direct support for the
|
||||
Python language.
|
||||
</p>
|
||||
<p>
|
||||
If your libvirt is installed as packages, rather than compiled
|
||||
by you from source code, ensure you have the appropriate
|
||||
package installed.
|
||||
</p>
|
||||
<p>
|
||||
This is named <b>libvirt-python</b> on RHEL/Fedora,
|
||||
<a href="http://packages.ubuntu.com/search?keywords=python-libvirt"><b>python-libvirt</b></a>
|
||||
on Ubuntu, and may be named differently on others.
|
||||
</p>
|
||||
<p>
|
||||
For usage information, see the
|
||||
<a href="python.html">Python API bindings</a> page.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<strong>Ruby</strong>: Chris Lalancette develops
|
||||
<a href="https://libvirt.org/ruby/">Ruby bindings</a>.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Integration API modules:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>D-Bus</strong>: Pavel Hrdina develops
|
||||
<a href="dbus.html">D-Bus API</a>.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
For information on using libvirt on <strong>Windows</strong>
|
||||
<a href="windows.html">please see the Windows support page</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Support, requests or help for libvirt bindings are welcome on the
|
||||
<a href="https://www.redhat.com/mailman/listinfo/libvir-list/">mailing list</a>,
|
||||
as usual try to provide enough background information and make sure
|
||||
you use recent version, see the <a href="bugs.html">help page</a>.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,9 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<browserconfig>
|
||||
<msapplication>
|
||||
<tile>
|
||||
<square150x150logo src="/mstile-150x150.png"/>
|
||||
<TileColor>#b91d47</TileColor>
|
||||
</tile>
|
||||
</msapplication>
|
||||
</browserconfig>
|
||||
@@ -1,161 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
|
||||
<h1>Bug reporting</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="security">Security Issues</a></h2>
|
||||
|
||||
<p>
|
||||
If you think that an issue with libvirt may have security
|
||||
implications, <strong>please do not</strong> publicly
|
||||
report it in the bug tracker, mailing lists, or irc. Libvirt
|
||||
has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
|
||||
that should be used instead. So if your issue has security
|
||||
implications, ignore the rest of this page and follow the
|
||||
<a href="securityprocess.html">security process</a> instead.
|
||||
</p>
|
||||
|
||||
<h2><a id="bugtracking">Bug Tracking</a></h2>
|
||||
|
||||
<p>
|
||||
If you are using libvirt binaries from a Linux distribution
|
||||
check below for distribution specific bug reporting policies
|
||||
first.
|
||||
</p>
|
||||
|
||||
<h2><a id="general">General libvirt bug reports</a></h2>
|
||||
|
||||
<p>
|
||||
Bugs in upstream libvirt code should be reported as issues in the
|
||||
appropriate <a href="https://gitlab.com/libvirt">project on GitLab.</a>
|
||||
Before submitting a ticket, check the existing tickets to see if
|
||||
the bug/feature is already tracked.
|
||||
</p>
|
||||
<p>
|
||||
It's always a good idea to file bug reports, as the process of
|
||||
filing the report always makes it easier to describe the
|
||||
problem, and the bug number provides a quick way of referring to
|
||||
the problem. However, not everybody in the community pays frequent
|
||||
attention to issues, so after you file a bug, asking questions
|
||||
and submitting patches on <a href="contact.html">the libvirt
|
||||
mailing lists</a> will increase your bug's visibility and
|
||||
encourage people to think about your problem. Don't hesitate to
|
||||
ask questions on the list, as others may know of existing
|
||||
solutions or be interested in collaborating with you on finding
|
||||
a solution. Patches are always appreciated, and it's likely
|
||||
that someone else has the same problem you do!
|
||||
</p>
|
||||
<p>
|
||||
If you decide to write code, though, before you begin please
|
||||
read the <a href="hacking.html">contributor guidelines</a>,
|
||||
especially the first point: "Discuss any large changes on the
|
||||
mailing list first. Post patches early and listen to feedback."
|
||||
Few development experiences are more discouraging than spending
|
||||
a bunch of time writing a patch only to have someone point out a
|
||||
better approach on list.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues">View libvirt.git tickets</a></li>
|
||||
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues/new">New libvirt.git ticket</a></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Note bugs in language bindings and other sub-projects should be
|
||||
reported to their corresponding git repository rather than the
|
||||
main libvirt.git linked above.
|
||||
</p>
|
||||
|
||||
<h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
If you are using binaries from <strong>Fedora</strong>, enter
|
||||
tickets against the <code>Fedora</code> product and
|
||||
the <code>libvirt</code> component.
|
||||
<ul>
|
||||
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
If you are using binaries from <strong>Red Hat Enterprise
|
||||
Linux</strong>, enter tickets against the Red Hat Enterprise
|
||||
Linux product that you're using (e.g., Red Hat Enterprise
|
||||
Linux 6) and the <code>libvirt</code> component. Red Hat
|
||||
bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
|
||||
you are a Red Hat customer.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
If you are using binaries from another Linux distribution
|
||||
first follow their own bug reporting guidelines.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
Finally, if you are a contributor to another Linux
|
||||
distribution and would like to have your procedure for
|
||||
filing bugs mentioned here, please mail the libvirt
|
||||
development list.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a id="quality">How to file high quality bug reports</a></h2>
|
||||
|
||||
<p>
|
||||
To increase the likelihood of your bug report being addressed it is
|
||||
important to provide as much information as possible. When filing
|
||||
libvirt bugs use this checklist to see if you are providing enough
|
||||
information:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>The version number of the libvirt build, or SHA1 of the GIT
|
||||
commit</li>
|
||||
<li>The hardware architecture being used</li>
|
||||
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
|
||||
<li>The XML config of the guest domain if relevant</li>
|
||||
<li>For Xen hypervisor, the domain logfiles from /var/log/xen and
|
||||
/var/log/libvirt/libxl</li>
|
||||
<li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
If the bug leads to a tool linked to libvirt crash, then the best
|
||||
is to provide a backtrace along with the scenario used to get the
|
||||
crash, the simplest is to run the program under gdb, reproduce the
|
||||
steps leading to the crash and then issue a gdb "bt -a" command to
|
||||
get the stack trace, attach it to the bug. Note that for the
|
||||
data to be really useful libvirt debug information must be present
|
||||
for example by installing libvirt debuginfo package on Fedora or
|
||||
Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
|
||||
to running gdb.</p>
|
||||
<p>
|
||||
It may also happen that the libvirt daemon itself crashes or gets stuck,
|
||||
in the first case run it (as root) under gdb, and reproduce the sequence
|
||||
leading to the crash, similarly to a normal program provide the
|
||||
"bt" backtrace information to where gdb will have stopped.<br/>
|
||||
But if libvirtd gets stuck, for example seems to stop processing
|
||||
commands, try to attach to the faulty daemon and issue a gdb command
|
||||
"thread apply all bt" to show all the threads backtraces, as in:</p>
|
||||
<pre> # ps -o etime,pid `pgrep libvirt`
|
||||
... note the process id from the output
|
||||
# gdb /usr/sbin/libvirtd
|
||||
.... some information about gdb and loading debug data
|
||||
(gdb) attach $the_daemon_process_id
|
||||
....
|
||||
(gdb) thread apply all bt
|
||||
.... information to attach to the bug
|
||||
(gdb)
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,413 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Control Groups Resource Management</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
The QEMU and LXC drivers make use of the Linux "Control Groups" facility
|
||||
for applying resource management to their virtual machines and containers.
|
||||
</p>
|
||||
|
||||
<h2><a id="requiredControllers">Required controllers</a></h2>
|
||||
|
||||
<p>
|
||||
The control groups filesystem supports multiple "controllers". By default
|
||||
the init system (such as systemd) should mount all controllers compiled
|
||||
into the kernel at <code>/sys/fs/cgroup/$CONTROLLER-NAME</code>. Libvirt
|
||||
will never attempt to mount any controllers itself, merely detect where
|
||||
they are mounted.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The QEMU driver is capable of using the <code>cpuset</code>,
|
||||
<code>cpu</code>, <code>cpuacct</code>, <code>memory</code>,
|
||||
<code>blkio</code> and <code>devices</code> controllers.
|
||||
None of them are compulsory. If any controller is not mounted,
|
||||
the resource management APIs which use it will cease to operate.
|
||||
It is possible to explicitly turn off use of a controller,
|
||||
even when mounted, via the <code>/etc/libvirt/qemu.conf</code>
|
||||
configuration file.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The LXC driver is capable of using the <code>cpuset</code>,
|
||||
<code>cpu</code>, <code>cpuacct</code>, <code>freezer</code>,
|
||||
<code>memory</code>, <code>blkio</code> and <code>devices</code>
|
||||
controllers. The <code>cpuacct</code>, <code>devices</code>
|
||||
and <code>memory</code> controllers are compulsory. Without
|
||||
them mounted, no containers can be started. If any of the
|
||||
other controllers are not mounted, the resource management APIs
|
||||
which use them will cease to operate.
|
||||
</p>
|
||||
|
||||
<h2><a id="currentLayout">Current cgroups layout</a></h2>
|
||||
|
||||
<p>
|
||||
As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been
|
||||
simplified, in order to facilitate the setup of resource control policies by
|
||||
administrators / management applications. The new layout is based on the concepts
|
||||
of "partitions" and "consumers". A "consumer" is a cgroup which holds the
|
||||
processes for a single virtual machine or container. A "partition" is a cgroup
|
||||
which does not contain any processes, but can have resource controls applied.
|
||||
A "partition" will have zero or more child directories which may be either
|
||||
"consumer" or "partition".
|
||||
</p>
|
||||
|
||||
<p>
|
||||
As of libvirt 1.1.1 or later, the cgroups layout will have some slight
|
||||
differences when running on a host with systemd 205 or later. The overall
|
||||
tree structure is the same, but there are some differences in the naming
|
||||
conventions for the cgroup directories. Thus the following docs split
|
||||
in two, one describing systemd hosts and the other non-systemd hosts.
|
||||
</p>
|
||||
|
||||
<h3><a id="currentLayoutSystemd">Systemd cgroups integration</a></h3>
|
||||
|
||||
<p>
|
||||
On hosts which use systemd, each consumer maps to a systemd scope unit,
|
||||
while partitions map to a system slice unit.
|
||||
</p>
|
||||
|
||||
<h4><a id="systemdScope">Systemd scope naming</a></h4>
|
||||
|
||||
<p>
|
||||
The systemd convention is for the scope name of virtual machines / containers
|
||||
to be of the general format <code>machine-$NAME.scope</code>. Libvirt forms the
|
||||
<code>$NAME</code> part of this by concatenating the driver type with the id
|
||||
and truncated name of the guest, and then escaping any systemd reserved
|
||||
characters.
|
||||
So for a guest <code>demo</code> running under the <code>lxc</code> driver,
|
||||
we get a <code>$NAME</code> of <code>lxc-12345-demo</code> which when escaped
|
||||
is <code>lxc\x2d12345\x2ddemo</code>. So the complete scope name is
|
||||
<code>machine-lxc\x2d12345\x2ddemo.scope</code>.
|
||||
The scope names map directly to the cgroup directory names.
|
||||
</p>
|
||||
|
||||
<h4><a id="systemdSlice">Systemd slice naming</a></h4>
|
||||
|
||||
<p>
|
||||
The systemd convention for slice naming is that a slice should include the
|
||||
name of all of its parents prepended on its own name. So for a libvirt
|
||||
partition <code>/machine/engineering/testing</code>, the slice name will
|
||||
be <code>machine-engineering-testing.slice</code>. Again the slice names
|
||||
map directly to the cgroup directory names. Systemd creates three top level
|
||||
slices by default, <code>system.slice</code> <code>user.slice</code> and
|
||||
<code>machine.slice</code>. All virtual machines or containers created
|
||||
by libvirt will be associated with <code>machine.slice</code> by default.
|
||||
</p>
|
||||
|
||||
<h4><a id="systemdLayout">Systemd cgroup layout</a></h4>
|
||||
|
||||
<p>
|
||||
Given this, a possible systemd cgroups layout involving 3 qemu guests,
|
||||
3 lxc containers and 3 custom child slices, would be:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ROOT
|
||||
|
|
||||
+- system.slice
|
||||
| |
|
||||
| +- libvirtd.service
|
||||
|
|
||||
+- machine.slice
|
||||
|
|
||||
+- machine-qemu\x2d1\x2dvm1.scope
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- machine-qemu\x2d2\x2dvm2.scope
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- machine-qemu\x2d3\x2dvm3.scope
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- machine-engineering.slice
|
||||
| |
|
||||
| +- machine-engineering-testing.slice
|
||||
| | |
|
||||
| | +- machine-lxc\x2d11111\x2dcontainer1.scope
|
||||
| |
|
||||
| +- machine-engineering-production.slice
|
||||
| |
|
||||
| +- machine-lxc\x2d22222\x2dcontainer2.scope
|
||||
|
|
||||
+- machine-marketing.slice
|
||||
|
|
||||
+- machine-lxc\x2d33333\x2dcontainer3.scope
|
||||
</pre>
|
||||
|
||||
<h3><a id="currentLayoutGeneric">Non-systemd cgroups layout</a></h3>
|
||||
|
||||
<p>
|
||||
On hosts which do not use systemd, each consumer has a corresponding cgroup
|
||||
named <code>$VMNAME.libvirt-{qemu,lxc}</code>. Each consumer is associated
|
||||
with exactly one partition, which also have a corresponding cgroup usually
|
||||
named <code>$PARTNAME.partition</code>. The exceptions to this naming rule
|
||||
is the top level default partition for virtual machines and containers
|
||||
<code>/machine</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Given this, a possible non-systemd cgroups layout involving 3 qemu guests,
|
||||
3 lxc containers and 2 custom child slices, would be:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ROOT
|
||||
|
|
||||
+- machine
|
||||
|
|
||||
+- qemu-1-vm1.libvirt-qemu
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- qeme-2-vm2.libvirt-qemu
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- qemu-3-vm3.libvirt-qemu
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- engineering.partition
|
||||
| |
|
||||
| +- testing.partition
|
||||
| | |
|
||||
| | +- lxc-11111-container1.libvirt-lxc
|
||||
| |
|
||||
| +- production.partition
|
||||
| |
|
||||
| +- lxc-22222-container2.libvirt-lxc
|
||||
|
|
||||
+- marketing.partition
|
||||
|
|
||||
+- lxc-33333-container3.libvirt-lxc
|
||||
</pre>
|
||||
|
||||
<h2><a id="customPartiton">Using custom partitions</a></h2>
|
||||
|
||||
<p>
|
||||
If there is a need to apply resource constraints to groups of
|
||||
virtual machines or containers, then the single default
|
||||
partition <code>/machine</code> may not be sufficiently
|
||||
flexible. The administrator may wish to sub-divide the
|
||||
default partition, for example into "testing" and "production"
|
||||
partitions, and then assign each guest to a specific
|
||||
sub-partition. This is achieved via a small element addition
|
||||
to the guest domain XML config, just below the main <code>domain</code>
|
||||
element
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
<resource>
|
||||
<partition>/machine/production</partition>
|
||||
</resource>
|
||||
...
|
||||
</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 >= 1.0.5, using
|
||||
the new cgroup layout. The legacy cgroups layout described
|
||||
later in this document did not support customization per guest.
|
||||
</p>
|
||||
|
||||
<h3><a id="createSystemd">Creating custom partitions (systemd)</a></h3>
|
||||
|
||||
<p>
|
||||
Given the XML config above, the admin on a systemd based host would
|
||||
need to create a unit file <code>/etc/systemd/system/machine-production.slice</code>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# cat > /etc/systemd/system/machine-testing.slice <<EOF
|
||||
[Unit]
|
||||
Description=VM testing slice
|
||||
Before=slices.target
|
||||
Wants=machine.slice
|
||||
EOF
|
||||
# systemctl start machine-testing.slice
|
||||
</pre>
|
||||
|
||||
<h3><a id="createNonSystemd">Creating custom partitions (non-systemd)</a></h3>
|
||||
|
||||
<p>
|
||||
Given the XML config above, the admin on a non-systemd based host
|
||||
would need to create a cgroup named '/machine/production.partition'
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# cd /sys/fs/cgroup
|
||||
# for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
|
||||
do
|
||||
mkdir $i/machine/production.partition
|
||||
done
|
||||
# for i in cpuset.cpus cpuset.mems
|
||||
do
|
||||
cat cpuset/machine/$i > cpuset/machine/production.partition/$i
|
||||
done
|
||||
</pre>
|
||||
|
||||
<h2><a id="resourceAPIs">Resource management APIs/commands</a></h2>
|
||||
|
||||
<p>
|
||||
Since libvirt aims to provide an API which is portable across
|
||||
hypervisors, the concept of cgroups is not exposed directly
|
||||
in the API or XML configuration. It is considered to be an
|
||||
internal implementation detail. Instead libvirt provides a
|
||||
set of APIs for applying resource controls, which are then
|
||||
mapped to corresponding cgroup tunables
|
||||
</p>
|
||||
|
||||
<h3>Scheduler tuning</h3>
|
||||
|
||||
<p>
|
||||
Parameters from the "cpu" controller are exposed via the
|
||||
<code>schedinfo</code> command in virsh.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh schedinfo demo
|
||||
Scheduler : posix
|
||||
cpu_shares : 1024
|
||||
vcpu_period : 100000
|
||||
vcpu_quota : -1
|
||||
emulator_period: 100000
|
||||
emulator_quota : -1</pre>
|
||||
|
||||
|
||||
<h3>Block I/O tuning</h3>
|
||||
|
||||
<p>
|
||||
Parameters from the "blkio" controller are exposed via the
|
||||
<code>bkliotune</code> command in virsh.
|
||||
</p>
|
||||
|
||||
|
||||
<pre>
|
||||
# virsh blkiotune demo
|
||||
weight : 500
|
||||
device_weight : </pre>
|
||||
|
||||
<h3>Memory tuning</h3>
|
||||
|
||||
<p>
|
||||
Parameters from the "memory" controller are exposed via the
|
||||
<code>memtune</code> command in virsh.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh memtune demo
|
||||
hard_limit : 580192
|
||||
soft_limit : unlimited
|
||||
swap_hard_limit: unlimited
|
||||
</pre>
|
||||
|
||||
<h3>Network tuning</h3>
|
||||
|
||||
<p>
|
||||
The <code>net_cls</code> is not currently used. Instead traffic
|
||||
filter policies are set directly against individual virtual
|
||||
network interfaces.
|
||||
</p>
|
||||
|
||||
<h2><a id="legacyLayout">Legacy cgroups layout</a></h2>
|
||||
|
||||
<p>
|
||||
Prior to libvirt 1.0.5, the cgroups layout created by libvirt was different
|
||||
from that described above, and did not allow for administrator customization.
|
||||
Libvirt used a fixed, 3-level hierarchy <code>libvirt/{qemu,lxc}/$VMNAME</code>
|
||||
which was rooted at the point in the hierarchy where libvirtd itself was
|
||||
located. So if libvirtd was placed at <code>/system/libvirtd.service</code>
|
||||
by systemd, the groups for each virtual machine / container would be located
|
||||
at <code>/system/libvirtd.service/libvirt/{qemu,lxc}/$VMNAME</code>. In addition
|
||||
to this, the QEMU drivers further child groups for each vCPU thread and the
|
||||
emulator thread(s). This leads to a hierarchy that looked like
|
||||
</p>
|
||||
|
||||
|
||||
<pre>
|
||||
$ROOT
|
||||
|
|
||||
+- system
|
||||
|
|
||||
+- libvirtd.service
|
||||
|
|
||||
+- libvirt
|
||||
|
|
||||
+- qemu
|
||||
| |
|
||||
| +- vm1
|
||||
| | |
|
||||
| | +- emulator
|
||||
| | +- vcpu0
|
||||
| | +- vcpu1
|
||||
| |
|
||||
| +- vm2
|
||||
| | |
|
||||
| | +- emulator
|
||||
| | +- vcpu0
|
||||
| | +- vcpu1
|
||||
| |
|
||||
| +- vm3
|
||||
| |
|
||||
| +- emulator
|
||||
| +- vcpu0
|
||||
| +- vcpu1
|
||||
|
|
||||
+- lxc
|
||||
|
|
||||
+- container1
|
||||
|
|
||||
+- container2
|
||||
|
|
||||
+- container3
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Although current releases are much improved, historically the use of deep
|
||||
hierarchies has had a significant negative impact on the kernel scalability.
|
||||
The legacy libvirt cgroups layout highlighted these problems, to the detriment
|
||||
of the performance of virtual machines and containers.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
230
docs/ci.rst
230
docs/ci.rst
@@ -1,230 +0,0 @@
|
||||
==============================
|
||||
Libvirt Continuous Integration
|
||||
==============================
|
||||
|
||||
.. contents::
|
||||
|
||||
The libvirt project primarily uses GitLab CI for automated testing of Linux
|
||||
builds, and cross-compiled Windows builds. `Travis <https://travis-ci.org/libvirt/libvirt>`_
|
||||
is used for validating macOS builds, and `Jenkins <https://ci.centos.org/view/libvirt>`_
|
||||
is temporarily used for validating FreeBSD builds.
|
||||
|
||||
GitLab CI Dashboard
|
||||
===================
|
||||
|
||||
The dashboard below shows the current status of the GitLab CI jobs for each
|
||||
repository:
|
||||
|
||||
Core project
|
||||
------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
|
||||
* - libvirt
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt/pipelines
|
||||
:alt: libvirt pipeline status
|
||||
|
||||
|
||||
Language bindings
|
||||
-----------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
|
||||
* - libvirt-csharp
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-csharp/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-csharp/pipelines
|
||||
:alt: libvirt-csharp pipeline status
|
||||
|
||||
* - libvirt-go
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-go/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-go/pipelines
|
||||
:alt: libvirt-go pipeline status
|
||||
|
||||
* - libvirt-java
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-java/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-java/pipelines
|
||||
:alt: libvirt-java pipeline status
|
||||
|
||||
* - libvirt-ocaml
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-ocaml/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-ocaml/pipelines
|
||||
:alt: libvirt-ocaml pipeline status
|
||||
|
||||
* - libvirt-perl
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-perl/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-perl/pipelines
|
||||
:alt: libvirt-perl pipeline status
|
||||
|
||||
* - libvirt-php
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-php/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-php/pipelines
|
||||
:alt: libvirt-php pipeline status
|
||||
|
||||
* - libvirt-python
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-python/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-python/pipelines
|
||||
:alt: libvirt-python pipeline status
|
||||
|
||||
* - libvirt-ruby
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-ruby/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-ruby/pipelines
|
||||
:alt: libvirt-ruby pipeline status
|
||||
|
||||
* - libvirt-rust
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-rust/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-rust/pipelines
|
||||
:alt: libvirt-rust pipeline status
|
||||
|
||||
|
||||
Object mappings
|
||||
---------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
|
||||
* - libvirt-cim
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-cim/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-cim/pipelines
|
||||
:alt: libvirt-cim pipeline status
|
||||
|
||||
* - libvirt-dbus
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-dbus/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-dbus/pipelines
|
||||
:alt: libvirt-dbus pipeline status
|
||||
|
||||
* - libvirt-glib
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-glib/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-glib/pipelines
|
||||
:alt: libvirt-glib pipeline status
|
||||
|
||||
* - libvirt-go-xml
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-go-xml/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-go-xml/pipelines
|
||||
:alt: libvirt-go-xml pipeline status
|
||||
|
||||
* - libvirt-snmp
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-snmp/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-snmp/pipelines
|
||||
:alt: libvirt-snmp pipeline status
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
|
||||
* - libvirt-ci
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-ci/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-ci/pipelines
|
||||
:alt: libvirt-ci pipeline status
|
||||
|
||||
* - libvirt-dockerfiles
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-dockerfiles/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-dockerfiles/pipelines
|
||||
:alt: libvirt-dockerfiles pipeline status
|
||||
|
||||
* - libvirt-test-API
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-test-API/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-test-API/pipelines
|
||||
:alt: libvirt-test-API pipeline status
|
||||
|
||||
* - libvirt-tck
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-tck/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-tck/pipelines
|
||||
:alt: libvirt-tck pipeline status
|
||||
|
||||
|
||||
Documentation / websites
|
||||
------------------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
* - libvirt-publican
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-publican/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-publican/pipelines
|
||||
:alt: libvirt-publican pipeline status
|
||||
|
||||
* - libvirt-appdev-guide-python
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-appdev-guide-python/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-appdev-guide-python/pipelines
|
||||
:alt: libvirt-appdev-guide-python pipeline status
|
||||
|
||||
* - libvirt-wiki
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-wiki/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-wiki/pipelines
|
||||
:alt: libvirt-wiki pipeline status
|
||||
|
||||
* - virttools-planet
|
||||
- .. image:: https://gitlab.com/libvirt/virttools-planet/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/virttools-planet/pipelines
|
||||
:alt: virttools-planet pipeline status
|
||||
|
||||
* - virttools-web
|
||||
- .. image:: https://gitlab.com/libvirt/virttools-web/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/virttools-web/pipelines
|
||||
:alt: virttools-web pipeline status
|
||||
|
||||
|
||||
Miscellaneous
|
||||
-------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 80 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Project
|
||||
- Pipeline
|
||||
|
||||
* - libvirt-console-proxy
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-console-proxy/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-console-proxy/pipelines
|
||||
:alt: libvirt-console-proxy pipeline status
|
||||
|
||||
* - libvirt-designer
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-designer/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-designer/pipelines
|
||||
:alt: libvirt-designer pipeline status
|
||||
|
||||
* - libvirt-devaddr
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-devaddr/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-devaddr/pipelines
|
||||
:alt: libvirt-devaddr pipeline status
|
||||
|
||||
* - libvirt-sandbox
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-sandbox/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-sandbox/pipelines
|
||||
:alt: libvirt-sandbox pipeline status
|
||||
|
||||
* - libvirt-sandbox-image
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-sandbox-image/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-sandbox-image/pipelines
|
||||
:alt: libvirt-sandbox-image pipeline status
|
||||
|
||||
* - libvirt-security-notice
|
||||
- .. image:: https://gitlab.com/libvirt/libvirt-security-notice/badges/master/pipeline.svg
|
||||
:target: https://gitlab.com/libvirt/libvirt-security-notice/pipelines
|
||||
:alt: libvirt-security-notice pipeline status
|
||||
@@ -1,924 +0,0 @@
|
||||
============
|
||||
Coding style
|
||||
============
|
||||
|
||||
.. contents::
|
||||
|
||||
Naming conventions
|
||||
==================
|
||||
|
||||
When reading libvirt code, a number of different naming
|
||||
conventions will be evident due to various changes in thinking
|
||||
over the course of the project's lifetime. The conventions
|
||||
documented below should be followed when creating any entirely new
|
||||
files in libvirt. When working on existing files, while it is
|
||||
desirable to apply these conventions, keeping a consistent style
|
||||
with existing code in that particular file is generally more
|
||||
important. The overall guiding principal is that every file, enum,
|
||||
struct, function, macro and typedef name must have a 'vir' or
|
||||
'VIR' prefix. All local scope variable names are exempt, and
|
||||
global variables are exempt, unless exported in a header file.
|
||||
|
||||
File names
|
||||
File naming varies depending on the subdirectory. The preferred
|
||||
style is to have a 'vir' prefix, followed by a name which
|
||||
matches the name of the functions / objects inside the file.
|
||||
For example, a file containing an object 'virHashtable' is
|
||||
stored in files 'virhashtable.c' and 'virhashtable.h'.
|
||||
Sometimes, methods which would otherwise be declared 'static'
|
||||
need to be exported for use by a test suite. For this purpose a
|
||||
second header file should be added with a suffix of 'priv',
|
||||
e.g. 'virhashtablepriv.h'. Use of underscores in file names is
|
||||
discouraged when using the 'vir' prefix style. The 'vir' prefix
|
||||
naming applies to src/util, src/rpc and tests/ directories.
|
||||
Most other directories do not follow this convention.
|
||||
|
||||
Enum type & field names
|
||||
All enums should have a 'vir' prefix in their typedef name, and
|
||||
each following word should have its first letter in uppercase.
|
||||
The enum name should match the typedef name with a leading
|
||||
underscore. The enum member names should be in all uppercase,
|
||||
and use an underscore to separate each word. The enum member
|
||||
name prefix should match the enum typedef name.
|
||||
|
||||
::
|
||||
|
||||
typedef enum _virSocketType virSocketType;
|
||||
enum _virSocketType {
|
||||
VIR_SOCKET_TYPE_IPV4,
|
||||
VIR_SOCKET_TYPE_IPV6,
|
||||
};
|
||||
|
||||
Struct type names
|
||||
All structs should have a 'vir' prefix in their typedef name,
|
||||
and each following word should have its first letter in
|
||||
uppercase. The struct name should be the same as the typedef
|
||||
name with a leading underscore. A second typedef should be
|
||||
given for a pointer to the struct with a 'Ptr' suffix.
|
||||
|
||||
::
|
||||
|
||||
typedef struct _virHashTable virHashTable;
|
||||
typedef virHashTable *virHashTablePtr;
|
||||
struct _virHashTable {
|
||||
...
|
||||
};
|
||||
|
||||
Function names
|
||||
All functions should have a 'vir' prefix in their name,
|
||||
followed by one or more words with first letter of each word
|
||||
capitalized. Underscores should not be used in function names.
|
||||
If the function is operating on an object, then the function
|
||||
name prefix should match the object typedef name, otherwise it
|
||||
should match the filename. Following this comes the verb /
|
||||
action name, and finally an optional subject name. For example,
|
||||
given an object 'virHashTable', all functions should have a
|
||||
name 'virHashTable$VERB' or 'virHashTable$VERB$SUBJECT", e.g.
|
||||
'virHashTableLookup' or 'virHashTableGetValue'.
|
||||
|
||||
Macro names
|
||||
All macros should have a "VIR" prefix in their name, followed
|
||||
by one or more uppercase words separated by underscores. The
|
||||
macro argument names should be in lowercase. Aside from having
|
||||
a "VIR" prefix there are no common practices for the rest of
|
||||
the macro name.
|
||||
|
||||
Code indentation
|
||||
================
|
||||
|
||||
Libvirt's C source code generally adheres to some basic
|
||||
code-formatting conventions. The existing code base is not totally
|
||||
consistent on this front, 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:
|
||||
|
||||
::
|
||||
|
||||
set nocompatible
|
||||
filetype on
|
||||
set autoindent
|
||||
set smartindent
|
||||
set cindent
|
||||
set tabstop=8
|
||||
set shiftwidth=4
|
||||
set expandtab
|
||||
set cinoptions=(0,:0,l1,t0,L3
|
||||
filetype plugin indent on
|
||||
au FileType make setlocal noexpandtab
|
||||
au BufRead,BufNewFile *.am setlocal noexpandtab
|
||||
match ErrorMsg /\s\+$\| \+\ze\t/
|
||||
|
||||
Or if you don't want to mess your ~/.vimrc up, you can save the
|
||||
above into a file called .lvimrc (not .vimrc) located at the root
|
||||
of libvirt source, then install a vim script from
|
||||
http://www.vim.org/scripts/script.php?script_id=1408, which will
|
||||
load the .lvimrc only when you edit libvirt code.
|
||||
|
||||
Code formatting (especially for new code)
|
||||
=========================================
|
||||
|
||||
With new code, we can be even more strict. Please apply the
|
||||
following function (using GNU indent) to any new code. Note that
|
||||
this also gives you an idea of the type of spacing we prefer
|
||||
around operators and keywords:
|
||||
|
||||
::
|
||||
|
||||
indent-libvirt()
|
||||
{
|
||||
indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 \
|
||||
-sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc \
|
||||
--no-tabs "$@"
|
||||
}
|
||||
|
||||
Note that sometimes you'll have to post-process that output
|
||||
further, by piping it through ``expand -i``, since some leading
|
||||
TABs can get through. Usually they're in macro definitions or
|
||||
strings, and should be converted anyhow.
|
||||
|
||||
Libvirt requires a C99 compiler for various reasons. However, most
|
||||
of the code base prefers to stick to C89 syntax unless there is a
|
||||
compelling reason otherwise. For example, it is preferable to use
|
||||
``/* */`` comments rather than ``//``. Also, when declaring local
|
||||
variables, the prevailing style has been to 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.
|
||||
|
||||
::
|
||||
|
||||
if(foo) // Bad
|
||||
if (foo) // Good
|
||||
|
||||
Function implementations must **not** have any whitespace between
|
||||
the function name and the opening bracket. E.g.
|
||||
|
||||
::
|
||||
|
||||
int foo (int wizz) // Bad
|
||||
int foo(int wizz) // Good
|
||||
|
||||
Function calls must **not** have any whitespace between the
|
||||
function name and the opening bracket. E.g.
|
||||
|
||||
::
|
||||
|
||||
bar = foo (wizz); // Bad
|
||||
bar = foo(wizz); // Good
|
||||
|
||||
Function typedefs must **not** have any whitespace between the
|
||||
closing bracket of the function name and opening bracket of the
|
||||
arg list. E.g.
|
||||
|
||||
::
|
||||
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
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.
|
||||
|
||||
::
|
||||
|
||||
while (expr) // single line body; {} is forbidden
|
||||
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 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:
|
||||
|
||||
::
|
||||
|
||||
while (true) // BAD! multi-line body with no braces
|
||||
/* comment... */
|
||||
single_line_stmt();
|
||||
|
||||
Do this instead:
|
||||
|
||||
::
|
||||
|
||||
while (true) { // Always put braces around a multi-line body.
|
||||
/* comment... */
|
||||
single_line_stmt();
|
||||
}
|
||||
|
||||
There is one exception: when the second body line is not at the
|
||||
same indentation level as the first body line:
|
||||
|
||||
::
|
||||
|
||||
if (expr)
|
||||
die("a diagnostic that would make this line"
|
||||
" extend past the 80-column limit"));
|
||||
|
||||
It is safe to omit the braces in the code above, since the
|
||||
further-indented second body line makes it obvious that this is
|
||||
still a single-statement body.
|
||||
|
||||
To reiterate, don't do this:
|
||||
|
||||
::
|
||||
|
||||
if (expr) // BAD: no braces around...
|
||||
while (expr_2) { // ... a multi-line body
|
||||
...
|
||||
}
|
||||
|
||||
Do this, instead:
|
||||
|
||||
::
|
||||
|
||||
if (expr) {
|
||||
while (expr_2) {
|
||||
...
|
||||
}
|
||||
}
|
||||
|
||||
However, there is one exception in the other direction, when even
|
||||
a one-line block should have braces. That occurs when that
|
||||
one-line, brace-less block is an ``if`` or ``else`` block, and the
|
||||
counterpart block **does** use braces. In that case, put braces
|
||||
around both blocks. Also, if the ``else`` block is much shorter
|
||||
than the ``if`` block, consider negating the ``if``-condition and
|
||||
swapping the bodies, putting the short block first and making the
|
||||
longer, multi-line block be the ``else`` block.
|
||||
|
||||
::
|
||||
|
||||
if (expr) {
|
||||
...
|
||||
...
|
||||
}
|
||||
else
|
||||
x = y; // BAD: braceless "else" with braced "then",
|
||||
// and short block last
|
||||
|
||||
if (expr)
|
||||
x = y; // BAD: braceless "if" with braced "else"
|
||||
else {
|
||||
...
|
||||
...
|
||||
}
|
||||
|
||||
Keeping braces consistent and putting the short block first is
|
||||
preferred, especially when the multi-line body is more than a few
|
||||
lines long, because it is easier to read and grasp the semantics
|
||||
of an if-then-else block when the simpler block occurs first,
|
||||
rather than after the more involved block:
|
||||
|
||||
::
|
||||
|
||||
if (!expr) {
|
||||
x = y; // putting the smaller block first is more readable
|
||||
} else {
|
||||
...
|
||||
...
|
||||
}
|
||||
|
||||
But if negating a complex condition is too ugly, then at least add
|
||||
braces:
|
||||
|
||||
::
|
||||
|
||||
if (complex expr not worth negating) {
|
||||
...
|
||||
...
|
||||
} else {
|
||||
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;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Conditional expressions
|
||||
-----------------------
|
||||
|
||||
For readability reasons new code should avoid shortening
|
||||
comparisons to 0 for numeric types. Boolean and pointer
|
||||
comparisions may be shortened. All long forms are okay:
|
||||
|
||||
::
|
||||
|
||||
virFooPtr foos = NULL;
|
||||
size nfoos = 0;
|
||||
bool hasFoos = false;
|
||||
|
||||
GOOD:
|
||||
if (!foos)
|
||||
if (!hasFoos)
|
||||
if (nfoos == 0)
|
||||
if (foos == NULL)
|
||||
if (hasFoos == true)
|
||||
|
||||
BAD:
|
||||
if (!nfoos)
|
||||
if (nfoos)
|
||||
|
||||
New code should avoid the ternary operator as much as possible.
|
||||
Specifically it must never span more than one line or nest:
|
||||
|
||||
::
|
||||
|
||||
BAD:
|
||||
char *foo = baz ?
|
||||
virDoSomethingReallyComplex(driver, vm, something, baz->foo) :
|
||||
NULL;
|
||||
|
||||
char *foo = bar ? bar->baz ? bar->baz->foo : "nobaz" : "nobar";
|
||||
|
||||
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__)
|
||||
|
||||
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)
|
||||
#endif
|
||||
|
||||
C types
|
||||
-------
|
||||
|
||||
Use the right type.
|
||||
|
||||
Scalars
|
||||
~~~~~~~
|
||||
|
||||
- If you're using ``int`` or ``long``, odds are good that there's
|
||||
a better type.
|
||||
- If a variable is counting something, be sure to declare it with
|
||||
an unsigned type.
|
||||
- If it's memory-size-related, use ``size_t`` (use ``ssize_t``
|
||||
only if required).
|
||||
- If it's file-size related, use uintmax_t, or maybe ``off_t``.
|
||||
- If it's file-offset related (i.e., signed), use ``off_t``.
|
||||
- If it's just counting small numbers use ``unsigned int``; (on
|
||||
all but oddball embedded systems, you can assume that that type
|
||||
is at least four bytes wide).
|
||||
- If a variable has boolean semantics, give it the ``bool`` type
|
||||
and use the corresponding ``true`` and ``false`` macros.
|
||||
- In the unusual event that you require a specific width, use a
|
||||
standard type like ``int32_t``, ``uint32_t``, ``uint64_t``,
|
||||
etc.
|
||||
- While using ``bool`` is good for readability, it comes with
|
||||
minor caveats:
|
||||
|
||||
- Don't use ``bool`` in places where the type size must be
|
||||
constant across all systems, like public interfaces and
|
||||
on-the-wire protocols. Note that it would be possible
|
||||
(albeit wasteful) to use ``bool`` in libvirt's logical wire
|
||||
protocol, since XDR maps that to its lower-level ``bool_t``
|
||||
type, which **is** fixed-size.
|
||||
- Don't compare a bool variable against the literal, ``true``,
|
||||
since a value with a logical non-false value need not be
|
||||
``1``. I.e., don't write ``if (seen == true) ...``. Rather,
|
||||
write ``if (seen)...``.
|
||||
|
||||
Of course, take all of the above with a grain of salt. If you're
|
||||
about to use some system interface that requires a type like
|
||||
``size_t``, ``pid_t`` or ``off_t``, use matching types for any
|
||||
corresponding variables.
|
||||
|
||||
Also, if you try to use e.g., ``unsigned int`` as a type, and that
|
||||
conflicts with the signedness of a related variable, sometimes
|
||||
it's best just to use the **wrong** type, if *pulling the thread*
|
||||
and fixing all related variables would be too invasive.
|
||||
|
||||
Finally, while using descriptive types is important, be careful
|
||||
not to go overboard. If whatever you're doing causes warnings, or
|
||||
requires casts, then reconsider or ask for help.
|
||||
|
||||
Pointers
|
||||
~~~~~~~~
|
||||
|
||||
Ensure that all of your pointers are *const-correct*. Unless a
|
||||
pointer is used to modify the pointed-to storage, give it the
|
||||
``const`` attribute. That way, the reader knows up-front that this
|
||||
is a read-only pointer. Perhaps more importantly, if we're
|
||||
diligent about this, when you see a non-const pointer, you're
|
||||
guaranteed that it is used to modify the storage it points to, or
|
||||
it is aliased to another pointer that is.
|
||||
|
||||
Attribute annotations
|
||||
---------------------
|
||||
|
||||
Use the following annotations to help the compiler and/or static
|
||||
analysis tools understand the code better:
|
||||
|
||||
``ATTRIBUTE_NONNULL``
|
||||
passing NULL for this parameter is not allowed
|
||||
|
||||
``ATTRIBUTE_PACKED``
|
||||
force a structure to be packed
|
||||
|
||||
``G_GNUC_FALLTHROUGH``
|
||||
allow code reuse by multiple switch cases
|
||||
|
||||
``G_GNUC_NO_INLINE``
|
||||
the function is mocked in the test suite
|
||||
|
||||
``G_GNUC_NORETURN``
|
||||
the function never returns
|
||||
|
||||
``G_GNUC_NULL_TERMINATED``
|
||||
last parameter must be NULL
|
||||
|
||||
``G_GNUC_PRINTF``
|
||||
validate that the formatting string matches parameters
|
||||
|
||||
``G_GNUC_UNUSED``
|
||||
parameter is unused in this implementation of the function
|
||||
|
||||
``G_GNUC_WARN_UNUSED_RESULT``
|
||||
the return value must be checked
|
||||
|
||||
File handling
|
||||
-------------
|
||||
|
||||
Usage of the ``fdopen()``, ``close()``, ``fclose()`` APIs is
|
||||
deprecated in libvirt code base to help avoiding double-closing of
|
||||
files or file descriptors, which is particularly dangerous in a
|
||||
multi-threaded application. Instead of these APIs, use the macros
|
||||
from virfile.h
|
||||
|
||||
- Open a file from a file descriptor:
|
||||
|
||||
::
|
||||
|
||||
if ((file = VIR_FDOPEN(fd, "r")) == NULL) {
|
||||
virReportSystemError(errno, "%s",
|
||||
_("failed to open file from file descriptor"));
|
||||
return -1;
|
||||
}
|
||||
/* fd is now invalid; only access the file using file variable */
|
||||
|
||||
- Close a file descriptor:
|
||||
|
||||
::
|
||||
|
||||
if (VIR_CLOSE(fd) < 0) {
|
||||
virReportSystemError(errno, "%s", _("failed to close file"));
|
||||
}
|
||||
|
||||
- Close a file:
|
||||
|
||||
::
|
||||
|
||||
if (VIR_FCLOSE(file) < 0) {
|
||||
virReportSystemError(errno, "%s", _("failed to close file"));
|
||||
}
|
||||
|
||||
- Close a file or file descriptor in an error path, without
|
||||
losing the previous ``errno`` value:
|
||||
|
||||
::
|
||||
|
||||
VIR_FORCE_CLOSE(fd);
|
||||
VIR_FORCE_FCLOSE(file);
|
||||
|
||||
String comparisons
|
||||
------------------
|
||||
|
||||
Do not use the strcmp, strncmp, etc functions directly. Instead
|
||||
use one of the following semantically named macros
|
||||
|
||||
- For strict equality:
|
||||
|
||||
::
|
||||
|
||||
STREQ(a,b)
|
||||
STRNEQ(a,b)
|
||||
|
||||
- For case insensitive equality:
|
||||
|
||||
::
|
||||
|
||||
STRCASEEQ(a,b)
|
||||
STRCASENEQ(a,b)
|
||||
|
||||
- For strict equality of a substring:
|
||||
|
||||
::
|
||||
|
||||
STREQLEN(a,b,n)
|
||||
STRNEQLEN(a,b,n)
|
||||
|
||||
- For case insensitive equality of a substring:
|
||||
|
||||
::
|
||||
|
||||
STRCASEEQLEN(a,b,n)
|
||||
STRCASENEQLEN(a,b,n)
|
||||
|
||||
- For strict equality of a prefix:
|
||||
|
||||
::
|
||||
|
||||
STRPREFIX(a,b)
|
||||
|
||||
- To avoid having to check if a or b are NULL:
|
||||
|
||||
::
|
||||
|
||||
STREQ_NULLABLE(a, b)
|
||||
STRNEQ_NULLABLE(a, b)
|
||||
|
||||
String copying
|
||||
--------------
|
||||
|
||||
Do not use the strncpy function. According to the man page, it
|
||||
does **not** guarantee a NULL-terminated buffer, which makes it
|
||||
extremely dangerous to use. Instead, use one of the replacement
|
||||
functions provided by libvirt:
|
||||
|
||||
::
|
||||
|
||||
virStrncpy(char *dest, const char *src, size_t n, size_t destbytes)
|
||||
|
||||
The first two arguments have the same meaning as for strncpy,
|
||||
namely the destination and source of the copy operation. Unlike
|
||||
strncpy, the function will always copy exactly the number of bytes
|
||||
requested and make sure the destination is NULL-terminated, as the
|
||||
source is required to be; sanity checks are performed to ensure
|
||||
the size of the destination, as specified by the last argument, is
|
||||
sufficient for the operation to succeed. On success, 0 is
|
||||
returned; on failure, a value <0 is returned instead.
|
||||
|
||||
::
|
||||
|
||||
virStrcpy(char *dest, const char *src, size_t destbytes)
|
||||
|
||||
Use this variant if you know you want to copy the entire src
|
||||
string into dest.
|
||||
|
||||
::
|
||||
|
||||
virStrcpyStatic(char *dest, const char *src)
|
||||
|
||||
Use this variant if you know you want to copy the entire src
|
||||
string into dest **and** you know that your destination string is
|
||||
a static string (i.e. that sizeof(dest) returns something
|
||||
meaningful). Note that this is a macro, so arguments could be
|
||||
evaluated more than once.
|
||||
|
||||
::
|
||||
|
||||
dst = g_strdup(src);
|
||||
dst = g_strndup(src, n);
|
||||
|
||||
You should avoid using strdup or strndup directly as they do not
|
||||
handle out-of-memory errors, and do not allow a NULL source. Use
|
||||
``g_strdup`` and ``g_strndup`` from GLib which abort on OOM and
|
||||
handle NULL source by returning NULL.
|
||||
|
||||
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 either the
|
||||
`GString <https://developer.gnome.org/glib/stable/glib-Strings.html>`__
|
||||
type from GLib or the virBuffer API. If formatting XML or QEMU
|
||||
command line is needed, use the virBuffer API described in
|
||||
virbuffer.h, since it has helper functions for those.
|
||||
|
||||
Typical usage is as follows:
|
||||
|
||||
::
|
||||
|
||||
char *
|
||||
somefunction(...)
|
||||
{
|
||||
g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
|
||||
|
||||
...
|
||||
|
||||
virBufferAddLit(&buf, "<domain>\n");
|
||||
|
||||
...
|
||||
|
||||
if (some_error)
|
||||
return NULL; /* g_auto will free the memory used so far */
|
||||
|
||||
...
|
||||
|
||||
virBufferAddLit(&buf, "</domain>\n");
|
||||
|
||||
...
|
||||
|
||||
if (virBufferCheckError(&buf) < 0)
|
||||
return NULL;
|
||||
|
||||
return virBufferContentAndReset(&buf);
|
||||
}
|
||||
|
||||
Include files
|
||||
-------------
|
||||
|
||||
There are now quite a large number of include files, both libvirt
|
||||
internal and external, and system includes. To manage all this
|
||||
complexity it's best to stick to the following general plan for
|
||||
all \*.c source files:
|
||||
|
||||
::
|
||||
|
||||
/*
|
||||
* Copyright notice
|
||||
* ....
|
||||
* ....
|
||||
* ....
|
||||
*
|
||||
*/
|
||||
|
||||
#include <config.h> Must come first in every file.
|
||||
|
||||
#include <stdio.h> Any system includes you need.
|
||||
#include <string.h>
|
||||
#include <limits.h>
|
||||
|
||||
#if WITH_NUMACTL Some system includes aren't supported
|
||||
# include <numa.h> everywhere so need these #if guards.
|
||||
#endif
|
||||
|
||||
#include "internal.h" Include this first, after system includes.
|
||||
|
||||
#include "util.h" Any libvirt internal header files.
|
||||
#include "buf.h"
|
||||
|
||||
static int
|
||||
myInternalFunc() The actual code.
|
||||
{
|
||||
...
|
||||
|
||||
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.
|
||||
|
||||
Printf-style functions
|
||||
----------------------
|
||||
|
||||
Whenever you add a new printf-style function, i.e., one with a
|
||||
format string argument and following "..." in its prototype, be
|
||||
sure to use gcc's printf attribute directive in the prototype. For
|
||||
example, here's the one for virCommandAddEnvFormat in
|
||||
vircommand.h:
|
||||
|
||||
::
|
||||
|
||||
void virCommandAddEnvFormat(virCommandPtr cmd, const char *format, ...)
|
||||
G_GNUC_PRINTF(2, 3);
|
||||
|
||||
This makes it so gcc's -Wformat and -Wformat-security options can
|
||||
do their jobs and cross-check format strings with the number and
|
||||
types of arguments.
|
||||
|
||||
When printing to a string, consider using GString or virBuffer for
|
||||
incremental allocations, g_strdup_printf for a one-shot
|
||||
allocation, and g_snprintf for fixed-width buffers. Only use
|
||||
g_sprintf, if you can prove the buffer won't overflow.
|
||||
|
||||
Error message format
|
||||
--------------------
|
||||
|
||||
Error messages visible to the user should be short and
|
||||
descriptive. All error messages are translated using gettext and
|
||||
thus must be wrapped in ``_()`` macro. To simplify the translation
|
||||
work, the error message must not be concatenated from various
|
||||
parts. To simplify searching for the error message in the code the
|
||||
strings should not be broken even if they result into a line
|
||||
longer than 80 columns and any formatting modifier should be
|
||||
enclosed by quotes or other obvious separator. If a string used
|
||||
with ``%s`` can be NULL the NULLSTR macro must be used.
|
||||
|
||||
::
|
||||
|
||||
GOOD: virReportError(VIR_ERR_INTERNAL_ERROR,
|
||||
_("Failed to connect to remote host '%s'"), hostname)
|
||||
|
||||
BAD: virReportError(VIR_ERR_INTERNAL_ERROR,
|
||||
_("Failed to %s to remote host '%s'"),
|
||||
"connect", hostname);
|
||||
|
||||
BAD: virReportError(VIR_ERR_INTERNAL_ERROR,
|
||||
_("Failed to connect "
|
||||
"to remote host '%s'),
|
||||
hostname);
|
||||
|
||||
Use of goto
|
||||
-----------
|
||||
|
||||
The use of goto is not forbidden, and goto is widely used
|
||||
throughout libvirt. While the uncontrolled use of goto will
|
||||
quickly lead to unmaintainable code, there is a place for it in
|
||||
well structured code where its use increases readability and
|
||||
maintainability. In general, if goto is used for error recovery,
|
||||
it's likely to be ok, otherwise, be cautious or avoid it all
|
||||
together.
|
||||
|
||||
The typical use of goto is to jump to cleanup code in the case of
|
||||
a long list of actions, any of which may fail and cause the entire
|
||||
operation to fail. In this case, a function will have a single
|
||||
label at the end of the function. It's almost always ok to use
|
||||
this style. In particular, if the cleanup code only involves
|
||||
free'ing memory, then having multiple labels is overkill. g_free()
|
||||
and most of the functions named XXXFree() in libvirt is required
|
||||
to handle NULL as its arg. This does not apply to libvirt's public
|
||||
APIs. Thus you can safely call free on all the variables even if
|
||||
they were not yet allocated (yes they have to have been
|
||||
initialized to NULL). This is much simpler and clearer than having
|
||||
multiple labels. Note that most of libvirt's type declarations can
|
||||
be marked with either ``g_autofree`` or ``g_autoptr`` which uses
|
||||
the compiler's ``__attribute__((cleanup))`` that calls the
|
||||
appropriate free function when the variable goes out of scope.
|
||||
|
||||
There are a couple of signs that a particular use of goto is not
|
||||
ok:
|
||||
|
||||
- You're using multiple labels. If you find yourself using
|
||||
multiple labels, you're strongly encouraged to rework your code
|
||||
to eliminate all but one of them.
|
||||
- The goto jumps back up to a point above the current line of
|
||||
code being executed. Please use some combination of looping
|
||||
constructs to re-execute code instead; it's almost certainly
|
||||
going to be more understandable by others. One well-known
|
||||
exception to this rule is restarting an i/o operation following
|
||||
EINTR.
|
||||
- The goto jumps down to an arbitrary place in the middle of a
|
||||
function followed by further potentially failing calls. You
|
||||
should almost certainly be using a conditional and a block
|
||||
instead of a goto. Perhaps some of your function's 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>`__
|
||||
|
||||
When using goto, please use one of these standard labels if it
|
||||
makes sense:
|
||||
|
||||
::
|
||||
|
||||
error: A path only taken upon return with an error code
|
||||
cleanup: A path taken upon return with success code + optional error
|
||||
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 ... */
|
||||
}
|
||||
@@ -1,33 +0,0 @@
|
||||
====================
|
||||
Committer guidelines
|
||||
====================
|
||||
|
||||
The AUTHORS files indicates the list of people with commit access
|
||||
right who can actually merge the patches.
|
||||
|
||||
The general rule for committing a patch is to make sure it has
|
||||
been reviewed properly in the mailing-list first, usually if a
|
||||
couple of people gave an ACK or +1 to a patch and nobody raised an
|
||||
objection on the list it should be good to go. If the patch
|
||||
touches a part of the code where you're not the main maintainer,
|
||||
or where you do not have a very clear idea of how things work,
|
||||
it's better to wait for a more authoritative feedback though.
|
||||
Before committing, please also rebuild locally, run 'make check
|
||||
syntax-check', and make sure you don't raise errors.
|
||||
|
||||
An exception to 'review and approval on the list first' is fixing
|
||||
failures to build:
|
||||
|
||||
- if a recently committed patch breaks compilation on a platform
|
||||
or for a given driver, then it's fine to commit a minimal fix
|
||||
directly without getting the review feedback first
|
||||
- if make check or make syntax-check breaks, if there is an
|
||||
obvious fix, it's fine to commit immediately. The patch should
|
||||
still be sent to the list (or tell what the fix was if
|
||||
trivial), and 'make check syntax-check' should pass too, before
|
||||
committing anything
|
||||
- fixes for documentation and code comments can be managed in the
|
||||
same way, but still make sure they get reviewed if non-trivial.
|
||||
- (ir)regular pulls from other repositories or automated updates,
|
||||
such as the keycodemap submodule updates, pulling in new
|
||||
translations or updating the container images for the CI system
|
||||
@@ -1,117 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1><a id="installation">libvirt Installation</a></h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="compiling">Compiling a release tarball</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt uses the standard configure/make/install steps and mandates
|
||||
that the build directory is different that the source directory:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
|
||||
$ cd libvirt-x.x.x
|
||||
$ mkdir build && cd build
|
||||
$ ../configure</pre>
|
||||
|
||||
<p>
|
||||
The <i>configure</i> script can be given options to change its default
|
||||
behaviour.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To get the complete list of the options it can take, pass it the
|
||||
<i>--help</i> option like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ../configure <i>--help</i></pre>
|
||||
|
||||
<p>
|
||||
When you have determined which options you want to use (if any),
|
||||
continue the process.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note the use of <b>sudo</b> with the <i>make install</i> command
|
||||
below. Using sudo is only required when installing to a location your
|
||||
user does not have write access to. Installing to a system location
|
||||
is a good example of this.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If you are installing to a location that your user <i>does</i> have write
|
||||
access to, then you can instead run the <i>make install</i> command
|
||||
without putting <b>sudo</b> before it.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ../configure <i>[possible options]</i>
|
||||
$ make
|
||||
$ <b>sudo</b> <i>make install</i></pre>
|
||||
|
||||
<p>
|
||||
At this point you <b>may</b> have to run ldconfig or a similar utility
|
||||
to update your list of installed shared libs.
|
||||
</p>
|
||||
|
||||
<h2><a id="building">Building from a GIT checkout</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt build process uses GNU autotools, so after obtaining a
|
||||
checkout it is necessary to generate the configure script and Makefile.in
|
||||
templates using the <code>autogen.sh</code> command. By default when
|
||||
the <code>configure</code> script is run from within a GIT checkout, it
|
||||
will turn on -Werror for builds. This can be disabled with
|
||||
--disable-werror, but this is not recommended.
|
||||
</p>
|
||||
|
||||
<p>To build & install libvirt to your home
|
||||
directory the following commands can be run:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ./autogen.sh --prefix=$HOME/usr
|
||||
$ make
|
||||
$ <b>sudo</b> make install</pre>
|
||||
|
||||
<p>
|
||||
Be aware though, that binaries built with a custom prefix will not
|
||||
interoperate with OS vendor provided binaries, since the UNIX socket
|
||||
paths will all be different. To produce a build that is compatible
|
||||
with normal OS vendor prefixes, use
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ./autogen.sh --system
|
||||
$ make
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
When doing this for day-to-day development purposes, it is recommended
|
||||
not to install over the OS vendor provided binaries. Instead simply
|
||||
run libvirt directly from the source tree. For example to run
|
||||
a privileged libvirtd instance
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ su -
|
||||
# service libvirtd stop (or systemctl stop libvirtd.service)
|
||||
# /home/to/your/checkout/src/libvirtd
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It is also possible to run virsh directly from the source tree
|
||||
using the ./run script (which sets some environment variables):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ./run ./tools/virsh ....
|
||||
</pre>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,116 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Contacting the project contributors</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="security">Security Issues</a></h2>
|
||||
|
||||
<p>
|
||||
If you think that an issue with libvirt may have security
|
||||
implications, <strong>please do not</strong> publicly
|
||||
report it in the bug tracker, mailing lists, or irc. Libvirt
|
||||
has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
|
||||
that should be used instead. So if your issue has security
|
||||
implications, ignore the rest of this page and follow the
|
||||
<a href="securityprocess.html">security process</a> instead.
|
||||
</p>
|
||||
|
||||
<h2><a id="email">Mailing lists</a></h2>
|
||||
|
||||
<p>
|
||||
There are three mailing-lists:
|
||||
</p>
|
||||
|
||||
<dl class="mail">
|
||||
<dt><a href="https://www.redhat.com/mailman/listinfo/libvir-list">libvir-list@redhat.com</a> (for development)</dt>
|
||||
<dd>
|
||||
Archives at <a href="https://www.redhat.com/archives/libvir-list">https://www.redhat.com/archives/libvir-list</a>
|
||||
</dd>
|
||||
<dd>
|
||||
This is a high volume mailing list. It is a place for discussions
|
||||
about the <strong>development</strong> of libvirt.
|
||||
</dd>
|
||||
<dd>
|
||||
Topics for discussion include:
|
||||
<ul>
|
||||
<li>New features for libvirt</li>
|
||||
<li>Bug fixing of libvirt</li>
|
||||
<li>New hypervisor drivers</li>
|
||||
<li>Development of language bindings for libvirt API</li>
|
||||
<li>Testing and documentation of libvirt</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://www.redhat.com/mailman/listinfo/libvirt-users">libvirt-users@redhat.com</a> (for users)</dt>
|
||||
<dd>
|
||||
Archives at <a href="https://www.redhat.com/archives/libvirt-users">https://www.redhat.com/archives/libvirt-users</a>
|
||||
</dd>
|
||||
<dd>
|
||||
This is a moderate volume mailing list. It is a place for discussions
|
||||
involving libvirt <strong>users</strong>.
|
||||
</dd>
|
||||
<dd>
|
||||
Topics for discussion include:
|
||||
<ul>
|
||||
<li>Usage of libvirt / virsh</li>
|
||||
<li>Administration of libvirt</li>
|
||||
<li>Deployment of libvirt with hypervisors</li>
|
||||
<li>Development of applications on top of / using the libvirt API(s)</li>
|
||||
<li>Any other topics along these lines</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt><a href="https://www.redhat.com/mailman/listinfo/libvirt-announce">libvirt-announce@redhat.com</a> (for release notices)</dt>
|
||||
<dd>
|
||||
Archives at <a href="https://www.redhat.com/archives/libvirt-announce">https://www.redhat.com/archives/libvirt-announce</a>
|
||||
</dd>
|
||||
<dd>
|
||||
This is a low volume mailing list, with restricted posting, for
|
||||
announcements of new libvirt releases.
|
||||
</dd>
|
||||
<dd>
|
||||
Subscribe to just this if you want to be notified of new releases,
|
||||
without subscribing to either of the other mailing lists.
|
||||
</dd>
|
||||
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
It is recommended but not required that you subscribe before posting
|
||||
to the user and development lists. Posts from non-subscribers will be
|
||||
subject to manual moderation delays. You can subscribe at the linked
|
||||
web pages above.
|
||||
</p>
|
||||
<p>
|
||||
Patches with explanations and provided as attachments are really
|
||||
appreciated, and should be directed to the development mailing list
|
||||
for review and discussion.
|
||||
Wherever possible, please generate the patches by using
|
||||
<code>git format-patch</code> in a git repository clone. Further
|
||||
useful information regarding developing libvirt and/or contributing is
|
||||
available on our <a href="hacking.html">Contributor Guidelines</a>
|
||||
page.
|
||||
</p>
|
||||
|
||||
<h2><a id="irc">IRC discussion</a></h2>
|
||||
|
||||
<p>
|
||||
Some of the libvirt developers may be found on IRC on the <a href="http://oftc.net">OFTC IRC</a>
|
||||
network. Use the settings:
|
||||
</p>
|
||||
<ul>
|
||||
<li>server: irc.oftc.net</li>
|
||||
<li>port: 6667 (the usual IRC port)</li>
|
||||
<li>channel: #virt</li>
|
||||
</ul>
|
||||
<p>
|
||||
NB There is no guarantee that someone will be watching or able to reply
|
||||
promptly, so use the mailing-list if you don't get an answer on the IRC
|
||||
channel.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,142 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Contributing to libvirt</h1>
|
||||
|
||||
<p>
|
||||
This page provides guidance on how to contribute to the
|
||||
libvirt project
|
||||
</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="skills">Contributions required</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt project is always looking for new contributors to
|
||||
participate in ongoing activities. While code development is a
|
||||
major part of the project, assistance is needed in many other
|
||||
areas including documentation writing, bug triage, testing,
|
||||
application integration, website / wiki content management,
|
||||
translation, branding, social media and more. The only
|
||||
requirement is an interest in virtualization and desire to
|
||||
help.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The following is a non-exhaustive list of areas in which
|
||||
people can contribute to libvirt. If you have ideas for
|
||||
other contributions feel free to follow them.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Software development</strong>. The core library / daemon (and
|
||||
thus the bulk of coding) is written in C, but there are
|
||||
language bindings written in Python, Perl, Java, Ruby,
|
||||
Php, OCaml and Go. There are also higher level wrappers
|
||||
mapping libvirt into other object frameworks, such GLib,
|
||||
CIM and SNMP. For those interested in working on the core parts of
|
||||
libvirt, the <a href="hacking.html">contributor guidelines</a> are
|
||||
mandatory reading</li>
|
||||
<li><strong>Translation</strong>. All the libvirt modules aim to support
|
||||
translations where appropriate. All translation is
|
||||
handling outside of the normal libvirt review process,
|
||||
using the <a href="http://fedora.zanata.org">Fedora
|
||||
instance</a> of the Zanata tool. Thus people wishing
|
||||
to contribute to translation should join the Fedora
|
||||
translation team</li>
|
||||
<li><strong>Documentation</strong>. There are docbook guides on various
|
||||
aspects of libvirt, particularly application development
|
||||
guides for the C library and Python, and a virsh command
|
||||
reference. There is thus scope for work by people who are
|
||||
familiar with using or developing against libvirt, to
|
||||
write further content for these guides. There is also a
|
||||
need for people to review existing content for copy editing
|
||||
and identifying gaps in the docs</li>
|
||||
<li><strong>Website / wiki curation</strong>. The bulk of the website is
|
||||
maintained in the primary GIT repository, while the wiki
|
||||
site uses mediawiki. In both cases there is a need for
|
||||
people to both write new content and curate existing
|
||||
content to identify outdated information, improve its
|
||||
organization and target gaps.</li>
|
||||
<li><strong>Testing</strong>. There are a number of tests suites that can run
|
||||
automated tests against libvirt. The coverage of the tests
|
||||
is never complete, so there is a need for people to create
|
||||
new test suites and / or provide environments to actually
|
||||
run the tests in a variety of deployment scenarios.</li>
|
||||
<li><strong>Code analysis</strong>. The libvirt project has access to the coverity
|
||||
tool to run static analysis against the codebase, however,
|
||||
there are other types of code analysis that can be useful.
|
||||
In particular fuzzing of the inputs can be very effective
|
||||
at identifying problematic edge cases.</li>
|
||||
<li><strong>Security handling</strong>. Downstream (operating system) vendors
|
||||
who distribute libvirt may wish to propose a person to
|
||||
be part of the security handling team, to get early access
|
||||
to information about forthcoming vulnerability fixes.</li>
|
||||
<li><strong>Evangalism</strong>. Work done by the project is of no benefit
|
||||
unless the (potential) user community knows that it
|
||||
exists. Thus it is critically important to the health
|
||||
and future growth of the project, that there are a people
|
||||
who evangalise the work created by the project. This can
|
||||
take many forms, writing blog posts (about usage of features,
|
||||
personal user experiences, areas for future work, and more),
|
||||
syndicating docs and blogs via social media, giving user
|
||||
group and/or conference talks about libvirt.</li>
|
||||
<li><strong>User assistance</strong>. Since documentation
|
||||
is never perfect, there are inevitably cases where users
|
||||
will struggle to attain a deployment goal they have, or
|
||||
run into trouble with managing an existing deployment.
|
||||
While some users may be able to contact a software vendor
|
||||
to obtain support, it is common to rely on community help
|
||||
forums such as <a href="contact.html#email">libvirt users
|
||||
mailing list</a>, or sites such as
|
||||
<a href="http://stackoverflow.com/questions/tagged/libvirt">stackoverflow.</a>
|
||||
People who are familiar with libvirt and have ability &
|
||||
desire to help other users are encouraged to participate in
|
||||
these help forums.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="comms">Communication</a></h2>
|
||||
|
||||
<p>
|
||||
For full details on contacting other project contributors
|
||||
read the <a href="contact.html">contact</a> page. There
|
||||
are two main channels that libvirt uses for communication
|
||||
between contributors:
|
||||
</p>
|
||||
|
||||
<h3><a id="email">Mailing lists</a></h3>
|
||||
|
||||
<p>
|
||||
The project has a number of
|
||||
<a href="contact.html#email">mailing lists</a> for
|
||||
general communication between contributors.
|
||||
In general any design discussions and review
|
||||
of contributions will take place on the mailing
|
||||
lists, so it is important for all contributors
|
||||
to follow the traffic.
|
||||
</p>
|
||||
|
||||
<h3><a id="irc">Instant messaging / chat</a></h3>
|
||||
|
||||
<p>
|
||||
Contributors to libvirt are encouraged to join the
|
||||
<a href="contact.html#irc">IRC channel</a> used by
|
||||
the project, where they can have live conversations
|
||||
with others members.
|
||||
</p>
|
||||
|
||||
<h2><a id="outreach">Student / outreach coding programs</a></h2>
|
||||
|
||||
<p>
|
||||
Since 2016, the libvirt project directly participates as an
|
||||
organization in the <a href="http://wiki.libvirt.org/page/Google_Summer_of_Code_Ideas">Google Summer of Code program</a>. Prior to
|
||||
this the project had a number of students in the program
|
||||
via a joint application with the QEMU project. People are
|
||||
encouraged to look at both the libvirt and QEMU programs
|
||||
to identify potentially interesting projects to work on.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,491 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>C# API bindings</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="description">Description</a></h2>
|
||||
|
||||
<p>
|
||||
The C# libvirt bindings are a class library. They use a Microsoft
|
||||
Visual Studio project architecture, and have been tested with Windows
|
||||
.NET, and Mono, on both Linux and Windows.
|
||||
</p>
|
||||
<p>
|
||||
Compiling them produces <b>LibvirtBindings.dll</b>, which can
|
||||
be added as a .NET reference to any .NET project needing access
|
||||
to libvirt.
|
||||
</p>
|
||||
|
||||
<h2><a id="requirements">Requirements</a></h2>
|
||||
|
||||
<p>
|
||||
These bindings depend upon the libvirt libraries being installed.
|
||||
</p>
|
||||
<p>
|
||||
In the .NET case, this is <b>libvirt-0.dll</b>, produced from
|
||||
compiling libvirt for windows.
|
||||
</p>
|
||||
|
||||
<!-- 2010-10-19 JC: Commented out until we have C# tarballs to download
|
||||
<h2><a id="getting">Getting them</a></h2>
|
||||
|
||||
<p>
|
||||
The latest versions of the libvirt C# bindings can be downloaded from:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="ftp://libvirt.org/libvirt/csharp/">libvirt.org FTP server</a></li>
|
||||
<li><a href="https://libvirt.org/sources/csharp/">libvirt.org HTTP server</a></li>
|
||||
</ul>
|
||||
-->
|
||||
|
||||
<h2><a id="git">GIT source repository</a></h2>
|
||||
<p>
|
||||
The C# bindings source code is maintained in a <a
|
||||
href="http://git-scm.com/">git</a> repository available on
|
||||
<a href="https://libvirt.org/git/">libvirt.org</a>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git clone https://libvirt.org/git/libvirt-csharp.git
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
They can also be browsed online:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<a href="https://libvirt.org/git/?p=libvirt-csharp.git;a=summary">https://libvirt.org/git/?p=libvirt-csharp.git;a=summary</a>
|
||||
</pre>
|
||||
|
||||
<h2><a id="usage">Usage</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt C# bindings class library exposes the <b>Libvirt</b>
|
||||
namespace. This namespace exposes all of the needed types (enum,
|
||||
struct), plus many classes exposing the libvirt API methods.
|
||||
</p>
|
||||
<p>
|
||||
These classes are grouped into functional areas, with each class
|
||||
exposing libvirt methods related to that area.
|
||||
</p>
|
||||
<p>
|
||||
For example, the libvirt methods related to connections, such as
|
||||
<b>virConnectOpenAuth</b> and <b>virConnectNumOfDomains</b>, are in
|
||||
the <b>Connect</b> class.
|
||||
<br />
|
||||
They are accessed as <b>Connect.OpenAuth</b>, and
|
||||
<b>Connect.NumOfDomains</b> respectively.
|
||||
</p>
|
||||
<p>
|
||||
In the same manner, the other class name mappings are:
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr><th>Name of libvirt function</th><th>C# class name</th></tr>
|
||||
<tr><td>virDomain...</td><td>Domain</td></tr>
|
||||
<tr><td>virEvent...</td><td>Event</td></tr>
|
||||
<tr><td>virInterface...</td><td>Interface</td></tr>
|
||||
<tr><td>virNetwork...</td><td>Network</td></tr>
|
||||
<tr><td>virNode...</td><td>Node</td></tr>
|
||||
<tr><td>virSecret...</td><td>Secret</td></tr>
|
||||
<tr><td>virStoragePool...</td><td>StoragePool</td></tr>
|
||||
<tr><td>virStorageVolume...</td><td>StorageVolume</td></tr>
|
||||
<tr><td>virStream...</td><td>Stream</td></tr>
|
||||
</table>
|
||||
<p>
|
||||
There are some additions as well:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
There is a class named <b>Library</b>, exposing the
|
||||
<b>virGetVersion</b> and <b>virInitialize</b> methods
|
||||
</li>
|
||||
<li>
|
||||
There is a class named <b>Errors</b>, exposing the error
|
||||
related methods. For example, <b>virSetErrorFunc</b> and
|
||||
<b>virConnResetLastError</b>.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="authors">Authors</a></h2>
|
||||
|
||||
<p>
|
||||
The C# bindings are the work of Arnaud Champion
|
||||
<<a href="mailto:arnaud.champion AT devatom.fr">arnaud.champion AT devatom.fr</a>>,
|
||||
based upon the previous work of Jaromír Červenka.
|
||||
</p>
|
||||
|
||||
<h2><a id="notes">Test Configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Testing is performed using the following configurations:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Windows 7 (64 bits) / .Net 4</li>
|
||||
<li>Windows 7 (64 bits) / Mono 2.6.7 (compiled in 32 bits)</li>
|
||||
<li>Ubuntu 10.10 amd64 / Mono 2.6.7 (compiled in 64 bits)</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="type">Type Coverage</a></h2>
|
||||
|
||||
<p>
|
||||
Coverage of the libvirt types is:
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr><th>Type</th><th>Name</th><th>Binding?</th><th>Tested?</th><th>Sample Code?</th><th>Works?</th><th>Tested .Net/Windows Works?</th><th>Tested Mono (32-bit)/Windows Works?</th><th>Tested Mono (64-bit)/Linux Works?</th></tr>
|
||||
<tr><td>enum</td><td>virCPUCompareResult</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virConnect</td><td>Yes, an IntPtr as the struct is not public</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virConnectAuth</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>struct</td><td>virConnectCredential</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virConnectCredentialType</td><td>Yes</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virConnectFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomain</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainBlockInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainBlockStatsInfo</td><td>Yes</td><td>Yes</td><td>virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainCoreDumpFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainCreateFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainDeviceModifyFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventDefinedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>struct</td><td>virDomainEventGraphicsAddress</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventGraphicsAddressType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventGraphicsPhase</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainEventGraphicsSubject</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainEventGraphicsSubjectIdentity</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventID</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventIOErrorAction</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventResumedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventStartedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventStoppedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventSuspendedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventUndefinedDetailType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>enum</td><td>virDomainEventWatchdogAction</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainInfo</td><td>Yes</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>struct</td><td>virDomainInterfaceStatsStruct</td><td>Yes</td><td>Yes</td><td>virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>struct</td><td>virDomainJobInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainJobType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainMemoryFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainMemoryStatStruct</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainMemoryStatTags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainMigrateFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virDomainSnapshot</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainSnapshotDeleteFlags</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainState</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virDomainXMLFlags</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virEventHandleType</td><td>Yes</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>struct</td><td>virInterface</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virInterfaceXMLFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virNWFilter</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virNetwork</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virNodeDevice</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virNodeInfo</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virSchedParameter</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virSchedParameterType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virSecret</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virSecretUsageType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virSecurityLabel</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virSecurityModel</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStoragePoolBuildFlags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStoragePoolDeleteFlags</td><td>Yes</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virStoragePoolInfo</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virStoragePool</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStoragePoolState</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virStorageVol</td><td>Yes, an IntPtr as the struct is not public</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStorageVolDeleteFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virStorageVolInfo</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStorageVolType</td><td>Yes</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virStream</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStreamEventType</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virStreamFlags</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virVcpuInfo</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>enum</td><td>virVcpuState</td><td>No</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>struct</td><td>virError</td><td>Yes</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainStats</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
</table>
|
||||
|
||||
<p></p>
|
||||
|
||||
<h2><a id="funccover">Function Coverage</a></h2>
|
||||
|
||||
<p>
|
||||
Coverage of the libvirt functions is:
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr><th>Name</th><th>Binding?</th><th>Type?</th><th>Tested?</th><th>Sample Code?</th><th>Working?</th><th>Tested .Net/Windows Works?</th><th>Tested Mono (32-bit)/Windows Works?</th><th>Tested Mono (64-bit)/Linux Works?</th></tr>
|
||||
<tr><td>virConnectAuthCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectBaselineCPU</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectClose</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectCompareCPU</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventDeregister</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventDeregisterAny</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventGenericCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventGraphicsCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventIOErrorCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventIOErrorReasonCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventRTCChangeCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventRegister</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectDomainEventRegisterAny</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainEventWatchdogCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainXMLFromNative</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectDomainXMLToNative</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectFindStoragePoolSources</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetCapabilities</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetHostname</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetLibVersion</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetMaxVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetType</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetURI</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectGetVersion</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectIsEncrypted</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectIsSecure</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListDefinedDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectListDefinedInterfaces </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListDefinedNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListDefinedStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectListInterfaces</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes, if the host handle the method</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListNWFilters </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListSecrets</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectListStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectNumOfDefinedDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectNumOfDefinedInterfaces</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfDefinedNetworks</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfDefinedStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfDomains</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectNumOfInterfaces</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfNWFilters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfNetworks </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfSecrets</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectNumOfStoragePools</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectOpen</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpen, virEventRegisterImpl, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectOpenAuth</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnectOpenReadOnly</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virConnectRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainAbortJob</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainAttachDevice</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainAttachDeviceFlags</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainBlockPeek</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainBlockStats</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainCoreDump</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainCreateLinux</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainCreateWithFlags</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainCreateXML</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainDetachDevice</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainDetachDeviceFlags</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetBlockInfo</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainGetJobInfo</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetMaxMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetMaxVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetName</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainGetOSType</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetSchedulerParameters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetSchedulerType</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetSecurityLabel</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetVcpus</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainHasCurrentSnapshot</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainHasManagedSaveImage</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainInterfaceStats </td><td>No</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainIsPersistent</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainLookupByID</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectOpenAuth, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td>virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virDomainLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainManagedSave </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainManagedSaveRemove</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainMemoryPeek</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainMemoryStats</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainMigrate</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainMigrateSetMaxDowntime</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainMigrateToURI </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainPinVcpu</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainReboot</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainRef </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainRestore</td><td>Yes </td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainResume </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainRevertToSnapshot</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSave</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSetMaxMemory </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSetMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSetSchedulerParameters</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSetVcpus</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainShutdown</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotCreateXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotCurrent</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotDelete</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotListNames</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotLookupByName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSnapshotNum</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainSuspend</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virDomainUpdateDeviceFlags</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventAddHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventAddTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventHandleCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virEventRegisterImpl</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virEventRemoveHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventRemoveTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventTimeoutCallback</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virEventUpdateHandleFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virEventUpdateTimeoutFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virFreeCallback</td><td>Yes</td><td>function</td><td>Yes</td><td>virEventRegisterImpl</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virGetVersion</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInitialize</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceCreate</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceDestroy</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceGetConnect</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceGetMACString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceIsActive</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceLookupByMACString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceLookupByName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceRef </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virInterfaceUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterGetUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterLookupByName </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterLookupByUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterLookupByUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterRef </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNWFilterUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkCreateXML</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetBridgeName</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetName</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetUUIDString </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkIsPersistent</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkSetAutostart</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNetworkUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceCreateXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceDestroy</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceDettach</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceFree</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceGetName</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceGetParent</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceListCaps</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceNumOfCaps</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceReAttach</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeDeviceReset</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeGetCellsFreeMemory</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeGetFreeMemory</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeGetInfo</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeGetSecurityModel </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeListDevices</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virNodeNumOfDevices</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretDefineXML</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretFree </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetConnect</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetUUIDString </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetUsageID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetUsageType</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetValue</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretGetXMLDesc</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretLookupByUUID</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretLookupByUUIDString</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretLookupByUsage</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretSetValue</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virSecretUndefine</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolBuild</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolCreate</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolCreateXML </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolDefineXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolDelete</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolDestroy</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolFree</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetAutostart</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetConnect</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetUUIDString</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolGetXMLDesc</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolIsActive</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolIsPersistent</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolListVolumes</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolLookupByUUID</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolLookupByUUIDString</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolLookupByVolume</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolNumOfVolumes</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolRefresh</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolSetAutostart</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStoragePoolUndefine</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolCreateXML</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolCreateXMLFrom</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolDelete</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolFree</td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetConnect </td><td>Yes</td><td>function</td><td>No</td><td></td><td>Maybe</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetInfo</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetKey</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetPath</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolGetXMLDesc </td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolLookupByKey</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolLookupByName</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolLookupByPath</td><td>Yes</td><td>function</td><td>Yes</td><td></td><td>Yes</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolRef</td><td>Yes</td><td>function</td><td>No</td><td></td><td>No</td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStorageVolWipe</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamAbort </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamEventAddCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamEventCallback</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamEventRemoveCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamEventUpdateCallback</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamFinish </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamFree </td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamNew</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamRecv</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamRecvAll</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamRef</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamSend</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamSendAll</td><td>No</td><td>function</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamSinkFunc</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virStreamSourceFunc</td><td>No</td><td>delegate</td><td></td><td></td><td></td><td></td><td></td><td></td></tr>
|
||||
<tr><td>virGetLastError</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectSetErrorFunc</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virConnSetErrorFunc</td><td>Yes</td><td>function</td><td>Yes</td><td>virConnectSetErrorFunc</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
<tr><td>virErrorFunc</td><td>Yes</td><td>delegate</td><td>Yes</td><td>virConnectSetErrorFunc, virDomainInfos</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td></tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
||||
692
docs/daemons.rst
692
docs/daemons.rst
@@ -1,692 +0,0 @@
|
||||
===============
|
||||
Libvirt Daemons
|
||||
===============
|
||||
|
||||
.. contents::
|
||||
|
||||
A libvirt deployment for accessing one of the stateful drivers will require
|
||||
one or more daemons to be deployed on the virtualization host. There are a
|
||||
number of ways the daemons can be configured which will be outlined in this
|
||||
page.
|
||||
|
||||
Architectural options
|
||||
=====================
|
||||
|
||||
Monolithic vs modular daemons
|
||||
-----------------------------
|
||||
|
||||
Traditionally libvirt provided a single monolithic daemon called ``libvirtd``
|
||||
which exposed support for all the stateful drivers, both primary hypervisor
|
||||
drivers and secondary supporting drivers. It also enables secure remote access
|
||||
from clients running off host.
|
||||
|
||||
Work is underway for the monolithic daemon to be replaced by a new set of
|
||||
modular daemons ``virt${DRIVER}d``, each one servicing a single stateful
|
||||
driver. A further ``virtproxyd`` daemon will provide secure remote access, as
|
||||
well as backcompatibility for clients using the UNIX socket path of the
|
||||
monolithic daemon.
|
||||
|
||||
The change to modular daemons should not affect API functionality used by
|
||||
management applications. It will, however, have an impact on host provisioning
|
||||
tools since there are new systemd services and configuration files to be
|
||||
managed.
|
||||
|
||||
Currently both monolithic and modular daemons are built by default, but the RPC
|
||||
client still prefers connecting to the monolithic daemon. It is intended to
|
||||
switch the RPC client to prefer the modular daemons in the near future. At
|
||||
least 1 year after this switch (but not more than 2 years), the monolithic
|
||||
daemon will be deleted entirely.
|
||||
|
||||
Operating modes
|
||||
---------------
|
||||
|
||||
The libvirt daemons, whether monolithic or modular, can often operate in two
|
||||
modes
|
||||
|
||||
* *System mode* - the daemon is running as the root user account, enabling
|
||||
access to its full range of functionality. A read-write connection to
|
||||
daemons in system mode **typically implies privileges equivalent to having
|
||||
a root shell**. Suitable `authentication mechanisms <auth.html>`__ **must
|
||||
be enabled** to secure it against untrustworthy clients/users.
|
||||
|
||||
* *Session mode* - the daemon is running as any non-root user account,
|
||||
providing access to a more restricted range of functionality. Only client
|
||||
apps/users running under **the same UID are permitted to connect**, thus a
|
||||
connection does not imply any elevation of privileges.
|
||||
|
||||
Not all drivers support session mode and as such the corresponding
|
||||
modular daemon may not support running in this mode
|
||||
|
||||
|
||||
Monolithic driver daemon
|
||||
========================
|
||||
|
||||
The monolithic daemon is known as ``libvirtd`` and has historically been the
|
||||
default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf``
|
||||
|
||||
|
||||
Monolithic sockets
|
||||
------------------
|
||||
|
||||
When running in system mode, ``libvirtd`` exposes three UNIX domain sockets, and
|
||||
optionally, one or two TCP sockets:
|
||||
|
||||
* ``/var/run/libvirt/libvirt-sock`` - the primary socket for accessing libvirt
|
||||
APIs, with full read-write privileges. A connection to this socket gives the
|
||||
client privileges that are equivalent to having a root shell. This is the
|
||||
socket that most management applications connect to by default.
|
||||
|
||||
* ``/var/run/libvirt/libvirt-sock-ro`` - the secondary socket for accessing
|
||||
libvirt APIs, with limited read-only privileges. A connection to this socket
|
||||
gives the ability to query the existence of objects and monitor some aspects
|
||||
of their operation. This is the socket that most management applications
|
||||
connect to when requesting read only mode. Typically this is what a
|
||||
monitoring app would use.
|
||||
|
||||
* ``/var/run/libvirt/libvirt-admin-sock`` - the administrative socket for
|
||||
controlling operation of the daemon itself (as opposed to drivers it is
|
||||
running). This can be used to dynamically reconfigure some aspects of the
|
||||
daemon and monitor/control connected clients.
|
||||
|
||||
* ``TCP 16509`` - the non-TLS socket for remotely accessing the libvirt APIs,
|
||||
with full read-write privileges. A connection to this socket gives the
|
||||
client privileges that are equivalent to having a root shell. Since it does
|
||||
not use TLS, an `authentication mechanism <auth.html>`__ that provides
|
||||
encryption must be used. Only the GSSAPI/Kerberos mechanism is capable of
|
||||
satisfying this requirement. In general applications should not use this
|
||||
socket except for debugging in a development/test environment.
|
||||
|
||||
* ``TCP 16514`` - the TLS socket for remotely accessing the libvirt APIs,
|
||||
with full read-write privileges. A connection to this socket gives the
|
||||
client privileges that are equivalent to having a root shell. Access control
|
||||
can be enforced either through validation of `x509 certificates
|
||||
<tlscerts.html>`__, and/or by enabling an `authentication mechanism
|
||||
<auth.html>`__.
|
||||
|
||||
NB, some distros will use ``/run`` instead of ``/var/run``.
|
||||
|
||||
When running in session mode, ``libvirtd`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/libvirt-sock`` - the primary socket for accessing
|
||||
libvirt APIs, with full read-write privileges. A connection to this socket
|
||||
does not alter the privileges that the client already has. This is the
|
||||
socket that most management applications connect to by default.
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/libvirt-admin-sock`` - the administrative socket
|
||||
for controlling operation of the daemon itself (as opposed to drivers it is
|
||||
running). This can be used to dynamically reconfigure some aspects of the
|
||||
daemon and monitor/control connected clients.
|
||||
|
||||
Notice that the session mode does not have a separate read-only socket. Since
|
||||
the clients must be running as the same user as the daemon itself, there is
|
||||
not any security benefit from attempting to enforce a read-only mode.
|
||||
|
||||
``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
|
||||
such as ``/run/user/$UID``.
|
||||
|
||||
|
||||
Monolithic Systemd Integration
|
||||
------------------------------
|
||||
|
||||
When the ``libvirtd`` daemon is managed by ``systemd`` a number of desirable
|
||||
features are available, most notably socket activation.
|
||||
|
||||
Libvirt ships a number of unit files for controlling ``libvirtd``:
|
||||
|
||||
* ``libvirtd.service`` - the main unit file for launching the ``libvirtd``
|
||||
daemon in system mode. The command line arguments passed can be configured by
|
||||
editing ``/etc/sysconfig/libvirtd``. This is typically only needed to control
|
||||
the use of the auto shutdown timeout value. It is recommended that this
|
||||
service unit be configured to start on boot. This is because various
|
||||
libvirt drivers support autostart of their objects. If it is known that
|
||||
autostart is not required, this unit can be left to start on demand.
|
||||
|
||||
* ``libvirtd.socket`` - the unit file corresponding to the main read-write
|
||||
UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to
|
||||
be started on boot by default.
|
||||
|
||||
* ``libvirtd-ro.socket`` - the unit file corresponding to the main read-only
|
||||
UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended
|
||||
to be started on boot by default.
|
||||
|
||||
* ``libvirtd-admin.socket`` - the unit file corresponding to the administrative
|
||||
UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This socket is
|
||||
recommended to be started on boot by default.
|
||||
|
||||
* ``libvirtd-tcp.socket`` - the unit file corresponding to the TCP 16509 port
|
||||
for non-TLS remote access. This socket should not be configured to start on
|
||||
boot until the administrator has configured a suitable authentication
|
||||
mechanism.
|
||||
|
||||
* ``libvirtd-tls.socket`` - the unit file corresponding to the TCP 16509 port
|
||||
for TLS remote access. This socket should not be configured to start on boot
|
||||
until the administrator has deployed x509 certificates and optionally
|
||||
configured a suitable authentication mechanism.
|
||||
|
||||
NB, some distros will use ``/etc/default`` instead of ``/etc/sysconfig``.
|
||||
|
||||
The socket unit files are newly introduced in 5.6.0. On newly installed hosts
|
||||
the UNIX socket units should be enabled by default. When upgrading an existing
|
||||
host from a previous version of libvirt, the socket unit files will be masked
|
||||
if ``libvirtd`` is currently configured to use the ``--listen`` argument, since
|
||||
the ``--listen`` argument is mutually exclusive with use of socket activation.
|
||||
|
||||
When systemd socket activation is used a number of configuration settings in
|
||||
``libvirtd.conf`` are no longer honoured. Instead these settings must be
|
||||
controlled via the system unit files
|
||||
|
||||
* ``listen_tcp`` - TCP socket usage is enabled by starting the
|
||||
``libvirtd-tcp.socket`` unit file.
|
||||
|
||||
* ``listen_tls`` - TLS socket usage is enabled by starting the
|
||||
``libvirtd-tls.socket`` unit file.
|
||||
|
||||
* ``tcp_port`` - Port for the non-TLS TCP socket, controlled via the
|
||||
``ListenStream`` parameter in the ``libvirtd-tcp.socket`` unit file.
|
||||
|
||||
* ``tls_port`` - Port for the TLS TCP socket, controlled via the
|
||||
``ListenStream`` parameter in the ``libvirtd-tls.socket`` unit file.
|
||||
|
||||
* ``listen_addr`` - IP address to listen on, independently controlled via the
|
||||
``ListenStream`` parameter in the ``libvirtd-tcp.socket`` or
|
||||
``libvirtd-tls.socket`` unit files.
|
||||
|
||||
* ``unix_sock_group`` - UNIX socket group owner, controlled via the
|
||||
``SocketGroup`` parameter in the ``libvirtd.socket`` and
|
||||
``libvirtd-ro.socket`` unit files
|
||||
|
||||
* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``libvirtd-ro.socket`` unit file
|
||||
|
||||
* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
|
||||
the ``SocketMode`` parameter in the ``libvirtd.socket`` unit file
|
||||
|
||||
* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``libvirtd-admin.socket`` unit file
|
||||
|
||||
* ``unix_sock_dir`` - directory in which all UNIX sockets are created
|
||||
independently controlled via the ``ListenStream`` parameter in any of the
|
||||
``libvirtd.socket``, ``libvirtd-ro.socket`` and ``libvirtd-admin.socket`` unit
|
||||
files.
|
||||
|
||||
Systemd releases prior to version 227 lacked support for passing the activation
|
||||
socket unit names into the service. When using these old versions, the
|
||||
``tcp_port``, ``tls_port`` and ``unix_sock_dir`` settings in ``libvirtd.conf``
|
||||
must be changed in lock-step with the equivalent settings in the unit files to
|
||||
ensure that ``libvirtd`` can identify the sockets.
|
||||
|
||||
|
||||
Modular driver daemons
|
||||
======================
|
||||
|
||||
The modular daemons are named after the driver which they are running, with
|
||||
the pattern ``virt${DRIVER}d`` and will become the default in future libvirt.
|
||||
They are configured via the files ``/etc/libvirt/virt${DRIVER}d.conf``
|
||||
|
||||
The following modular daemons currently exist for hypervisor drivers
|
||||
|
||||
* ``virtqemud`` - the QEMU management daemon, for running virtual machines
|
||||
on UNIX platforms, optionally with KVM acceleration, in either system or
|
||||
session mode
|
||||
* ``virtxend`` - the Xen management daemon, for running virtual machines
|
||||
on the Xen hypervisor, in system mode only
|
||||
* ``virtlxcd`` - the Linux Container management daemon, for running LXC guests
|
||||
in system mode only
|
||||
* ``virtbhyved`` - the BHyve management daemon, for running virtual machines
|
||||
on FreeBSD with the BHyve hypervisor, in system mode.
|
||||
* ``virtvboxd`` - the VirtualBox management daemon, for running virtual machines
|
||||
on UNIX platforms.
|
||||
|
||||
The additional modular daemons service secondary drivers
|
||||
|
||||
* ``virtinterfaced`` - the host NIC management daemon, in system mode only
|
||||
* ``virtnetworkd`` - the virtual network management daemon, in system mode only
|
||||
* ``virtnodedevd`` - the host physical device management daemon, in system mode
|
||||
only
|
||||
* ``virtnwfilterd`` - the host firewall management daemon, in system mode only
|
||||
* ``virtsecretd`` - the host secret management daemon, in system or session mode
|
||||
* ``virtstoraged`` - the host storage management daemon, in system or session
|
||||
mode
|
||||
|
||||
|
||||
Modular Sockets
|
||||
---------------
|
||||
|
||||
When running in system mode, ``virt${DRIVER}d`` exposes three UNIX domain
|
||||
sockets:
|
||||
|
||||
* ``/var/run/libvirt/virt${DRIVER}d-sock`` - the primary socket for accessing
|
||||
libvirt APIs, with full read-write privileges. For many of the daemons, a
|
||||
connection to this socket gives the client privileges that are equivalent to
|
||||
having a root shell. This is the socket that most management applications
|
||||
connect to by default.
|
||||
|
||||
* ``/var/run/libvirt/virt${DRIVER}d-sock-ro`` - the secondary socket for
|
||||
accessing libvirt APIs, with limited read-only privileges. A connection to
|
||||
this socket gives the ability to query the existence of objects and monitor
|
||||
some aspects of their operation. This is the socket that most management
|
||||
applications connect to when requesting read only mode. Typically this is
|
||||
what a monitoring app would use.
|
||||
|
||||
* ``/var/run/libvirt/virt${DRIVER}d-admin-sock`` - the administrative socket for
|
||||
controlling operation of the daemon itself (as opposed to drivers it is
|
||||
running). This can be used to dynamically reconfigure some aspects of the
|
||||
daemon and monitor/control connected clients.
|
||||
|
||||
NB, some distros will use ``/run`` instead of ``/var/run``.
|
||||
|
||||
When running in session mode, ``virt${DRIVER}d`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-sock`` - the primary socket for
|
||||
accessing libvirt APIs, with full read-write privileges. A connection to this
|
||||
socket does not alter the privileges that the client already has. This is the
|
||||
socket that most management applications connect to by default.
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-admin-sock`` - the administrative
|
||||
socket for controlling operation of the daemon itself (as opposed to drivers
|
||||
it is running). This can be used to dynamically reconfigure some aspects of
|
||||
the daemon and monitor/control connected clients.
|
||||
|
||||
Notice that the session mode does not have a separate read-only socket. Since
|
||||
the clients must be running as the same user as the daemon itself, there is
|
||||
not any security benefit from attempting to enforce a read-only mode.
|
||||
|
||||
``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
|
||||
such as ``/run/user/$UID``.
|
||||
|
||||
Modular Systemd Integration
|
||||
---------------------------
|
||||
|
||||
When the ``virt${DRIVER}d`` daemon is managed by ``systemd`` a number of
|
||||
desirable features are available, most notably socket activation.
|
||||
|
||||
Libvirt ships a number of unit files for controlling ``virt${DRIVER}d``:
|
||||
|
||||
* ``virt${DRIVER}d.service`` - the main unit file for launching the
|
||||
``virt${DRIVER}d`` daemon in system mode. The command line arguments passed
|
||||
can be configured by editing ``/etc/sysconfig/virt${DRIVER}d``. This is
|
||||
typically only needed to control the use of the auto shutdown timeout value.
|
||||
It is recommended that this service unit be configured to start on boot.
|
||||
This is because various libvirt drivers support autostart of their objects.
|
||||
If it is known that autostart is not required, this unit can be left to start
|
||||
on demand.
|
||||
|
||||
* ``virt${DRIVER}d.socket`` - the unit file corresponding to the main read-write
|
||||
UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock``. This socket is
|
||||
recommended to be started on boot by default.
|
||||
|
||||
* ``virt${DRIVER}d-ro.socket`` - the unit file corresponding to the main
|
||||
read-only UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock-ro``. This
|
||||
socket is recommended to be started on boot by default.
|
||||
|
||||
* ``virt${DRIVER}d-admin.socket`` - the unit file corresponding to the
|
||||
administrative UNIX socket ``/var/run/libvirt/virt${DRIVER}d-admin-sock``.
|
||||
This socket is recommended to be started on boot by default.
|
||||
|
||||
NB, some distros will use ``/etc/default`` instead of ``/etc/sysconfig``.
|
||||
|
||||
The socket unit files are newly introduced in 5.6.0. On newly installed hosts
|
||||
the UNIX socket units should be enabled by default. When upgrading an existing
|
||||
host from a previous version of libvirt, the socket unit files will be masked
|
||||
if ``virt${DRIVER}d`` is currently configured to use the ``--listen`` argument,
|
||||
since the ``--listen`` argument is mutually exclusive with use of socket
|
||||
activation.
|
||||
|
||||
When systemd socket activation is used a number of configuration settings in
|
||||
``virt${DRIVER}d.conf`` are no longer honoured. Instead these settings must be
|
||||
controlled via the system unit files:
|
||||
|
||||
* ``unix_sock_group`` - UNIX socket group owner, controlled via the
|
||||
``SocketGroup`` parameter in the ``virt${DRIVER}d.socket`` and
|
||||
``virt${DRIVER}d-ro.socket`` unit files
|
||||
|
||||
* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virt${DRIVER}d-ro.socket`` unit file
|
||||
|
||||
* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
|
||||
the ``SocketMode`` parameter in the ``virt${DRIVER}d.socket`` unit file
|
||||
|
||||
* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virt${DRIVER}d-admin.socket`` unit file
|
||||
|
||||
* ``unix_sock_dir`` - directory in which all UNIX sockets are created
|
||||
independently controlled via the ``ListenStream`` parameter in any of the
|
||||
``virt${DRIVER}d.socket``, ``virt${DRIVER}d-ro.socket`` and
|
||||
``virt${DRIVER}d-admin.socket`` unit files.
|
||||
|
||||
Systemd releases prior to version 227 lacked support for passing the activation
|
||||
socket unit names into the service. When using these old versions, the
|
||||
``unix_sock_dir`` setting in ``virt${DRIVER}d.conf`` must be changed in
|
||||
lock-step with the equivalent setting in the unit files to ensure that
|
||||
``virt${DRIVER}d`` can identify the sockets.
|
||||
|
||||
|
||||
Switching to modular daemons
|
||||
----------------------------
|
||||
|
||||
If a host is currently set to use the monolithic ``libvirtd`` daemon and needs
|
||||
to be migrated to the monolithic daemons a number of services need to be
|
||||
changed. The steps below outline the process on hosts using the systemd init
|
||||
service.
|
||||
|
||||
While it is technically possible to do this while virtual machines are running,
|
||||
it is recommended that virtual machines be stopped or live migrated to a new
|
||||
host first.
|
||||
|
||||
#. Stop the current monolithic daemon and its socket units
|
||||
|
||||
::
|
||||
|
||||
$ systemctl stop libvirtd.service
|
||||
$ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket
|
||||
|
||||
#. Disable future start of the monolithic daemon
|
||||
|
||||
::
|
||||
|
||||
$ systemctl disable libvirtd.service
|
||||
$ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket
|
||||
|
||||
For stronger protection it is valid to use ``mask`` instead of ``disable``
|
||||
too.
|
||||
|
||||
#. Enable the new daemons for the particular virtualizationd driver desired,
|
||||
and any of the secondary drivers to accompany it. The following example
|
||||
enables the QEMU driver and all the secondary drivers:
|
||||
|
||||
::
|
||||
|
||||
$ for drv in qemu interface network nodedev nwfilter secret storage
|
||||
do
|
||||
systemctl unmask virt${drv}d.service
|
||||
systemctl unmask virt${drv}d{,-ro,-admin}.socket
|
||||
systemctl enable virt${drv}d.service
|
||||
systemctl enable virt${drv}d{,-ro,-admin}.socket
|
||||
done
|
||||
|
||||
#. Start the sockets for the same set of daemons. There is no need to start the
|
||||
services as they will get started when the first socket connection is
|
||||
established
|
||||
|
||||
::
|
||||
|
||||
$ for drv in qemu network nodedev nwfilter secret storage
|
||||
do
|
||||
systemctl start virt${drv}d{,-ro,-admin}.socket
|
||||
done
|
||||
|
||||
#. If connections from remote hosts need to be supported the proxy daemon
|
||||
must be enabled and started
|
||||
|
||||
::
|
||||
|
||||
$ systemctl unmask virtproxyd.service
|
||||
$ systemctl unmask virtproxyd{,-ro,-admin}.socket
|
||||
$ systemctl enable virtproxyd.service
|
||||
$ systemctl enable virtproxyd{,-ro,-admin}.socket
|
||||
$ systemctl start virtproxyd{,-ro,-admin}.socket
|
||||
|
||||
The UNIX sockets allow for remote access using SSH tunneling. If ``libvirtd``
|
||||
had TCP or TLS sockets configured, those should be started too
|
||||
|
||||
::
|
||||
|
||||
$ systemctl unmask virtproxyd-tls.socket
|
||||
$ systemctl enable virtproxyd-tls.socket
|
||||
$ systemctl start virtproxyd-tls.socket
|
||||
|
||||
|
||||
Proxy daemon
|
||||
============
|
||||
|
||||
The monolithic daemon is known as ``libvirtd`` and has historically been the
|
||||
default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf``
|
||||
|
||||
|
||||
Proxy sockets
|
||||
-------------
|
||||
|
||||
When running in system mode, ``virtproxyd`` exposes three UNIX domain sockets,
|
||||
and optionally, one or two TCP sockets. These sockets are identical to those
|
||||
provided by the traditional ``libvirtd`` so refer to earlier documentation in
|
||||
this page.
|
||||
|
||||
When running in session mode, ``virtproxyd`` exposes two UNIX domain sockets,
|
||||
which are again identical to those provided by ``libvirtd``.
|
||||
|
||||
Proxy Systemd Integration
|
||||
-------------------------
|
||||
|
||||
When the ``virtproxyd`` daemon is managed by ``systemd`` a number of desirable
|
||||
features are available, most notably socket activation.
|
||||
|
||||
Libvirt ships a number of unit files for controlling ``virtproxyd``:
|
||||
|
||||
* ``virtproxyd.service`` - the main unit file for launching the ``virtproxyd``
|
||||
daemon in system mode. The command line arguments passed can be configured by
|
||||
editing ``/etc/sysconfig/virtproxyd``. This is typically only needed to
|
||||
control the use of the auto shutdown timeout value.
|
||||
|
||||
* ``virtproxyd.socket`` - the unit file corresponding to the main read-write
|
||||
UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to
|
||||
be started on boot by default.
|
||||
|
||||
* ``virtproxyd-ro.socket`` - the unit file corresponding to the main read-only
|
||||
UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended
|
||||
to be started on boot by default.
|
||||
|
||||
* ``virtproxyd-admin.socket`` - the unit file corresponding to the
|
||||
administrative UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This
|
||||
socket is recommended to be started on boot by default.
|
||||
|
||||
* ``virtproxyd-tcp.socket`` - the unit file corresponding to the TCP 16509 port
|
||||
for non-TLS remote access. This socket should not be configured to start on
|
||||
boot until the administrator has configured a suitable authentication
|
||||
mechanism.
|
||||
|
||||
* ``virtproxyd-tls.socket`` - the unit file corresponding to the TCP 16509 port
|
||||
for TLS remote access. This socket should not be configured to start on boot
|
||||
until the administrator has deployed x509 certificates and optionally
|
||||
configured a suitable authentication mechanism.
|
||||
|
||||
NB, some distros will use ``/etc/default`` instead of ``/etc/sysconfig``.
|
||||
|
||||
The socket unit files are newly introduced in 5.6.0. On newly installed hosts
|
||||
the UNIX socket units should be enabled by default. When upgrading an existing
|
||||
host from a previous version of libvirt, the socket unit files will be masked
|
||||
if ``virtproxyd`` is currently configured to use the ``--listen`` argument, since
|
||||
the ``--listen`` argument is mutually exclusive with use of socket activation.
|
||||
|
||||
When systemd socket activation is used a number of configuration settings in
|
||||
``virtproxyd.conf`` are no longer honoured. Instead these settings must be
|
||||
controlled via the system unit files. Refer to the earlier documentation on
|
||||
the ``libvirtd`` service socket configuration for further information.
|
||||
|
||||
|
||||
Logging daemon
|
||||
==============
|
||||
|
||||
The ``virtlogd`` daemon provides a service for managing log files associated
|
||||
with QEMU virtual machines. The QEMU process is given one or more pipes, the
|
||||
other end of which are owned by the ``virtlogd`` daemon. It will then write
|
||||
data on those pipes to log files, while enforcing a maximum file size and
|
||||
performing log rollover at the size limit.
|
||||
|
||||
Since the daemon holds open anoymous pipe file descriptors, it must never be
|
||||
stopped while any QEMU virtual machines are running. To enable software updates
|
||||
to be applied, the daemon is capable of re-executing itself while keeping all
|
||||
file descriptors open. This can be triggered by sending the daemon ``SIGUSR1``
|
||||
|
||||
Logging Sockets
|
||||
---------------
|
||||
|
||||
When running in system mode, ``virtlogd`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``/var/run/libvirt/virtlogd-sock`` - the primary socket for accessing
|
||||
libvirt APIs, with full read-write privileges. Access to the socket is
|
||||
restricted to the root user.
|
||||
|
||||
* ``/var/run/libvirt/virtlogd-admin-sock`` - the administrative socket for
|
||||
controlling operation of the daemon itself (as opposed to drivers it is
|
||||
running). This can be used to dynamically reconfigure some aspects of the
|
||||
daemon and monitor/control connected clients.
|
||||
|
||||
NB, some distros will use ``/run`` instead of ``/var/run``.
|
||||
|
||||
When running in session mode, ``virtlogd`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-sock`` - the primary socket for
|
||||
accessing libvirt APIs, with full read-write privileges. Access to the
|
||||
socket is restricted to the unprivileged user running the daemon.
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-admin-sock`` - the administrative
|
||||
socket for controlling operation of the daemon itself (as opposed to drivers
|
||||
it is running). This can be used to dynamically reconfigure some aspects of
|
||||
the daemon and monitor/control connected clients.
|
||||
|
||||
``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
|
||||
such as ``/run/user/$UID``.
|
||||
|
||||
Logging Systemd Integration
|
||||
---------------------------
|
||||
|
||||
When the ``virtlogd`` daemon is managed by ``systemd`` a number of desirable
|
||||
features are available, most notably socket activation.
|
||||
|
||||
Libvirt ships a number of unit files for controlling ``virtlogd``:
|
||||
|
||||
* ``virtlogd.service`` - the main unit file for launching the
|
||||
``virtlogd`` daemon in system mode. The command line arguments passed
|
||||
can be configured by editing ``/etc/sysconfig/virtlogd``. This is
|
||||
typically only needed to control the use of the auto shutdown timeout value.
|
||||
|
||||
* ``virtlogd.socket`` - the unit file corresponding to the main read-write
|
||||
UNIX socket ``/var/run/libvirt/virtlogd-sock``. This socket is recommended
|
||||
to be started on boot by default.
|
||||
|
||||
* ``virtlogd-admin.socket`` - the unit file corresponding to the administrative
|
||||
UNIX socket ``/var/run/libvirt/virtlogd-admin-sock``. This socket is
|
||||
recommended to be started on boot by default.
|
||||
|
||||
NB, some distros will use ``/etc/default`` instead of ``/etc/sysconfig``.
|
||||
|
||||
When systemd socket activation is used a number of configuration settings in
|
||||
``virtlogd.conf`` are no longer honoured. Instead these settings must be
|
||||
controlled via the system unit files:
|
||||
|
||||
* ``unix_sock_group`` - UNIX socket group owner, controlled via the
|
||||
``SocketGroup`` parameter in the ``virtlogd.socket`` and
|
||||
``virtlogd-ro.socket`` unit files
|
||||
|
||||
* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virtlogd-ro.socket`` unit file
|
||||
|
||||
* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
|
||||
the ``SocketMode`` parameter in the ``virtlogd.socket`` unit file
|
||||
|
||||
* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virtlogd-admin.socket`` unit file
|
||||
|
||||
* ``unix_sock_dir`` - directory in which all UNIX sockets are created
|
||||
independently controlled via the ``ListenStream`` parameter in any of the
|
||||
``virtlogd.socket`` and ``virtlogd-admin.socket`` unit files.
|
||||
|
||||
Systemd releases prior to version 227 lacked support for passing the activation
|
||||
socket unit names into the service. When using these old versions, the
|
||||
``unix_sock_dir`` setting in ``virtlogd.conf`` must be changed in
|
||||
lock-step with the equivalent setting in the unit files to ensure that
|
||||
``virtlogd`` can identify the sockets.
|
||||
|
||||
Locking daemon
|
||||
==============
|
||||
|
||||
The ``virtlockd`` daemon provides a service for holding locks against file
|
||||
images and devices serving as backing storage for virtual disks. The locks
|
||||
will be held for as long as there is a QEMU process running with the disk
|
||||
open.
|
||||
|
||||
To ensure continuity of locking, the daemon holds open anoymous file
|
||||
descriptors, it must never be stopped while any QEMU virtual machines are
|
||||
running. To enable software updates to be applied, the daemon is capable of
|
||||
re-executing itself while keeping all file descriptors open. This can be
|
||||
triggered by sending the daemon ``SIGUSR1``
|
||||
|
||||
Locking Sockets
|
||||
---------------
|
||||
|
||||
When running in system mode, ``virtlockd`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``/var/run/libvirt/virtlockd-sock`` - the primary socket for accessing
|
||||
libvirt APIs, with full read-write privileges. Access to the socket is
|
||||
restricted to the root user.
|
||||
|
||||
* ``/var/run/libvirt/virtlockd-admin-sock`` - the administrative socket for
|
||||
controlling operation of the daemon itself (as opposed to drivers it is
|
||||
running). This can be used to dynamically reconfigure some aspects of the
|
||||
daemon and monitor/control connected clients.
|
||||
|
||||
NB, some distros will use ``/run`` instead of ``/var/run``.
|
||||
|
||||
When running in session mode, ``virtlockd`` exposes two UNIX domain sockets:
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-sock`` - the primary socket for
|
||||
accessing libvirt APIs, with full read-write privileges. Access to the
|
||||
socket is restricted to the unprivileged user running the daemon.
|
||||
|
||||
* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-admin-sock`` - the administrative
|
||||
socket for controlling operation of the daemon itself (as opposed to drivers
|
||||
it is running). This can be used to dynamically reconfigure some aspects of
|
||||
the daemon and monitor/control connected clients.
|
||||
|
||||
``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
|
||||
such as ``/run/user/$UID``.
|
||||
|
||||
Locking Systemd Integration
|
||||
---------------------------
|
||||
|
||||
When the ``virtlockd`` daemon is managed by ``systemd`` a number of desirable
|
||||
features are available, most notably socket activation.
|
||||
|
||||
Libvirt ships a number of unit files for controlling ``virtlockd``:
|
||||
|
||||
* ``virtlockd.service`` - the main unit file for launching the
|
||||
``virtlockd`` daemon in system mode. The command line arguments passed
|
||||
can be configured by editing ``/etc/sysconfig/virtlockd``. This is
|
||||
typically only needed to control the use of the auto shutdown timeout value.
|
||||
|
||||
* ``virtlockd.socket`` - the unit file corresponding to the main read-write
|
||||
UNIX socket ``/var/run/libvirt/virtlockd-sock``. This socket is recommended
|
||||
to be started on boot by default.
|
||||
|
||||
* ``virtlockd-admin.socket`` - the unit file corresponding to the administrative
|
||||
UNIX socket ``/var/run/libvirt/virtlockd-admin-sock``. This socket is
|
||||
recommended to be started on boot by default.
|
||||
|
||||
NB, some distros will use ``/etc/default`` instead of ``/etc/sysconfig``.
|
||||
|
||||
When systemd socket activation is used a number of configuration settings in
|
||||
``virtlockd.conf`` are no longer honoured. Instead these settings must be
|
||||
controlled via the system unit files:
|
||||
|
||||
* ``unix_sock_group`` - UNIX socket group owner, controlled via the
|
||||
``SocketGroup`` parameter in the ``virtlockd.socket`` and
|
||||
``virtlockd-ro.socket`` unit files
|
||||
|
||||
* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virtlockd-ro.socket`` unit file
|
||||
|
||||
* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
|
||||
the ``SocketMode`` parameter in the ``virtlockd.socket`` unit file
|
||||
|
||||
* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
|
||||
``SocketMode`` parameter in the ``virtlockd-admin.socket`` unit file
|
||||
|
||||
* ``unix_sock_dir`` - directory in which all UNIX sockets are created
|
||||
independently controlled via the ``ListenStream`` parameter in any of the
|
||||
``virtlockd.socket`` and ``virtlockd-admin.socket`` unit files.
|
||||
|
||||
Systemd releases prior to version 227 lacked support for passing the activation
|
||||
socket unit names into the service. When using these old versions, the
|
||||
``unix_sock_dir`` setting in ``virtlockd.conf`` must be changed in
|
||||
lock-step with the equivalent setting in the unit files to ensure that
|
||||
``virtlockd`` can identify the sockets.
|
||||
@@ -1,102 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>D-Bus API bindings</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="description">Description</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt-dbus wraps libvirt API to provide a high-level object-oriented
|
||||
API better suited for dbus-based applications.
|
||||
</p>
|
||||
|
||||
<h2><a id="git">GIT source repository</a></h2>
|
||||
<p>
|
||||
The D-Bus bindings source code is maintained in a
|
||||
<a href="https://git-scm.com/">git</a> repository available on
|
||||
<a href="https://libvirt.org/git/">libvirt.org</a>:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git clone https://libvirt.org/git/libvirt-dbus.git
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
They can also be browsed online:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<a href="https://libvirt.org/git/?p=libvirt-dbus.git">https://libvirt.org/git/?p=libvirt-dbus.git</a>
|
||||
</pre>
|
||||
|
||||
<h2><a id="usage">Usage</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt-dbus exports libvirt API using D-Bus objects with methods and
|
||||
properties described by interfaces. Currently only local connection
|
||||
to libvirt is exported and the list of supported drivers depends
|
||||
on the type of the bus connection (session or system).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The name of the libvirt-dbus service is <code>org.libvirt</code>.
|
||||
libvirt-dbus distributes an interface XML descriptions which can be
|
||||
usually found at <code>/usr/share/dbus-1/interfaces/</code>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By default unprivileged user has access only to the session D-Bus
|
||||
connection. In order to allow specific user "foo" to access the system
|
||||
D-Bus connection you need to create a file
|
||||
<code>/etc/dbus-1/system.d/org.libvirt.conf</code> that contains:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<?xml version="1.0"?>
|
||||
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
|
||||
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
|
||||
|
||||
<busconfig>
|
||||
|
||||
<policy user="foo">
|
||||
<allow send_destination="org.libvirt"/>
|
||||
</policy>
|
||||
|
||||
</busconfig>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To get a list of supported drivers for the specific bus connection
|
||||
you can run these commands (not all drivers may be available on
|
||||
the host):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
gdbus introspect --xml --session --dest org.libvirt --object-path /org/libvirt
|
||||
gdbus introspect --xml --system --dest org.libvirt --object-path /org/libvirt
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Every object is introspectable so you can get a list of available
|
||||
interfaces with methods, signals and properties running this command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
gdbus introspect --xml --system --dest org.libvirt --object-path /org/libvirt/QEMU
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To get a list of domains for specific connection driver you can run
|
||||
this command:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
gdbus call --system --dest org.libvirt --object-path /org/libvirt/QEMU \
|
||||
--method org.libvirt.Connect.ListDomains 0
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,13 +0,0 @@
|
||||
=================
|
||||
Developer tooling
|
||||
=================
|
||||
|
||||
libvirt includes support for some useful development tools right
|
||||
in its source repository, meaning users will be able to take
|
||||
advantage of them without little or no configuration. Examples
|
||||
include:
|
||||
|
||||
- `color_coded <https://github.com/jeaye/color_coded>`__, a vim
|
||||
plugin for libclang-powered semantic syntax highlighting;
|
||||
- `YouCompleteMe <http://valloric.github.io/YouCompleteMe/>`__, a
|
||||
vim plugin for libclang-powered semantic code completion.
|
||||
@@ -1,42 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>libvirt Application Development Guides</h1>
|
||||
|
||||
<p>
|
||||
The libvirt API is accessible from a number of programming languages.
|
||||
At this time, there are application development guides available
|
||||
which cover the C API and the Python API. Of the two, the Python guide
|
||||
is currently the more comprehensive document.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="https://libvirt.org/docs/libvirt-appdev-guide/en-US/html/">Application Development Guide (C language) HTML</a></li>
|
||||
<li><a href="https://libvirt.org/docs/libvirt-appdev-guide/en-US/pdf/">Application Development Guide (C language) PDF</a></li>
|
||||
<li><a href="https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/html/">Application Development Guide (Python language) HTML</a></li>
|
||||
<li><a href="https://libvirt.org/docs/libvirt-appdev-guide-python/en-US/pdf/">Application Development Guide (Python language) PDF</a></li>
|
||||
</ul>
|
||||
|
||||
<h2>Contributing content</h2>
|
||||
|
||||
<p>
|
||||
These guides are written in DocBook and published with the
|
||||
publican tool, which is also used for Fedora and Red Hat
|
||||
documentation. The original content is provided in GIT and
|
||||
any contributions to the guide are welcome.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# C language
|
||||
$ git clone <a href="https://libvirt.org/git/?p=libvirt-appdev-guide.git">https://libvirt.org/git/libvirt-appdev-guide.git</a>
|
||||
|
||||
# Python language
|
||||
$ git clone <a href="https://libvirt.org/git/?p=libvirt-appdev-guide-python.git">https://libvirt.org/git/libvirt-appdev-guide-python.git</a>
|
||||
|
||||
# Publican Style/Theme
|
||||
$ git clone <a href="https://libvirt.org/git/?p=libvirt-publican.git">https://libvirt.org/git/libvirt-publican.git</a>
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,187 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body class="docs">
|
||||
<div class="panel">
|
||||
<h2>Deployment / operation</h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="apps.html">Applications</a></dt>
|
||||
<dd>Applications known to use libvirt</dd>
|
||||
|
||||
<dt><a href="manpages/index.html">Manual pages</a></dt>
|
||||
<dd>Manual pages for libvirt tools / daemons</dd>
|
||||
|
||||
<dt><a href="windows.html">Windows</a></dt>
|
||||
<dd>Downloads for Windows</dd>
|
||||
|
||||
<dt><a href="migration.html">Migration</a></dt>
|
||||
<dd>Migrating guests between machines</dd>
|
||||
|
||||
<dt><a href="daemons.html">Daemons</a></dt>
|
||||
<dd>Overview of the daemons provided by libvirt</dd>
|
||||
|
||||
<dt><a href="remote.html">Remote access</a></dt>
|
||||
<dd>Enable remote access over TCP</dd>
|
||||
|
||||
<dt><a href="tlscerts.html">TLS certs</a></dt>
|
||||
<dd>Generate and deploy x509 certificates for TLS</dd>
|
||||
|
||||
<dt><a href="auth.html">Authentication</a></dt>
|
||||
<dd>Configure authentication for the libvirt daemon</dd>
|
||||
|
||||
<dt><a href="acl.html">Access control</a></dt>
|
||||
<dd>Configure access control libvirt APIs with <a href="aclpolkit.html">polkit</a></dd>
|
||||
|
||||
<dt><a href="logging.html">Logging</a></dt>
|
||||
<dd>The library and the daemon logging support</dd>
|
||||
|
||||
<dt><a href="auditlog.html">Audit log</a></dt>
|
||||
<dd>Audit trail logs for host operations</dd>
|
||||
|
||||
<dt><a href="firewall.html">Firewall</a></dt>
|
||||
<dd>Firewall and network filter configuration</dd>
|
||||
|
||||
<dt><a href="hooks.html">Hooks</a></dt>
|
||||
<dd>Hooks for system specific management</dd>
|
||||
|
||||
<dt><a href="nss.html">NSS module</a></dt>
|
||||
<dd>Enable domain host name translation to IP addresses</dd>
|
||||
|
||||
<dt><a href="http://wiki.libvirt.org/page/FAQ">FAQ</a></dt>
|
||||
<dd>Frequently asked questions</dd>
|
||||
</dl>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="panel">
|
||||
<h2>Application development</h2>
|
||||
<dl>
|
||||
<dt><a href="html/index.html">API reference</a></dt>
|
||||
<dd>Reference manual for the C public API, split in
|
||||
<a href="html/libvirt-libvirt-common.html">common</a>,
|
||||
<a href="html/libvirt-libvirt-domain.html">domain</a>,
|
||||
<a href="html/libvirt-libvirt-domain-checkpoint.html">domain checkpoint</a>,
|
||||
<a href="html/libvirt-libvirt-domain-snapshot.html">domain snapshot</a>,
|
||||
<a href="html/libvirt-virterror.html">error</a>,
|
||||
<a href="html/libvirt-libvirt-event.html">event</a>,
|
||||
<a href="html/libvirt-libvirt-host.html">host</a>,
|
||||
<a href="html/libvirt-libvirt-interface.html">interface</a>,
|
||||
<a href="html/libvirt-libvirt-network.html">network</a>,
|
||||
<a href="html/libvirt-libvirt-nodedev.html">node device</a>,
|
||||
<a href="html/libvirt-libvirt-nwfilter.html">network filter</a>,
|
||||
<a href="html/libvirt-libvirt-secret.html">secret</a>,
|
||||
<a href="html/libvirt-libvirt-storage.html">storage</a>,
|
||||
<a href="html/libvirt-libvirt-stream.html">stream</a>
|
||||
and
|
||||
<a href="html/index-admin.html">admin</a>,
|
||||
<a href="html/index-qemu.html">QEMU</a>,
|
||||
<a href="html/index-lxc.html">LXC</a> libs
|
||||
</dd>
|
||||
|
||||
<dt><a href="bindings.html">Language bindings and API modules</a></dt>
|
||||
<dd>Bindings of the libvirt API for
|
||||
<a href="csharp.html">c#</a>,
|
||||
<a href="https://godoc.org/github.com/libvirt/libvirt-go">go</a>,
|
||||
<a href="java.html">java</a>,
|
||||
<a href="https://libvirt.org/ocaml/">ocaml</a>,
|
||||
<a href="http://search.cpan.org/dist/Sys-Virt/">perl</a>,
|
||||
<a href="python.html">python</a>,
|
||||
<a href="php.html">php</a>,
|
||||
<a href="https://libvirt.org/ruby/">ruby</a>
|
||||
and integration API modules for
|
||||
<a href="dbus.html">D-Bus</a></dd>
|
||||
|
||||
|
||||
<dt><a href="format.html">XML schemas</a></dt>
|
||||
<dd>Description of the XML schemas for
|
||||
<a href="formatdomain.html">domains</a>,
|
||||
<a href="formatnetwork.html">networks</a>,
|
||||
<a href="formatnetworkport.html">network ports</a>,
|
||||
<a href="formatnwfilter.html">network filtering</a>,
|
||||
<a href="formatstorage.html">storage</a>,
|
||||
<a href="formatstorageencryption.html">storage encryption</a>,
|
||||
<a href="formatcaps.html">capabilities</a>,
|
||||
<a href="formatdomaincaps.html">domain capabilities</a>,
|
||||
<a href="formatstoragecaps.html">storage pool capabilities</a>,
|
||||
<a href="formatnode.html">node devices</a>,
|
||||
<a href="formatsecret.html">secrets</a>,
|
||||
<a href="formatsnapshot.html">snapshots</a>,
|
||||
<a href="formatcheckpoint.html">checkpoints</a>,
|
||||
<a href="formatbackup.html">backup jobs</a></dd>
|
||||
|
||||
<dt><a href="uri.html">URI format</a></dt>
|
||||
<dd>The URI formats used for connecting to libvirt</dd>
|
||||
|
||||
<dt><a href="cgroups.html">CGroups</a></dt>
|
||||
<dd>Control groups integration</dd>
|
||||
|
||||
<dt><a href="drivers.html">Drivers</a></dt>
|
||||
<dd>Hypervisor specific driver information</dd>
|
||||
|
||||
<dt><a href="support.html">Support guarantees</a></dt>
|
||||
<dd>Details of support status for various interfaces</dd>
|
||||
|
||||
<dt><a href="hvsupport.html">Driver support</a></dt>
|
||||
<dd>matrix of API support per hypervisor per release</dd>
|
||||
|
||||
<dt><a href="kbase.html">Knowledge Base</a></dt>
|
||||
<dd>Task oriented guides to key features</dd>
|
||||
</dl>
|
||||
</div>
|
||||
|
||||
<div class="panel">
|
||||
<h2>Project development</h2>
|
||||
<dl>
|
||||
<dt><a href="hacking.html">Contributor guidelines</a></dt>
|
||||
<dd>General hacking guidelines for contributors</dd>
|
||||
|
||||
<dt><a href="styleguide.html">Docs style guide</a></dt>
|
||||
<dd>Style guidelines for reStructuredText docs</dd>
|
||||
|
||||
<dt><a href="strategy.html">Project strategy</a></dt>
|
||||
<dd>Sets a vision for future direction & technical choices</dd>
|
||||
|
||||
<dt><a href="ci.html">CI Testing</a></dt>
|
||||
<dd>Details of the Continuous Integration testing strategy</dd>
|
||||
|
||||
<dt><a href="bugs.html">Bug reports</a></dt>
|
||||
<dd>How and where to report bugs and request features</dd>
|
||||
|
||||
<dt><a href="compiling.html">Compiling</a></dt>
|
||||
<dd>How to compile libvirt</dd>
|
||||
|
||||
<dt><a href="goals.html">Goals</a></dt>
|
||||
<dd>Terminology and goals of libvirt API</dd>
|
||||
|
||||
<dt><a href="api.html">API concepts</a></dt>
|
||||
<dd>The libvirt API concepts</dd>
|
||||
|
||||
<dt><a href="api_extension.html">API extensions</a></dt>
|
||||
<dd>Adding new public libvirt APIs</dd>
|
||||
|
||||
<dt><a href="internals/eventloop.html">Event loop and worker pool</a></dt>
|
||||
<dd>Libvirt's event loop and worker pool mode</dd>
|
||||
|
||||
<dt><a href="internals/command.html">Spawning commands</a></dt>
|
||||
<dd>Spawning commands from libvirt driver code</dd>
|
||||
|
||||
<dt><a href="internals/rpc.html">RPC protocol & APIs</a></dt>
|
||||
<dd>RPC protocol information and API / dispatch guide</dd>
|
||||
|
||||
<dt><a href="internals/locking.html">Lock managers</a></dt>
|
||||
<dd>Use lock managers to protect disk content</dd>
|
||||
|
||||
<dt><a href="testsuites.html">Functional testing</a></dt>
|
||||
<dd>Testing libvirt with <a href="testtck.html">TCK test suite</a> and
|
||||
<a href="testapi.html">Libvirt-test-API</a></dd>
|
||||
|
||||
<dt><a href="newreposetup.html">New repo setup</a></dt>
|
||||
<dd>Procedure for configuring new git repositories for libvirt</dd>
|
||||
</dl>
|
||||
</div>
|
||||
|
||||
<br class="clear"/>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,605 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Downloads</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a id="releases">Project modules</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt project maintains a number of inter-related modules beyond
|
||||
the core C library/daemon.
|
||||
</p>
|
||||
|
||||
<table class="top_table downloads">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Module</th>
|
||||
<th>Releases</th>
|
||||
<th>GIT Repo</th>
|
||||
<th>Bug Tracker</th>
|
||||
<th>GIT Mirrors</th>
|
||||
<th>Resources</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>libvirt</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt">github</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="html/index.html">api ref</a>
|
||||
<a href="news.html">changes</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th colspan="7">Language bindings</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>C#</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/csharp/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-csharp">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-csharp/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-csharp.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-csharp">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Go</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/libvirt-go">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-go/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-go.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-go">github</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://godoc.org/libvirt.org/libvirt-go">api ref</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Java</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/java/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-java">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-java/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-java.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-java">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>OCaml</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/ocaml/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ocaml">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ocaml/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-ocaml">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Perl (Sys::Virt)</td>
|
||||
<td>
|
||||
<a href="https://metacpan.org/release/Sys-Virt/">cpan</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-perl">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-perl/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-perl.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-perl">github</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://metacpan.org/release/Sys-Virt/">api ref</a>
|
||||
<a href="https://libvirt.org/git/?p=libvirt-perl.git;a=blob;f=Changes;hb=HEAD">changes</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PHP</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/php/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-php">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-php/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-php">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Python</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/python/">libvirt</a>
|
||||
<a href="https://pypi.python.org/pypi/libvirt-python">pypi</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-python">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-python/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-python.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-python">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Ruby</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/ruby/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ruby">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ruby/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-ruby.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-ruby">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Rust</td>
|
||||
<td>
|
||||
<a href="https://crates.io/crates/virt">crates.io</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-rust">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-rust/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-rust.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-rust">github</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://docs.rs/virt">api ref</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th colspan="7">Integration modules</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>GLib / GConfig / GObject</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/glib/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-glib">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-glib/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-glib.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-glib">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Go XML</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/libvirt-go-xml">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-go-xml">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-go-xml/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-go-xml.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-go-xml">github</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://godoc.org/libvirt.org/libvirt-go-xml">api ref</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>D-Bus</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/dbus/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-dbus">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-dbus/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-dbus.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-dbus">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Console Proxy</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/consoleproxy/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-console-proxy">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-console-proxy/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-console-proxy.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-console-proxy">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>CIM provider</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/CIM/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-cim">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-cim/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-cim.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-cim">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>CIM utils</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/CIM/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libcmpiutil">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libcmpiutil/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libcmpiutil.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libcmpiutil">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SNMP</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/snmp/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-snmp">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-snmp/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-snmp.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-snmp">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Application Sandbox</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/sandbox/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-sandbox">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-sandbox/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-sandbox.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-sandbox">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th colspan="7">Testing</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TCK</td>
|
||||
<td>
|
||||
<a href="https://libvirt.org/sources/tck/">libvirt</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-tck">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-tck/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-tck.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-tck">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Test API</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-test-API">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-test-API/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-test-API.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-test-API">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Continuous Integration Config</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ci">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-ci/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-ci.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-ci">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>CIM Test</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/cimtest">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/cimtest/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=cimtest.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/cimtest">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th colspan="7">Documentation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Publican Brand</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-publican">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-publican/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-publican.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-publican">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>App Development Guide</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-appdev-guide">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-appdev-guide/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-appdev-guide.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-appdev-guide">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>App Development Guide Python</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-appdev-guide-python">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-appdev-guide-python/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-appdev-guide-python.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-appdev-guide-python">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>virsh Command Reference</td>
|
||||
<td></td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-virshcmdref">gitlab</a>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://gitlab.com/libvirt/libvirt-virshcmdref/-/issues">issues</a>
|
||||
</td>
|
||||
<td class="gitmirror">
|
||||
<a href="https://libvirt.org/git/?p=libvirt-virshcmdref.git;a=summary">libvirt</a>
|
||||
<a href="https://github.com/libvirt/libvirt-virshcmdref">github</a>
|
||||
</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Primary download site</h2>
|
||||
|
||||
<p>
|
||||
Most modules have releases made available for download on the project
|
||||
site via HTTPS. Some modules are instead made available at alternative
|
||||
locations, for example, the Perl binding is made available only on CPAN.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="https://libvirt.org/sources/">libvirt.org HTTPS server</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="schedule">Primary release schedule</a></h2>
|
||||
|
||||
<p>
|
||||
The core libvirt module follows a time based plan, with releases made
|
||||
once a month on the 1st of each month give or take a few days. The only
|
||||
exception is at the start of the year where there are two 6 weeks gaps
|
||||
(first release in the middle of Jan, then skip the Feb release), giving
|
||||
a total of 11 releases a year. The Python and Perl modules will aim to
|
||||
release at the same time as the core libvirt module. Other modules have
|
||||
independent ad-hoc releases with no fixed time schedule.
|
||||
</p>
|
||||
|
||||
<h2><a id="numbering">Release numbering</a></h2>
|
||||
|
||||
<p>
|
||||
Since libvirt 2.0.0, a time based version numbering rule
|
||||
is applied to the core library releases. As such, the changes
|
||||
in version number have do not have any implications with respect
|
||||
to the scope of features or bugfixes included, the stability of
|
||||
the code, or the API / ABI compatibility (libvirt API / ABI is
|
||||
guaranteed stable forever). The rules applied for changing the
|
||||
libvirt version number are:
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>major</code></dt>
|
||||
<dd>incremented by 1 for the first release of the year (the
|
||||
Jan 15th release)</dd>
|
||||
<dt><code>minor</code></dt>
|
||||
<dd>reset to 0 with every major increment, otherwise incremented by 1
|
||||
for each monthly release from git master</dd>
|
||||
<dt><code>micro</code></dt>
|
||||
<dd>always 0 for releases from git master, incremented by 1
|
||||
for each stable maintenance release</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
Prior to 2.0.0, the major/minor numbers were incremented
|
||||
fairly arbitrarily, and maintenance releases appended a
|
||||
fourth digit. The language bindings will aim to use the
|
||||
same version number as the most recent core library API
|
||||
they support. The other modules have their own distinct
|
||||
release numbering sequence, though they generally aim
|
||||
to follow the above rules for incrementing major/minor/micro
|
||||
digits.
|
||||
</p>
|
||||
|
||||
<h2><a id="maintenance">Maintenance releases</a></h2>
|
||||
<p>
|
||||
In the git repository are several stable maintenance branches
|
||||
for the core library, matching the
|
||||
pattern <code>v<i>major</i>.<i>minor</i>-maint</code>;
|
||||
these branches are forked off the corresponding
|
||||
<code>v<i>major</i>.<i>minor</i>.0</code> formal
|
||||
release, and may have further releases of the
|
||||
form <code>v<i>major</i>.<i>minor</i>.<i>micro</i></code>.
|
||||
These maintenance branches should only contain bug fixes, and no
|
||||
new features, backported from the master branch, and are
|
||||
supported as long as at least one downstream distribution
|
||||
expresses interest in a given branch. These maintenance
|
||||
branches are considered during CVE analysis. In contrast
|
||||
to the primary releases which are made once a month, there
|
||||
is no formal schedule for the maintenance releases, which
|
||||
are made whenever there is a need to make available key
|
||||
bugfixes to downstream consumers. The language bindings
|
||||
and other modules generally do not provide stable branch
|
||||
releases.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For more details about contents of maintenance releases, see
|
||||
<a href="http://wiki.libvirt.org/page/Maintenance_Releases">the
|
||||
wiki page</a>.
|
||||
</p>
|
||||
|
||||
<h2><a id="git">GIT source repository</a></h2>
|
||||
|
||||
<p>
|
||||
All modules maintained by the libvirt project have their primary
|
||||
source available in the <a href="https://libvirt.org/git/">project GIT server</a>.
|
||||
Each module can be cloned anonymously using:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git clone https://libvirt.org/git/[module name].git</pre>
|
||||
|
||||
<p>
|
||||
The <code>git://</code> protocol is also available if desired, but
|
||||
<code>https://</code> is encouraged, since it is more reliable when
|
||||
faced with strict firewalls.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
git clone git://libvirt.org/[module name].git</pre>
|
||||
|
||||
<p>
|
||||
In addition to this primary repository, there are the following read-only git
|
||||
repositories which mirror the master one. Note that we currently do not
|
||||
use the full set of features on these mirrors (e.g. pull requests on
|
||||
GitHub, so please don't use them). All patch review and discussion only
|
||||
occurs on the <a href="contact.html">libvir-list</a> mailing list. Also
|
||||
note that some repositories listed below allow HTTP checkouts too.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<a href="https://github.com/libvirt/">https://github.com/libvirt/</a>
|
||||
<a href="https://gitlab.com/libvirt/libvirt">https://gitlab.com/libvirt/</a></pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,43 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Internal drivers</h1>
|
||||
|
||||
<ul>
|
||||
<li><a href="#hypervisor">Hypervisor drivers</a></li>
|
||||
<li><a href="storage.html">Storage drivers</a></li>
|
||||
<li><a href="drvnodedev.html">Node device driver</a></li>
|
||||
<li><a href="drvsecret.html">Secret driver</a></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The libvirt public API delegates its implementation to one or
|
||||
more internal drivers, depending on the <a href="uri.html">connection URI</a>
|
||||
passed when initializing the library. There is always a hypervisor driver
|
||||
active, and if the libvirt daemon is available there will usually be a
|
||||
network and storage driver active.
|
||||
</p>
|
||||
|
||||
<h2><a id="hypervisor">Hypervisor drivers</a></h2>
|
||||
|
||||
<p>
|
||||
The hypervisor drivers currently supported by libvirt are:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><strong><a href="drvlxc.html">LXC</a></strong> - Linux Containers</li>
|
||||
<li><strong><a href="drvopenvz.html">OpenVZ</a></strong></li>
|
||||
<li><strong><a href="drvqemu.html">QEMU</a></strong></li>
|
||||
<li><strong><a href="drvtest.html">Test</a></strong> - Used for testing</li>
|
||||
<li><strong><a href="drvvbox.html">VirtualBox</a></strong></li>
|
||||
<li><strong><a href="drvesx.html">VMware ESX</a></strong></li>
|
||||
<li><strong><a href="drvvmware.html">VMware Workstation/Player</a></strong></li>
|
||||
<li><strong><a href="drvxen.html">Xen</a></strong></li>
|
||||
<li><strong><a href="drvhyperv.html">Microsoft Hyper-V</a></strong></li>
|
||||
<li><strong><a href="drvvirtuozzo.html">Virtuozzo</a></strong></li>
|
||||
<li><strong><a href="drvbhyve.html">Bhyve</a></strong> - The BSD Hypervisor</li>
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,493 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Bhyve driver</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
Bhyve is a FreeBSD hypervisor. It first appeared in FreeBSD 10.0. However, it's
|
||||
recommended to keep tracking FreeBSD 10-STABLE to make sure all new features
|
||||
of bhyve are supported.
|
||||
|
||||
In order to enable bhyve on your FreeBSD host, you'll need to load the <code>vmm</code>
|
||||
kernel module. Additionally, <code>if_tap</code> and <code>if_bridge</code> modules
|
||||
should be loaded for networking support. Also, <span class="since">since 3.2.0</span> the
|
||||
<code>virt-host-validate(1)</code> supports the bhyve host validation and could be
|
||||
used like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ virt-host-validate bhyve
|
||||
BHYVE: Checking for vmm module : PASS
|
||||
BHYVE: Checking for if_tap module : PASS
|
||||
BHYVE: Checking for if_bridge module : PASS
|
||||
BHYVE: Checking for nmdm module : PASS
|
||||
$
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Additional information on bhyve could be obtained on <a href="http://bhyve.org/">bhyve.org</a>.
|
||||
</p>
|
||||
|
||||
<h2><a id="uri">Connections to the Bhyve driver</a></h2>
|
||||
<p>
|
||||
The libvirt bhyve driver is a single-instance privileged driver. Some sample
|
||||
connection URIs are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bhyve:///system (local access)
|
||||
bhyve+unix:///system (local access)
|
||||
bhyve+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a id="exconfig">Example guest domain XML configurations</a></h2>
|
||||
|
||||
<h3>Example config</h3>
|
||||
<p>
|
||||
The bhyve driver in libvirt is in its early stage and under active development. So it supports
|
||||
only limited number of features bhyve provides.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note: in older libvirt versions, only a single network device and a single
|
||||
disk device were supported per-domain. However,
|
||||
<span class="since">since 1.2.6</span> the libvirt bhyve driver supports
|
||||
up to 31 PCI devices.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note: the Bhyve driver in libvirt will boot whichever device is first. If you
|
||||
want to install from CD, put the CD device first. If not, put the root HDD
|
||||
first.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note: Only the SATA bus is supported. Only <code>cdrom</code>- and
|
||||
<code>disk</code>-type disks are supported.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
<name>bhyve</name>
|
||||
<uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid>
|
||||
<memory>219136</memory>
|
||||
<currentMemory>219136</currentMemory>
|
||||
<vcpu>1</vcpu>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
</os>
|
||||
<features>
|
||||
<apic/>
|
||||
<acpi/>
|
||||
</features>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<disk type='file'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/bhyve_freebsd.img'/>
|
||||
<target dev='hda' bus='sata'/>
|
||||
</disk>
|
||||
<disk type='file' device='cdrom'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/cdrom.iso'/>
|
||||
<target dev='hdc' bus='sata'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<model type='virtio'/>
|
||||
<source bridge="virbr0"/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>(The <disk> 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 <bootloader>.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
<name>linux_guest</name>
|
||||
<uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid>
|
||||
<memory>131072</memory>
|
||||
<currentMemory>131072</currentMemory>
|
||||
<vcpu>1</vcpu>
|
||||
<bootloader>/usr/local/sbin/grub-bhyve</bootloader>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
</os>
|
||||
<features>
|
||||
<apic/>
|
||||
<acpi/>
|
||||
</features>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/guest_hdd.img'/>
|
||||
<target dev='hda' bus='sata'/>
|
||||
</disk>
|
||||
<disk type='file' device='cdrom'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/cdrom.iso'/>
|
||||
<target dev='hdc' bus='sata'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<model type='virtio'/>
|
||||
<source bridge="virbr0"/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h3>Example config (Linux UEFI guest, VNC, tablet)</h3>
|
||||
|
||||
<p>This is an example to boot into Fedora 25 installation:</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
<name>fedora_uefi_vnc_tablet</name>
|
||||
<memory unit='G'>4</memory>
|
||||
<vcpu>2</vcpu>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<b><loader readonly="yes" type="pflash">/usr/local/share/uefi-firmware/BHYVE_UEFI.fd</loader></b>
|
||||
</os>
|
||||
<features>
|
||||
<apic/>
|
||||
<acpi/>
|
||||
</features>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<disk type='file' device='cdrom'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/Fedora-Workstation-Live-x86_64-25-1.3.iso'/>
|
||||
<target dev='hdc' bus='sata'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<disk type='file' device='disk'>
|
||||
<driver name='file' type='raw'/>
|
||||
<source file='/path/to/linux_uefi.img'/>
|
||||
<target dev='hda' bus='sata'/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<model type='virtio'/>
|
||||
<source bridge="virbr0"/>
|
||||
</interface>
|
||||
<serial type="nmdm">
|
||||
<source master="/dev/nmdm0A" slave="/dev/nmdm0B"/>
|
||||
</serial>
|
||||
<b><graphics type='vnc' port='5904'>
|
||||
<listen type='address' address='127.0.0.1'/>
|
||||
</graphics>
|
||||
<controller type='usb' model='nec-xhci'/>
|
||||
<input type='tablet' bus='usb'/></b>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>Please refer to the <a href="#uefi">UEFI</a> section for a more detailed explanation.</p>
|
||||
|
||||
<h2><a id="usage">Guest usage / management</a></h2>
|
||||
|
||||
<h3><a id="console">Connecting to a guest console</a></h3>
|
||||
|
||||
<p>
|
||||
Guest console connection is supported through the <code>nmdm</code> device. It could be enabled by adding
|
||||
the following to the domain XML (<span class="since">Since 1.2.4</span>):
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
<serial type="nmdm">
|
||||
<source master="/dev/nmdm0A" slave="/dev/nmdm0B"/>
|
||||
</serial>
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
|
||||
<p>Make sure to load the <code>nmdm</code> kernel module if you plan to use that.</p>
|
||||
|
||||
<p>
|
||||
Then <code>virsh console</code> command can be used to connect to the text console
|
||||
of a guest.</p>
|
||||
|
||||
<p><b>NB:</b> Some versions of bhyve have a bug that prevents guests from booting
|
||||
until the console is opened by a client. This bug was fixed in FreeBSD
|
||||
<a href="http://svnweb.freebsd.org/changeset/base/262884">r262884</a>. If
|
||||
an older version is used, one either has to open a console manually with <code>virsh console</code>
|
||||
to let a guest boot or start a guest using:</p>
|
||||
|
||||
<pre>start --console domname</pre>
|
||||
|
||||
<p><b>NB:</b> A bootloader configured to require user interaction will prevent
|
||||
the domain from starting (and thus <code>virsh console</code> or <code>start
|
||||
--console</code> from functioning) until the user interacts with it manually on
|
||||
the VM host. Because users typically do not have access to the VM host,
|
||||
interactive bootloaders are unsupported by libvirt. <em>However,</em> if you happen to
|
||||
run into this scenario and also happen to have access to the Bhyve host
|
||||
machine, you may select a boot option and allow the domain to finish starting
|
||||
by using an alternative terminal client on the VM host to connect to the
|
||||
domain-configured null modem device. One example (assuming
|
||||
<code>/dev/nmdm0B</code> is configured as the slave end of the domain serial
|
||||
device) is:</p>
|
||||
|
||||
<pre>cu -l /dev/nmdm0B</pre>
|
||||
|
||||
<h3><a id="xmltonative">Converting from domain XML to Bhyve args</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> command can preview the actual
|
||||
<code>bhyve</code> commands that will be executed for a given domain.
|
||||
It outputs two lines, the first line is a <code>bhyveload</code> command and
|
||||
the second is a <code>bhyve</code> command.
|
||||
</p>
|
||||
|
||||
<p>Please note that the <code>virsh domxml-to-native</code> doesn't do any
|
||||
real actions other than printing the command, for example, it doesn't try to
|
||||
find a proper TAP interface and create it, like what is done when starting
|
||||
a domain; and always returns <code>tap0</code> for the network interface. So
|
||||
if you're going to run these commands manually, most likely you might want to
|
||||
tweak them.</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c "bhyve:///system" domxml-to-native --format bhyve-argv --xml /path/to/bhyve.xml
|
||||
/usr/sbin/bhyveload -m 214 -d /home/user/vm1.img vm1
|
||||
/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1
|
||||
</pre>
|
||||
|
||||
<h3><a id="zfsvolume">Using ZFS volumes</a></h3>
|
||||
|
||||
<p>It's possible to use ZFS volumes as disk devices <span class="since">since 1.2.8</span>.
|
||||
An example of domain XML device entry for that will look like:</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
<disk type='volume' device='disk'>
|
||||
<source pool='zfspool' volume='vol1'/>
|
||||
<target dev='vdb' bus='virtio'/>
|
||||
</disk>
|
||||
...</pre>
|
||||
|
||||
<p>Please refer to the <a href="storage.html">Storage documentation</a> for more details on storage
|
||||
management.</p>
|
||||
|
||||
<h3><a id="grubbhyve">Using grub2-bhyve or Alternative Bootloaders</a></h3>
|
||||
|
||||
<p>It's possible to boot non-FreeBSD guests by specifying an explicit
|
||||
bootloader, e.g. <code>grub-bhyve(1)</code>. Arguments to the bootloader may be
|
||||
specified as well. If the bootloader is <code>grub-bhyve</code> and arguments
|
||||
are omitted, libvirt will try and infer boot ordering from user-supplied
|
||||
<boot order='N'> 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>
|
||||
...
|
||||
<bootloader>/usr/local/sbin/grub-bhyve</bootloader>
|
||||
<bootloader_args>...</bootloader_args>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>Caveat: <code>bootloader_args</code> does not support any quoting.
|
||||
Filenames, etc, must not have spaces or they will be tokenized incorrectly.</p>
|
||||
|
||||
<h3><a id="uefi">Using UEFI bootrom, VNC, and USB tablet</a></h3>
|
||||
|
||||
<p><span class="since">Since 3.2.0</span>, in addition to <a href="#grubbhyve">grub-bhyve</a>,
|
||||
non-FreeBSD guests could be also booted using an UEFI boot ROM, provided both guest OS and
|
||||
installed <code>bhyve(1)</code> version support UEFI. To use that, <code>loader</code>
|
||||
should be specified in the <code>os</code> section:</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
...
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<loader readonly="yes" type="pflash">/usr/local/share/uefi-firmware/BHYVE_UEFI.fd</loader>
|
||||
</os>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>This uses the UEFI firmware provided by
|
||||
the <a href="https://www.freshports.org/sysutils/bhyve-firmware/">sysutils/bhyve-firmware</a>
|
||||
FreeBSD port.</p>
|
||||
|
||||
<p>VNC and the tablet input device could be configured this way:</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
<devices>
|
||||
...
|
||||
<graphics type='vnc' port='5904'>
|
||||
<listen type='address' address='127.0.0.1'/>
|
||||
</graphics>
|
||||
<controller type='usb' model='nec-xhci'/>
|
||||
<input type='tablet' bus='usb'/>
|
||||
</devices>
|
||||
...
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>This way, VNC will be accessible on <code>127.0.0.1:5904</code>.</p>
|
||||
|
||||
<p>Please note that the tablet device requires to have a USB controller
|
||||
of the <code>nec-xhci</code> model. Currently, only a single controller of this
|
||||
type and a single tablet are supported per domain.</p>
|
||||
|
||||
<p><span class="since">Since 3.5.0</span>, it's possible to configure how the video device is exposed
|
||||
to the guest using the <code>vgaconf</code> attribute:</p>
|
||||
|
||||
<pre>
|
||||
<domain type='bhyve'>
|
||||
<devices>
|
||||
...
|
||||
<graphics type='vnc' port='5904'>
|
||||
<listen type='address' address='127.0.0.1'/>
|
||||
</graphics>
|
||||
<video>
|
||||
<driver vgaconf='on'/>
|
||||
<model type='gop' heads='1' primary='yes'/>
|
||||
</video>
|
||||
...
|
||||
</devices>
|
||||
...
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>If not specified, bhyve's default mode for <code>vgaconf</code>
|
||||
will be used. Please refer to the
|
||||
<a href="https://www.freebsd.org/cgi/man.cgi?query=bhyve&sektion=8&manpath=FreeBSD+12-current">bhyve(8)</a>
|
||||
manual page and the <a href="https://wiki.freebsd.org/bhyve">bhyve wiki</a> for more details on using
|
||||
the <code>vgaconf</code> option.</p>
|
||||
|
||||
<p><span class="since">Since 3.7.0</span>, it's possible to use <code>autoport</code>
|
||||
to let libvirt allocate VNC port automatically (instead of explicitly specifying
|
||||
it with the <code>port</code> attribute):</p>
|
||||
|
||||
<pre>
|
||||
<graphics type='vnc' autoport='yes'>
|
||||
</pre>
|
||||
|
||||
<h3><a id="clockconfig">Clock configuration</a></h3>
|
||||
|
||||
<p>Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in
|
||||
<a href="http://svnweb.freebsd.org/changeset/base/284894">r284894</a> for <i>10-STABLE</i> and
|
||||
in <a href="http://svnweb.freebsd.org/changeset/base/279225">r279225</a> for <i>-CURRENT</i>.
|
||||
It's possible to use this in libvirt <span class="since">since 1.2.18</span>, just place the
|
||||
following to domain XML:</p>
|
||||
|
||||
<pre>
|
||||
<domain type="bhyve">
|
||||
...
|
||||
<clock offset='utc'/>
|
||||
...
|
||||
</domain>
|
||||
</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>
|
||||
<domain type="bhyve">
|
||||
...
|
||||
<clock offset='localtime'/>
|
||||
...
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h3><a id="e1000">e1000 NIC</a></h3>
|
||||
|
||||
<p>As of <a href="https://svnweb.freebsd.org/changeset/base/302504">r302504</a> bhyve
|
||||
supports Intel e1000 network adapter emulation. It's supported in libvirt
|
||||
<span class="since">since 3.1.0</span> and could be used as follows:</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
<interface type='bridge'>
|
||||
<source bridge='virbr0'/>
|
||||
<model type='<b>e1000</b>'/>
|
||||
</interface>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<h3><a id="wired">Wiring guest memory</a></h3>
|
||||
|
||||
<p><span class="since">Since 4.4.0</span>, it's possible to specify that guest memory should
|
||||
be wired and cannot be swapped out as follows:</p>
|
||||
<pre>
|
||||
<domain type="bhyve">
|
||||
...
|
||||
<memoryBacking>
|
||||
<locked/>
|
||||
</memoryBacking>
|
||||
...
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h3><a id="cputopology">CPU topology</a></h3>
|
||||
|
||||
<p><span class="since">Since 4.5.0</span>, it's possible to specify guest CPU topology, if bhyve
|
||||
supports that. Support for specifying guest CPU topology was added to bhyve in
|
||||
<a href="http://svnweb.freebsd.org/changeset/base/332298">r332298</a> for <i>-CURRENT</i>.
|
||||
Example:</p>
|
||||
<pre>
|
||||
<domain type="bhyve">
|
||||
...
|
||||
<cpu>
|
||||
<topology sockets='1' cores='2' threads='1'/>
|
||||
</cpu>
|
||||
...
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h3><a id="bhyvecommand">Pass-through of arbitrary bhyve commands</a></h3>
|
||||
|
||||
<p><span class="since">Since 5.1.0</span>, it's possible to pass additional command-line
|
||||
arguments to the bhyve process when starting the domain using the
|
||||
<code><bhyve:commandline></code> element under <code>domain</code>.
|
||||
To supply an argument, use the element <code><bhyve:arg></code> with
|
||||
the attribute <code>value</code> set to additional argument to be added.
|
||||
The arg element may be repeated multiple times. To use this XML addition, it is necessary
|
||||
to issue an XML namespace request (the special <code>xmlns:<i>name</i></code> attribute)
|
||||
that pulls in <code>http://libvirt.org/schemas/domain/bhyve/1.0</code>;
|
||||
typically, the namespace is given the name of <code>bhyve</code>.
|
||||
</p>
|
||||
<p>Example:</p>
|
||||
<pre>
|
||||
<domain type="bhyve" xmlns:bhyve="http://libvirt.org/schemas/domain/bhyve/1.0">
|
||||
...
|
||||
<bhyve:commandline>
|
||||
<bhyve:arg value='-somebhyvearg'/>
|
||||
</bhyve:commandline>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>Note that these extensions are for testing and development purposes only.
|
||||
They are <b>unsupported</b>, using them may result in inconsistent state,
|
||||
and upgrading either bhyve or libvirtd maybe break behavior of a domain that
|
||||
was relying on a specific commands pass-through.</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,824 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>VMware ESX hypervisor driver</h1>
|
||||
<ul id="toc"></ul>
|
||||
<p>
|
||||
The libvirt VMware ESX driver can manage VMware ESX/ESXi 3.5/4.x/5.x and
|
||||
VMware GSX 2.0, also called VMware Server 2.0, and possibly later
|
||||
versions. <span class="since">Since 0.8.3</span> the driver can also
|
||||
connect to a VMware vCenter 2.5/4.x/5.x (VPX).
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.vmware.com/">VMware ESX and GSX</a>
|
||||
hypervisors
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
<p>
|
||||
None. Any out-of-the-box installation of VPX/ESX(i)/GSX should work. No
|
||||
preparations are required on the server side, no libvirtd must be
|
||||
installed on the ESX server. The driver uses version 2.5 of the remote,
|
||||
SOAP based
|
||||
<a href="http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/">
|
||||
VMware Virtual Infrastructure API</a> (VI API) to communicate with the
|
||||
ESX server, like the VMware Virtual Infrastructure Client (VI client)
|
||||
does. Since version 4.0 this API is called
|
||||
<a href="http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/">
|
||||
VMware vSphere API</a>.
|
||||
</p>
|
||||
|
||||
<h2><a id="uri">Connections to the VMware ESX driver</a></h2>
|
||||
<p>
|
||||
Some example remote connection URIs for the driver are:
|
||||
</p>
|
||||
<pre>
|
||||
vpx://example-vcenter.com/dc1/srv1 (VPX over HTTPS, select ESX server 'srv1' in datacenter 'dc1')
|
||||
esx://example-esx.com (ESX over HTTPS)
|
||||
gsx://example-gsx.com (GSX over HTTPS)
|
||||
esx://example-esx.com/?transport=http (ESX over HTTP)
|
||||
esx://example-esx.com/?no_verify=1 (ESX over HTTPS, but doesn't verify the server's SSL certificate)
|
||||
</pre>
|
||||
<p>
|
||||
<strong>Note</strong>: In contrast to other drivers, the ESX driver is
|
||||
a client-side-only driver. It connects to the ESX server using HTTP(S).
|
||||
Therefore, the <a href="remote.html">remote transport mechanism</a>
|
||||
provided by the remote driver and libvirtd will not work, and you
|
||||
cannot use URIs like <code>esx+ssh://example.com</code>.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="uriformat">URI Format</a></h3>
|
||||
<p>
|
||||
URIs have this general form (<code>[...]</code> marks an optional part).
|
||||
</p>
|
||||
<pre>
|
||||
type://[username@]hostname[:port]/[[folder/...]datacenter/[folder/...][cluster/]server][?extraparameters]
|
||||
</pre>
|
||||
<p>
|
||||
The <code>type://</code> is either <code>esx://</code> or
|
||||
<code>gsx://</code> or <code>vpx://</code> <span class="since">since 0.8.3</span>.
|
||||
The driver selects the default port depending on the <code>type://</code>.
|
||||
For <code>esx://</code> and <code>vpx://</code> the default HTTPS port
|
||||
is 443, for <code>gsx://</code> it is 8333.
|
||||
If the port parameter is given, it overrides the default port.
|
||||
</p>
|
||||
<p>
|
||||
A <code>vpx://</code> connection is currently restricted to a single
|
||||
ESX server. This might be relaxed in the future. The path part of the
|
||||
URI is used to specify the datacenter and the ESX server in it. If the
|
||||
ESX server is part of a cluster then the cluster has to be specified too.
|
||||
</p>
|
||||
<p>
|
||||
An example: ESX server <code>example-esx.com</code> is managed by
|
||||
vCenter <code>example-vcenter.com</code> and part of cluster
|
||||
<code>cluster1</code>. This cluster is part of datacenter <code>dc1</code>.
|
||||
</p>
|
||||
<pre>
|
||||
vpx://example-vcenter.com/dc1/cluster1/example-esx.com
|
||||
</pre>
|
||||
<p>
|
||||
Datacenters and clusters can be organized in folders, those have to be
|
||||
specified as well. The driver can handle folders
|
||||
<span class="since">since 0.9.7</span>.
|
||||
</p>
|
||||
<pre>
|
||||
vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
|
||||
</pre>
|
||||
|
||||
|
||||
<h4><a id="extraparams">Extra parameters</a></h4>
|
||||
<p>
|
||||
Extra parameters can be added to a URI as part of the query string
|
||||
(the part following <code>?</code>). A single parameter is formed by a
|
||||
<code>name=value</code> pair. Multiple parameters are separated by
|
||||
<code>&</code>.
|
||||
</p>
|
||||
<pre>
|
||||
?<span style="color: #E50000">no_verify=1</span>&<span style="color: #00B200">auto_answer=1</span>&<span style="color: #0000E5">proxy=socks://example-proxy.com:23456</span>
|
||||
</pre>
|
||||
<p>
|
||||
The driver understands the extra parameters shown below.
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Values</th>
|
||||
<th>Meaning</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>transport</code>
|
||||
</td>
|
||||
<td>
|
||||
<code>http</code> or <code>https</code>
|
||||
</td>
|
||||
<td>
|
||||
Overrides the default HTTPS transport. For <code>esx://</code>
|
||||
and <code>vpx://</code> the default HTTP port is 80, for
|
||||
<code>gsx://</code> it is 8222.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>vcenter</code>
|
||||
</td>
|
||||
<td>
|
||||
Hostname of a VMware vCenter or <code>*</code>
|
||||
</td>
|
||||
<td>
|
||||
In order to perform a migration the driver needs to know the
|
||||
VMware vCenter for the ESX server. If set to <code>*</code>,
|
||||
the driver connects to the vCenter known to the ESX server.
|
||||
This parameter in useful when connecting to an ESX server only.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>no_verify</code>
|
||||
</td>
|
||||
<td>
|
||||
<code>0</code> or <code>1</code>
|
||||
</td>
|
||||
<td>
|
||||
If set to 1, this disables libcurl client checks of the server's
|
||||
SSL certificate. The default value is 0. See the
|
||||
<a href="#certificates">Certificates for HTTPS</a> section for
|
||||
details.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>auto_answer</code>
|
||||
</td>
|
||||
<td>
|
||||
<code>0</code> or <code>1</code>
|
||||
</td>
|
||||
<td>
|
||||
If set to 1, the driver answers all
|
||||
<a href="#questions">questions</a> with the default answer.
|
||||
If set to 0, questions are reported as errors. The default
|
||||
value is 0. <span class="since">Since 0.7.5</span>.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>proxy</code>
|
||||
</td>
|
||||
<td>
|
||||
<code>[type://]hostname[:port]</code>
|
||||
</td>
|
||||
<td>
|
||||
Allows to specify a proxy for HTTP and HTTPS communication.
|
||||
<span class="since">Since 0.8.2</span>.
|
||||
The optional <code>type</code> part may be one of:
|
||||
<code>http</code>, <code>socks</code>, <code>socks4</code>,
|
||||
<code>socks4a</code> or <code>socks5</code>. The default is
|
||||
<code>http</code> and <code>socks</code> is synonymous for
|
||||
<code>socks5</code>. The optional <code>port</code> allows to
|
||||
override the default port 1080.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
<h3><a id="auth">Authentication</a></h3>
|
||||
<p>
|
||||
In order to perform any useful operation the driver needs to log into
|
||||
the ESX server. Therefore, only <code>virConnectOpenAuth</code> can be
|
||||
used to connect to an ESX server, <code>virConnectOpen</code> and
|
||||
<code>virConnectOpenReadOnly</code> don't work.
|
||||
To log into an ESX server or vCenter the driver will request
|
||||
credentials using the callback passed to the
|
||||
<code>virConnectOpenAuth</code> function. The driver passes the
|
||||
hostname as challenge parameter to the callback. This enables the
|
||||
callback to distinguish between requests for ESX server and vCenter.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note</strong>: During the ongoing driver development, testing
|
||||
is done using an unrestricted <code>root</code> account. Problems may
|
||||
occur if you use a restricted account. Detailed testing with restricted
|
||||
accounts has not been done yet.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="certificates">Certificates for HTTPS</a></h3>
|
||||
<p>
|
||||
By default the ESX driver uses HTTPS to communicate with an ESX server.
|
||||
Proper HTTPS communication requires correctly configured SSL
|
||||
certificates. This certificates are different from the ones libvirt
|
||||
uses for <a href="remote.html">secure communication over TLS</a> to a
|
||||
libvirtd one a remote server.
|
||||
</p>
|
||||
<p>
|
||||
By default the driver tries to verify the server's SSL certificate
|
||||
using the CA certificate pool installed on your client computer. With
|
||||
an out-of-the-box installed ESX server this won't work, because a newly
|
||||
installed ESX server uses auto-generated self-signed certificates.
|
||||
Those are singed by a CA certificate that is typically not known to your
|
||||
client computer and libvirt will report an error like this one:
|
||||
</p>
|
||||
<pre>
|
||||
error: internal error curl_easy_perform() returned an error: Peer certificate cannot be authenticated with known CA certificates (60)
|
||||
</pre>
|
||||
<p>
|
||||
Where are two ways to solve this problem:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Use the <code>no_verify=1</code> <a href="#extraparams">extra parameter</a>
|
||||
to disable server certificate verification.
|
||||
</li>
|
||||
<li>
|
||||
Generate new SSL certificates signed by a CA known to your client
|
||||
computer and replace the original ones on your ESX server. See the
|
||||
section <i>Replace a Default Certificate with a CA-Signed Certificate</i>
|
||||
in the <a href="http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esx_server_config.pdf">ESX Configuration Guide</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a id="connproblems">Connection problems</a></h3>
|
||||
<p>
|
||||
There are also other causes for connection problems than the
|
||||
<a href="#certificates">HTTPS certificate</a> related ones.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
As stated before the ESX driver doesn't need the
|
||||
<a href="remote.html">remote transport mechanism</a>
|
||||
provided by the remote driver and libvirtd, nor does the ESX driver
|
||||
support it. Therefore, using an URI including a transport in the
|
||||
scheme won't work. Only <a href="#uriformat">URIs as described</a>
|
||||
are supported by the ESX driver. Here's a collection of possible
|
||||
error messages:
|
||||
<pre>
|
||||
$ virsh -c esx+tcp://example.com/
|
||||
error: unable to connect to libvirtd at 'example.com': Connection refused
|
||||
</pre>
|
||||
<pre>
|
||||
$ virsh -c esx+tls://example.com/
|
||||
error: Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
|
||||
</pre>
|
||||
<pre>
|
||||
$ virsh -c esx+ssh://example.com/
|
||||
error: cannot recv data: ssh: connect to host example.com port 22: Connection refused
|
||||
</pre>
|
||||
<pre>
|
||||
$ virsh -c esx+ssh://example.com/
|
||||
error: cannot recv data: Resource temporarily unavailable
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
<span class="since">Since 0.7.0</span> libvirt contains the ESX
|
||||
driver. Earlier versions of libvirt will report a misleading error
|
||||
about missing certificates when you try to connect to an ESX server.
|
||||
<pre>
|
||||
$ virsh -c esx://example.com/
|
||||
error: Cannot access CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
|
||||
</pre>
|
||||
<p>
|
||||
Don't let this error message confuse you. Setting up certificates
|
||||
as described on the <a href="remote.html#Remote_certificates">remote transport mechanism</a> page
|
||||
does not help, as this is not a certificate related problem.
|
||||
</p>
|
||||
<p>
|
||||
To fix this problem you need to update your libvirt to 0.7.0 or newer.
|
||||
You may also see this error when you use a libvirt version that
|
||||
contains the ESX driver but you or your distro disabled the ESX
|
||||
driver during compilation. <span class="since">Since 0.8.3</span>
|
||||
the error message has been improved in this case:
|
||||
</p>
|
||||
<pre>
|
||||
$ virsh -c esx://example.com/
|
||||
error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</pre>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a id="questions">Questions blocking tasks</a></h2>
|
||||
<p>
|
||||
Some methods of the VI API start tasks, for example
|
||||
<code>PowerOnVM_Task()</code>. Such tasks may be blocked by questions
|
||||
if the ESX server detects an issue with the domain that requires user
|
||||
interaction. The ESX driver cannot prompt the user to answer a
|
||||
question, libvirt doesn't have an API for something like this.
|
||||
</p>
|
||||
<p>
|
||||
The VI API provides the <code>AnswerVM()</code> method to
|
||||
programmatically answer a questions. So the driver has two options
|
||||
how to handle such a situation: either answer the questions with the
|
||||
default answer or report the question as an error and cancel the
|
||||
blocked task if possible. The
|
||||
<a href="#uriformat"><code>auto_answer</code></a> query parameter
|
||||
controls the answering behavior.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="xmlspecial">Specialties in the domain XML config</a></h2>
|
||||
<p>
|
||||
There are several specialties in the domain XML config for ESX domains.
|
||||
</p>
|
||||
|
||||
<h3><a id="restrictions">Restrictions</a></h3>
|
||||
<p>
|
||||
There are some restrictions for some values of the domain XML config.
|
||||
The driver will complain if this restrictions are violated.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Memory size has to be a multiple of 4096
|
||||
</li>
|
||||
<li>
|
||||
Number of virtual CPU has to be 1 or a multiple of 2.
|
||||
<span class="since">Since 4.10.0</span> any number of vCPUs is
|
||||
supported.
|
||||
</li>
|
||||
<li>
|
||||
Valid MAC address prefixes are <code>00:0c:29</code> and
|
||||
<code>00:50:56</code>. <span class="since">Since 0.7.6</span>
|
||||
arbitrary <a href="#macaddresses">MAC addresses</a> are supported.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a id="datastore">Datastore references</a></h3>
|
||||
<p>
|
||||
Storage is managed in datastores. VMware uses a special path format to
|
||||
reference files in a datastore. Basically, the datastore name is put
|
||||
into squared braces in front of the path.
|
||||
</p>
|
||||
<pre>
|
||||
[datastore] directory/filename
|
||||
</pre>
|
||||
<p>
|
||||
To define a new domain the driver converts the domain XML into a
|
||||
VMware VMX file and uploads it to a datastore known to the ESX server.
|
||||
Because multiple datastores may be known to an ESX server the driver
|
||||
needs to decide to which datastore the VMX file should be uploaded.
|
||||
The driver deduces this information from the path of the source of the
|
||||
first file-based harddisk listed in the domain XML.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="macaddresses">MAC addresses</a></h3>
|
||||
<p>
|
||||
VMware has registered two MAC address prefixes for domains:
|
||||
<code>00:0c:29</code> and <code>00:50:56</code>. These prefixes are
|
||||
split into ranges for different purposes.
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr>
|
||||
<th>Range</th>
|
||||
<th>Purpose</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>00:0c:29:00:00:00</code> - <code>00:0c:29:ff:ff:ff</code>
|
||||
</td>
|
||||
<td>
|
||||
An ESX server autogenerates MAC addresses from this range if
|
||||
the VMX file doesn't contain a MAC address when trying to start
|
||||
a domain.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>00:50:56:00:00:00</code> - <code>00:50:56:3f:ff:ff</code>
|
||||
</td>
|
||||
<td>
|
||||
MAC addresses from this range can by manually assigned by the
|
||||
user in the VI client.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>00:50:56:80:00:00</code> - <code>00:50:56:bf:ff:ff</code>
|
||||
</td>
|
||||
<td>
|
||||
A VI client autogenerates MAC addresses from this range for
|
||||
newly defined domains.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
The VMX files generated by the ESX driver always contain a MAC address,
|
||||
because libvirt generates a random one if an interface element in the
|
||||
domain XML file lacks a MAC address.
|
||||
<span class="since">Since 0.7.6</span> the ESX driver sets the prefix
|
||||
for generated MAC addresses to <code>00:0c:29</code>. Before 0.7.6
|
||||
the <code>00:50:56</code> prefix was used. Sometimes this resulted in
|
||||
the generation of out-of-range MAC address that were rejected by the
|
||||
ESX server.
|
||||
</p>
|
||||
<p>
|
||||
Also <span class="since">since 0.7.6</span> every MAC address outside
|
||||
this ranges can be used. For such MAC addresses the ESX server-side
|
||||
check is disabled in the VMX file to stop the ESX server from rejecting
|
||||
out-of-predefined-range MAC addresses.
|
||||
</p>
|
||||
<pre>
|
||||
ethernet0.checkMACAddress = "false"
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a id="hardware">Available hardware</a></h3>
|
||||
<p>
|
||||
VMware ESX supports different models of SCSI controllers and network
|
||||
cards.
|
||||
</p>
|
||||
|
||||
<h4>SCSI controller models</h4>
|
||||
<dl>
|
||||
<dt><code>auto</code></dt>
|
||||
<dd>
|
||||
This isn't an actual controller model. If specified the ESX driver
|
||||
tries to detect the SCSI controller model referenced in the
|
||||
<code>.vmdk</code> file and use it. Autodetection fails when a
|
||||
SCSI controller has multiple disks attached and the SCSI controller
|
||||
models referenced in the <code>.vmdk</code> files are inconsistent.
|
||||
<span class="since">Since 0.8.3</span>
|
||||
</dd>
|
||||
<dt><code>buslogic</code></dt>
|
||||
<dd>
|
||||
BusLogic SCSI controller for older guests.
|
||||
</dd>
|
||||
<dt><code>lsilogic</code></dt>
|
||||
<dd>
|
||||
LSI Logic SCSI controller for recent guests.
|
||||
</dd>
|
||||
<dt><code>lsisas1068</code></dt>
|
||||
<dd>
|
||||
LSI Logic SAS 1068 controller. <span class="since">Since 0.8.0</span>
|
||||
</dd>
|
||||
<dt><code>vmpvscsi</code></dt>
|
||||
<dd>
|
||||
Special VMware Paravirtual SCSI controller, requires VMware tools inside
|
||||
the guest. See <a href="http://kb.vmware.com/kb/1010398">VMware KB1010398</a>
|
||||
for details. <span class="since">Since 0.8.3</span>
|
||||
</dd>
|
||||
</dl>
|
||||
<p>
|
||||
Here a domain XML snippet:
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<disk type='file' device='disk'>
|
||||
<source file='[local-storage] Fedora11/Fedora11.vmdk'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
<address type='drive' controller='0' bus='0' unit='0'/>
|
||||
</disk>
|
||||
<controller type='scsi' index='0' model='<strong>lsilogic</strong>'/>
|
||||
...
|
||||
</pre>
|
||||
<p>
|
||||
The controller element is supported <span class="since">since 0.8.2</span>.
|
||||
Prior to this <code><driver name='lsilogic'/></code> was abused to
|
||||
specify the SCSI controller model. This attribute usage is deprecated now.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<disk type='file' device='disk'>
|
||||
<driver name='<strong>lsilogic</strong>'/>
|
||||
<source file='[local-storage] Fedora11/Fedora11.vmdk'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
</disk>
|
||||
...
|
||||
</pre>
|
||||
|
||||
|
||||
<h4>Network card models</h4>
|
||||
<dl>
|
||||
<dt><code>vlance</code></dt>
|
||||
<dd>
|
||||
AMD PCnet32 network card for older guests.
|
||||
</dd>
|
||||
<dt><code>vmxnet</code>, <code>vmxnet2</code>, <code>vmxnet3</code></dt>
|
||||
<dd>
|
||||
Special VMware VMXnet network card, requires VMware tools inside
|
||||
the guest. See <a href="http://kb.vmware.com/kb/1001805">VMware KB1001805</a>
|
||||
for details.
|
||||
</dd>
|
||||
<dt><code>e1000</code></dt>
|
||||
<dd>
|
||||
Intel E1000 network card for recent guests.
|
||||
</dd>
|
||||
</dl>
|
||||
<p>
|
||||
Here a domain XML snippet:
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<interface type='bridge'>
|
||||
<mac address='00:50:56:25:48:c7'/>
|
||||
<source bridge='VM Network'/>
|
||||
<model type='<strong>e1000</strong>'/>
|
||||
</interface>
|
||||
...
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a id="importexport">Import and export of domain XML configs</a></h2>
|
||||
<p>
|
||||
The ESX driver currently supports a native config format known as
|
||||
<code>vmware-vmx</code> to handle VMware VMX configs.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="xmlimport">Converting from VMware VMX config to domain XML config</a></h3>
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to convert an
|
||||
existing VMware VMX config into a domain XML config that can then be
|
||||
used by libvirt.
|
||||
</p>
|
||||
<pre>
|
||||
$ cat > demo.vmx << EOF
|
||||
#!/usr/bin/vmware
|
||||
config.version = "8"
|
||||
virtualHW.version = "4"
|
||||
floppy0.present = "false"
|
||||
nvram = "Fedora11.nvram"
|
||||
deploymentPlatform = "windows"
|
||||
virtualHW.productCompatibility = "hosted"
|
||||
tools.upgrade.policy = "useGlobal"
|
||||
powerType.powerOff = "default"
|
||||
powerType.powerOn = "default"
|
||||
powerType.suspend = "default"
|
||||
powerType.reset = "default"
|
||||
displayName = "Fedora11"
|
||||
extendedConfigFile = "Fedora11.vmxf"
|
||||
scsi0.present = "true"
|
||||
scsi0.sharedBus = "none"
|
||||
scsi0.virtualDev = "lsilogic"
|
||||
memsize = "1024"
|
||||
scsi0:0.present = "true"
|
||||
scsi0:0.fileName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11.vmdk"
|
||||
scsi0:0.deviceType = "scsi-hardDisk"
|
||||
ide0:0.present = "true"
|
||||
ide0:0.clientDevice = "true"
|
||||
ide0:0.deviceType = "cdrom-raw"
|
||||
ide0:0.startConnected = "false"
|
||||
ethernet0.present = "true"
|
||||
ethernet0.networkName = "VM Network"
|
||||
ethernet0.addressType = "vpx"
|
||||
ethernet0.generatedAddress = "00:50:56:91:48:c7"
|
||||
chipset.onlineStandby = "false"
|
||||
guestOSAltName = "Red Hat Enterprise Linux 5 (32-Bit)"
|
||||
guestOS = "rhel5"
|
||||
uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
|
||||
snapshot.action = "keep"
|
||||
sched.cpu.min = "0"
|
||||
sched.cpu.units = "mhz"
|
||||
sched.cpu.shares = "normal"
|
||||
sched.mem.minsize = "0"
|
||||
sched.mem.shares = "normal"
|
||||
toolScripts.afterPowerOn = "true"
|
||||
toolScripts.afterResume = "true"
|
||||
toolScripts.beforeSuspend = "true"
|
||||
toolScripts.beforePowerOff = "true"
|
||||
scsi0:0.redo = ""
|
||||
tools.syncTime = "false"
|
||||
uuid.location = "56 4d b5 06 a2 bd fb eb-ae 86 f7 d8 49 27 d0 c4"
|
||||
sched.cpu.max = "unlimited"
|
||||
sched.swap.derivedName = "/vmfs/volumes/498076b2-02796c1a-ef5b-000ae484a6a3/Fedora11/Fedora11-7de040d8.vswp"
|
||||
tools.remindInstall = "TRUE"
|
||||
EOF
|
||||
|
||||
$ virsh -c esx://example.com domxml-from-native vmware-vmx demo.vmx
|
||||
Enter username for example.com [root]:
|
||||
Enter root password for example.com:
|
||||
<domain type='vmware'>
|
||||
<name>Fedora11</name>
|
||||
<uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
|
||||
<memory>1048576</memory>
|
||||
<currentMemory>1048576</currentMemory>
|
||||
<vcpu>1</vcpu>
|
||||
<os>
|
||||
<type arch='i686'>hvm</type>
|
||||
</os>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='[local-storage] Fedora11/Fedora11.vmdk'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
<address type='drive' controller='0' bus='0' unit='0'/>
|
||||
</disk>
|
||||
<controller type='scsi' index='0' model='lsilogic'/>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:50:56:91:48:c7'/>
|
||||
<source bridge='VM Network'/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a id="xmlexport">Converting from domain XML config to VMware VMX config</a></h3>
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
domain XML config into a VMware VMX config.
|
||||
</p>
|
||||
<pre>
|
||||
$ cat > demo.xml << EOF
|
||||
<domain type='vmware'>
|
||||
<name>Fedora11</name>
|
||||
<uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
|
||||
<memory>1048576</memory>
|
||||
<currentMemory>1048576</currentMemory>
|
||||
<vcpu>1</vcpu>
|
||||
<os>
|
||||
<type arch='x86_64'>hvm</type>
|
||||
</os>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='[local-storage] Fedora11/Fedora11.vmdk'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
<address type='drive' controller='0' bus='0' unit='0'/>
|
||||
</disk>
|
||||
<controller type='scsi' index='0' model='lsilogic'/>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:50:56:25:48:c7'/>
|
||||
<source bridge='VM Network'/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
EOF
|
||||
|
||||
$ virsh -c esx://example.com domxml-to-native vmware-vmx demo.xml
|
||||
Enter username for example.com [root]:
|
||||
Enter root password for example.com:
|
||||
config.version = "8"
|
||||
virtualHW.version = "4"
|
||||
guestOS = "other-64"
|
||||
uuid.bios = "50 11 5e 16 9b dc 49 d7-f1 71 53 c4 d7 f9 17 10"
|
||||
displayName = "Fedora11"
|
||||
memsize = "1024"
|
||||
numvcpus = "1"
|
||||
scsi0.present = "true"
|
||||
scsi0.virtualDev = "lsilogic"
|
||||
scsi0:0.present = "true"
|
||||
scsi0:0.deviceType = "scsi-hardDisk"
|
||||
scsi0:0.fileName = "/vmfs/volumes/local-storage/Fedora11/Fedora11.vmdk"
|
||||
ethernet0.present = "true"
|
||||
ethernet0.networkName = "VM Network"
|
||||
ethernet0.connectionType = "bridged"
|
||||
ethernet0.addressType = "static"
|
||||
ethernet0.address = "00:50:56:25:48:C7"
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a id="xmlconfig">Example domain XML configs</a></h2>
|
||||
|
||||
<h3>Fedora11 on x86_64</h3>
|
||||
<pre>
|
||||
<domain type='vmware'>
|
||||
<name>Fedora11</name>
|
||||
<uuid>50115e16-9bdc-49d7-f171-53c4d7f91710</uuid>
|
||||
<memory>1048576</memory>
|
||||
<currentMemory>1048576</currentMemory>
|
||||
<vcpu>1</vcpu>
|
||||
<os>
|
||||
<type arch='x86_64'>hvm</type>
|
||||
</os>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='[local-storage] Fedora11/Fedora11.vmdk'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
<address type='drive' controller='0' bus='0' unit='0'/>
|
||||
</disk>
|
||||
<controller type='scsi' index='0'/>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:50:56:25:48:c7'/>
|
||||
<source bridge='VM Network'/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a id="migration">Migration</a></h2>
|
||||
<p>
|
||||
A migration cannot be initiated on an ESX server directly, a VMware
|
||||
vCenter is necessary for this. The <code>vcenter</code> query
|
||||
parameter must be set either to the hostname or IP address of the
|
||||
vCenter managing the ESX server or to <code>*</code>. Setting it
|
||||
to <code>*</code> causes the driver to connect to the vCenter known to
|
||||
the ESX server. If the ESX server is not managed by a vCenter an error
|
||||
is reported.
|
||||
</p>
|
||||
<pre>
|
||||
esx://example.com/?vcenter=example-vcenter.com
|
||||
</pre>
|
||||
<p>
|
||||
Here's an example how to migrate the domain <code>Fedora11</code> from
|
||||
ESX server <code>example-src.com</code> to ESX server
|
||||
<code>example-dst.com</code> implicitly involving vCenter
|
||||
<code>example-vcenter.com</code> using <code>virsh</code>.
|
||||
</p>
|
||||
<pre>
|
||||
$ virsh -c esx://example-src.com/?vcenter=* migrate Fedora11 esx://example-dst.com/?vcenter=*
|
||||
Enter username for example-src.com [root]:
|
||||
Enter root password for example-src.com:
|
||||
Enter username for example-vcenter.com [administrator]:
|
||||
Enter administrator password for example-vcenter.com:
|
||||
Enter username for example-dst.com [root]:
|
||||
Enter root password for example-dst.com:
|
||||
Enter username for example-vcenter.com [administrator]:
|
||||
Enter administrator password for example-vcenter.com:
|
||||
</pre>
|
||||
<p>
|
||||
<span class="since">Since 0.8.3</span> you can directly connect to a vCenter.
|
||||
This simplifies migration a bit. Here's the same migration as above but
|
||||
using <code>vpx://</code> connections and assuming both ESX server are in
|
||||
datacenter <code>dc1</code> and aren't part of a cluster.
|
||||
</p>
|
||||
<pre>
|
||||
$ virsh -c vpx://example-vcenter.com/dc1/example-src.com migrate Fedora11 vpx://example-vcenter.com/dc1/example-dst.com
|
||||
Enter username for example-vcenter.com [administrator]:
|
||||
Enter administrator password for example-vcenter.com:
|
||||
Enter username for example-vcenter.com [administrator]:
|
||||
Enter administrator password for example-vcenter.com:
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a id="scheduler">Scheduler configuration</a></h2>
|
||||
<p>
|
||||
The driver exposes the ESX CPU scheduler. The parameters listed below
|
||||
are available to control the scheduler.
|
||||
</p>
|
||||
<dl>
|
||||
<dt><code>reservation</code></dt>
|
||||
<dd>
|
||||
The amount of CPU resource in MHz that is guaranteed to be
|
||||
available to the domain. Valid values are 0 and greater.
|
||||
</dd>
|
||||
<dt><code>limit</code></dt>
|
||||
<dd>
|
||||
The CPU utilization of the domain will be
|
||||
limited to this value in MHz, even if more CPU resources are
|
||||
available. If the limit is set to -1, the CPU utilization of the
|
||||
domain is unlimited. If the limit is not set to -1, it must be
|
||||
greater than or equal to the reservation.
|
||||
</dd>
|
||||
<dt><code>shares</code></dt>
|
||||
<dd>
|
||||
Shares are used to determine relative CPU
|
||||
allocation between domains. In general, a domain with more shares
|
||||
gets proportionally more of the CPU resource. Valid values are 0
|
||||
and greater. The special values -1, -2 and -3 represent the
|
||||
predefined shares level <code>low</code>, <code>normal</code> and
|
||||
<code>high</code>.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h2><a id="tools">VMware tools</a></h2>
|
||||
<p>
|
||||
Some actions require installed VMware tools. If the VMware tools are
|
||||
not installed in the guest and one of the actions below is to be
|
||||
performed the ESX server raises an error and the driver reports it.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<code>virDomainReboot</code>
|
||||
</li>
|
||||
<li>
|
||||
<code>virDomainShutdown</code>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a id="links">Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://www.vmware.com/support/developer/vc-sdk/">
|
||||
VMware vSphere Web Services SDK Documentation
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://www.vmware.com/pdf/esx3_memory.pdf">
|
||||
The Role of Memory in VMware ESX Server 3
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://www.sanbarrow.com/vmx.html">
|
||||
VMware VMX config parameters
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://www.vmware.com/pdf/vsp_4_pvscsi_perf.pdf">
|
||||
VMware ESX 4.0 PVSCSI Storage Performance
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</body></html>
|
||||
@@ -1,115 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Microsoft Hyper-V hypervisor driver</h1>
|
||||
<ul id="toc"></ul>
|
||||
<p>
|
||||
The libvirt Microsoft Hyper-V driver can manage Hyper-V 2008 R2 and newer.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.microsoft.com/hyper-v-server/">Microsoft Hyper-V</a>
|
||||
hypervisor
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a id="uri">Connections to the Microsoft Hyper-V driver</a></h2>
|
||||
<p>
|
||||
Some example remote connection URIs for the driver are:
|
||||
</p>
|
||||
<pre>
|
||||
hyperv://example-hyperv.com (over HTTPS)
|
||||
hyperv://example-hyperv.com/?transport=http (over HTTP)
|
||||
</pre>
|
||||
<p>
|
||||
<strong>Note</strong>: In contrast to other drivers, the Hyper-V driver
|
||||
is a client-side-only driver. It connects to the Hyper-V server using
|
||||
WS-Management over HTTP(S). Therefore, the
|
||||
<a href="remote.html">remote transport mechanism</a> provided by the
|
||||
remote driver and libvirtd will not work, and you cannot use URIs like
|
||||
<code>hyperv+ssh://example.com</code>.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="uriformat">URI Format</a></h3>
|
||||
<p>
|
||||
URIs have this general form (<code>[...]</code> marks an optional part).
|
||||
</p>
|
||||
<pre>
|
||||
hyperv://[username@]hostname[:port]/[?extraparameters]
|
||||
</pre>
|
||||
<p>
|
||||
The default HTTPS ports is 5986. If the port parameter is given, it
|
||||
overrides the default port.
|
||||
</p>
|
||||
|
||||
|
||||
<h4><a id="extraparams">Extra parameters</a></h4>
|
||||
<p>
|
||||
Extra parameters can be added to a URI as part of the query string
|
||||
(the part following <code>?</code>). A single parameter is formed by a
|
||||
<code>name=value</code> pair. Multiple parameters are separated by
|
||||
<code>&</code>.
|
||||
</p>
|
||||
<pre>
|
||||
?transport=http
|
||||
</pre>
|
||||
<p>
|
||||
The driver understands the extra parameters shown below.
|
||||
</p>
|
||||
<table class="top_table">
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Values</th>
|
||||
<th>Meaning</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
<code>transport</code>
|
||||
</td>
|
||||
<td>
|
||||
<code>http</code> or <code>https</code>
|
||||
</td>
|
||||
<td>
|
||||
Overrides the default HTTPS transport. The default HTTP port
|
||||
is 5985.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
<h3><a id="auth">Authentication</a></h3>
|
||||
<p>
|
||||
In order to perform any useful operation the driver needs to log into
|
||||
the Hyper-V server. Therefore, only <code>virConnectOpenAuth</code> can
|
||||
be used to connect to an Hyper-V server, <code>virConnectOpen</code> and
|
||||
<code>virConnectOpenReadOnly</code> don't work.
|
||||
To log into an Hyper-V server the driver will request credentials using
|
||||
the callback passed to the <code>virConnectOpenAuth</code> function.
|
||||
The driver passes the hostname as challenge parameter to the callback.
|
||||
</p>
|
||||
<p>
|
||||
<strong>Note</strong>: Currently only <code>Basic</code> authentication
|
||||
is supported by libvirt. This method is disabled by default on the
|
||||
Hyper-V server and can be enabled via the WinRM commandline tool.
|
||||
</p>
|
||||
<pre>
|
||||
winrm set winrm/config/service/auth @{Basic="true"}
|
||||
</pre>
|
||||
<p>
|
||||
To allow <code>Basic</code> authentication with HTTP transport WinRM
|
||||
needs to allow unencrypted communication. This can be enabled via the
|
||||
WinRM commandline tool. However, this is not the recommended
|
||||
communication mode.
|
||||
</p>
|
||||
<pre>
|
||||
winrm set winrm/config/service @{AllowUnencrypted="true"}
|
||||
</pre>
|
||||
|
||||
|
||||
</body></html>
|
||||
@@ -1,812 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>LXC container driver</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
The libvirt LXC driver manages "Linux Containers". At their simplest, containers
|
||||
can just be thought of as a collection of processes, separated from the main
|
||||
host processes via a set of resource namespaces and constrained via control
|
||||
groups resource tunables. The libvirt LXC driver has no dependency on the LXC
|
||||
userspace tools hosted on sourceforge.net. It directly utilizes the relevant
|
||||
kernel features to build the container environment. This allows for sharing
|
||||
of many libvirt technologies across both the QEMU/KVM and LXC drivers. In
|
||||
particular sVirt for mandatory access control, auditing of operations,
|
||||
integration with control groups and many other features.
|
||||
</p>
|
||||
|
||||
<h2><a id="cgroups">Control groups Requirements</a></h2>
|
||||
|
||||
<p>
|
||||
In order to control the resource usage of processes inside containers, the
|
||||
libvirt LXC driver requires that certain cgroups controllers are mounted on
|
||||
the host OS. The minimum required controllers are 'cpuacct', 'memory' and
|
||||
'devices', while recommended extra controllers are 'cpu', 'freezer' and
|
||||
'blkio'. Libvirt will not mount the cgroups filesystem itself, leaving
|
||||
this up to the init system to take care of. Systemd will do the right thing
|
||||
in this respect, while for other init systems the <code>cgconfig</code>
|
||||
init service will be required. For further information, consult the general
|
||||
libvirt <a href="cgroups.html">cgroups documentation</a>.
|
||||
</p>
|
||||
|
||||
<h2><a id="namespaces">Namespace requirements</a></h2>
|
||||
|
||||
<p>
|
||||
In order to separate processes inside a container from those in the
|
||||
primary "host" OS environment, the libvirt LXC driver requires that
|
||||
certain kernel namespaces are compiled in. Libvirt currently requires
|
||||
the 'mount', 'ipc', 'pid', and 'uts' namespaces to be available. If
|
||||
separate network interfaces are desired, then the 'net' namespace is
|
||||
required. If the guest configuration declares a
|
||||
<a href="formatdomain.html#elementsOSContainer">UID or GID mapping</a>,
|
||||
the 'user' namespace will be enabled to apply these. <strong>A suitably
|
||||
configured UID/GID mapping is a pre-requisite to making containers
|
||||
secure, in the absence of sVirt confinement.</strong>
|
||||
</p>
|
||||
|
||||
<h2><a id="init">Default container setup</a></h2>
|
||||
|
||||
<h3><a id="cliargs">Command line arguments</a></h3>
|
||||
|
||||
<p>
|
||||
When the container "init" process is started, it will typically
|
||||
not be given any command line arguments (eg the equivalent of
|
||||
the bootloader args visible in <code>/proc/cmdline</code>). If
|
||||
any arguments are desired, then must be explicitly set in the
|
||||
container XML configuration via one or more <code>initarg</code>
|
||||
elements. For example, to run <code>systemd --unit emergency.service</code>
|
||||
would use the following XML
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<os>
|
||||
<type arch='x86_64'>exe</type>
|
||||
<init>/bin/systemd</init>
|
||||
<initarg>--unit</initarg>
|
||||
<initarg>emergency.service</initarg>
|
||||
</os>
|
||||
</pre>
|
||||
|
||||
<h3><a id="envvars">Environment variables</a></h3>
|
||||
|
||||
<p>
|
||||
When the container "init" process is started, it will be given several useful
|
||||
environment variables. The following standard environment variables are mandated
|
||||
by <a href="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">systemd container interface</a>
|
||||
to be provided by all container technologies on Linux.
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>container</code></dt>
|
||||
<dd>The fixed string <code>libvirt-lxc</code> to identify libvirt as the creator</dd>
|
||||
<dt><code>container_uuid</code></dt>
|
||||
<dd>The UUID assigned to the container by libvirt</dd>
|
||||
<dt><code>PATH</code></dt>
|
||||
<dd>The fixed string <code>/bin:/usr/bin</code></dd>
|
||||
<dt><code>TERM</code></dt>
|
||||
<dd>The fixed string <code>linux</code></dd>
|
||||
<dt><code>HOME</code></dt>
|
||||
<dd>The fixed string <code>/</code></dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
In addition to the standard variables, the following libvirt specific
|
||||
environment variables are also provided
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><code>LIBVIRT_LXC_NAME</code></dt>
|
||||
<dd>The name assigned to the container by libvirt</dd>
|
||||
<dt><code>LIBVIRT_LXC_UUID</code></dt>
|
||||
<dd>The UUID assigned to the container by libvirt</dd>
|
||||
<dt><code>LIBVIRT_LXC_CMDLINE</code></dt>
|
||||
<dd>The unparsed command line arguments specified in the container configuration.
|
||||
Use of this is discouraged, in favour of passing arguments directly to the
|
||||
container init process via the <code>initarg</code> config element.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a id="fsmounts">Filesystem mounts</a></h3>
|
||||
|
||||
<p>
|
||||
In the absence of any explicit configuration, the container will
|
||||
inherit the host OS filesystem mounts. A number of mount points will
|
||||
be made read only, or re-mounted with new instances to provide
|
||||
container specific data. The following special mounts are setup
|
||||
by libvirt
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>/dev</code> a new "tmpfs" pre-populated with authorized device nodes</li>
|
||||
<li><code>/dev/pts</code> a new private "devpts" instance for console devices</li>
|
||||
<li><code>/sys</code> the host "sysfs" instance remounted read-only</li>
|
||||
<li><code>/proc</code> a new instance of the "proc" filesystem</li>
|
||||
<li><code>/proc/sys</code> the host "/proc/sys" bind-mounted read-only</li>
|
||||
<li><code>/sys/fs/selinux</code> the host "selinux" instance remounted read-only</li>
|
||||
<li><code>/sys/fs/cgroup/NNNN</code> the host cgroups controllers bind-mounted to
|
||||
only expose the sub-tree associated with the container</li>
|
||||
<li><code>/proc/meminfo</code> a FUSE backed file reflecting memory limits of the container</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a id="devnodes">Device nodes</a></h3>
|
||||
|
||||
<p>
|
||||
The container init process will be started with <code>CAP_MKNOD</code>
|
||||
capability removed and blocked from re-acquiring it. As such it will
|
||||
not be able to create any device nodes in <code>/dev</code> or anywhere
|
||||
else in its filesystems. Libvirt itself will take care of pre-populating
|
||||
the <code>/dev</code> filesystem with any devices that the container
|
||||
is authorized to use. The current devices that will be made available
|
||||
to all containers are
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>/dev/zero</code></li>
|
||||
<li><code>/dev/null</code></li>
|
||||
<li><code>/dev/full</code></li>
|
||||
<li><code>/dev/random</code></li>
|
||||
<li><code>/dev/urandom</code></li>
|
||||
<li><code>/dev/stdin</code> symlinked to <code>/proc/self/fd/0</code></li>
|
||||
<li><code>/dev/stdout</code> symlinked to <code>/proc/self/fd/1</code></li>
|
||||
<li><code>/dev/stderr</code> symlinked to <code>/proc/self/fd/2</code></li>
|
||||
<li><code>/dev/fd</code> symlinked to <code>/proc/self/fd</code></li>
|
||||
<li><code>/dev/ptmx</code> symlinked to <code>/dev/pts/ptmx</code></li>
|
||||
<li><code>/dev/console</code> symlinked to <code>/dev/pts/0</code></li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
In addition, for every console defined in the guest configuration,
|
||||
a symlink will be created from <code>/dev/ttyN</code> symlinked to
|
||||
the corresponding <code>/dev/pts/M</code> pseudo TTY device. The
|
||||
first console will be <code>/dev/tty1</code>, with further consoles
|
||||
numbered incrementally from there.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Since /dev/ttyN and /dev/console are linked to the pts devices. The
|
||||
tty device of login program is pts device. The pam module securetty
|
||||
may prevent root user from logging in container. If you want root
|
||||
user to log in container successfully, add the pts device to the file
|
||||
/etc/securetty of container.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Further block or character devices will be made available to containers
|
||||
depending on their configuration.
|
||||
</p>
|
||||
|
||||
<h2><a id="security">Security considerations</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt LXC driver is fairly flexible in how it can be configured,
|
||||
and as such does not enforce a requirement for strict security
|
||||
separation between a container and the host. This allows it to be used
|
||||
in scenarios where only resource control capabilities are important,
|
||||
and resource sharing is desired. Applications wishing to ensure secure
|
||||
isolation between a container and the host must ensure that they are
|
||||
writing a suitable configuration.
|
||||
</p>
|
||||
|
||||
<h3><a id="securenetworking">Network isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any network interfaces,
|
||||
the <code>network</code> namespace will not be activated, and thus
|
||||
the container will see all the host's network interfaces. This will
|
||||
allow apps in the container to bind to/connect from TCP/UDP addresses
|
||||
and ports from the host OS. It also allows applications to access
|
||||
UNIX domain sockets associated with the host OS, which are in the
|
||||
abstract namespace. If access to UNIX domains sockets in the abstract
|
||||
namespace is not wanted, then applications should set the
|
||||
<code><privnet/></code> flag in the
|
||||
<code><features>....</features></code> element.
|
||||
</p>
|
||||
|
||||
<h3><a id="securefs">Filesystem isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any filesystems, then
|
||||
the container will be set up with a root filesystem that matches
|
||||
the host's root filesystem. As noted earlier, only a few locations
|
||||
such as <code>/dev</code>, <code>/proc</code> and <code>/sys</code>
|
||||
will be altered. This means that, in the absence of restrictions
|
||||
from sVirt, a process running as user/group N:M inside the container
|
||||
will be able to access almost exactly the same files as a process
|
||||
running as user/group N:M in the host.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There are multiple options for restricting this. It is possible to
|
||||
simply map the existing root filesystem through to the container in
|
||||
read-only mode. Alternatively a completely separate root filesystem
|
||||
can be configured for the guest. In both cases, further sub-mounts
|
||||
can be applied to customize the content that is made visible. Note
|
||||
that in the absence of sVirt controls, it is still possible for the
|
||||
root user in a container to unmount any sub-mounts applied. The user
|
||||
namespace feature can also be used to restrict access to files based
|
||||
on the UID/GID mappings.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Sharing the host filesystem tree, also allows applications to access
|
||||
UNIX domains sockets associated with the host OS, which are in the
|
||||
filesystem namespaces. It should be noted that a number of init
|
||||
systems including at least <code>systemd</code> and <code>upstart</code>
|
||||
have UNIX domain socket which are used to control their operation.
|
||||
Thus, if the directory/filesystem holding their UNIX domain socket is
|
||||
exposed to the container, it will be possible for a user in the container
|
||||
to invoke operations on the init service in the same way it could if
|
||||
outside the container. This also applies to other applications in the
|
||||
host which use UNIX domain sockets in the filesystem, such as DBus,
|
||||
Libvirtd, and many more. If this is not desired, then applications
|
||||
should either specify the UID/GID mapping in the configuration to
|
||||
enable user namespaces and thus block access to the UNIX domain socket
|
||||
based on permissions, or should ensure the relevant directories have
|
||||
a bind mount to hide them. This is particularly important for the
|
||||
<code>/run</code> or <code>/var/run</code> directories.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="secureusers">User and group isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any ID mapping, then the
|
||||
user and group IDs used inside the container will match those used
|
||||
outside the container. In addition, the capabilities associated with
|
||||
a process in the container will infer the same privileges they would
|
||||
for a process in the host. This has obvious implications for security,
|
||||
since a root user inside the container will be able to access any
|
||||
file owned by root that is visible to the container, and perform more
|
||||
or less any privileged kernel operation. In the absence of additional
|
||||
protection from sVirt, this means that the root user inside a container
|
||||
is effectively as powerful as the root user in the host. There is no
|
||||
security isolation of the root user.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The ID mapping facility was introduced to allow for stricter control
|
||||
over the privileges of users inside the container. It allows apps to
|
||||
define rules such as "user ID 0 in the container maps to user ID 1000
|
||||
in the host". In addition the privileges associated with capabilities
|
||||
are somewhat reduced so that they cannot be used to escape from the
|
||||
container environment. A full description of user namespaces is outside
|
||||
the scope of this document, however LWN has
|
||||
<a href="https://lwn.net/Articles/532593/">a good write-up on the topic</a>.
|
||||
From the libvirt point of view, the key thing to remember is that defining
|
||||
an ID mapping for users and groups in the container XML configuration
|
||||
causes libvirt to activate the user namespace feature.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="activation">Systemd Socket Activation Integration</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt LXC driver provides the ability to pass across pre-opened file
|
||||
descriptors when starting LXC guests. This allows for libvirt LXC to support
|
||||
systemd's <a href="http://0pointer.de/blog/projects/socket-activated-containers.html">socket
|
||||
activation capability</a>, where an incoming client connection
|
||||
in the host OS will trigger the startup of a container, which runs another
|
||||
copy of systemd which gets passed the server socket, and then activates the
|
||||
actual service handler in the container.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Let us assume that you already have a LXC guest created, running
|
||||
a systemd instance as PID 1 inside the container, which has an
|
||||
SSHD service configured. The goal is to automatically activate
|
||||
the container when the first SSH connection is made. The first
|
||||
step is to create a couple of unit files for the host OS systemd
|
||||
instance. The <code>/etc/systemd/system/mycontainer.service</code>
|
||||
unit file specifies how systemd will start the libvirt LXC container
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[Unit]
|
||||
Description=My little container
|
||||
|
||||
[Service]
|
||||
ExecStart=/usr/bin/virsh -c lxc:///system start --pass-fds 3 mycontainer
|
||||
ExecStop=/usr/bin/virsh -c lxc:///system destroy mycontainer
|
||||
Type=oneshot
|
||||
RemainAfterExit=yes
|
||||
KillMode=none
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>--pass-fds 3</code> argument specifies that the file
|
||||
descriptor number 3 that <code>virsh</code> inherits from systemd,
|
||||
is to be passed into the container. Since <code>virsh</code> will
|
||||
exit immediately after starting the container, the <code>RemainAfterExit</code>
|
||||
and <code>KillMode</code> settings must be altered from their defaults.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Next, the <code>/etc/systemd/system/mycontainer.socket</code> unit
|
||||
file is created to get the host systemd to listen on port 23 for
|
||||
TCP connections. When this unit file is activated by the first
|
||||
incoming connection, it will cause the <code>mycontainer.service</code>
|
||||
unit to be activated with the FD corresponding to the listening TCP
|
||||
socket passed in as FD 3.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[Unit]
|
||||
Description=The SSH socket of my little container
|
||||
|
||||
[Socket]
|
||||
ListenStream=23
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Port 23 was picked here so that the container doesn't conflict
|
||||
with the host's SSH which is on the normal port 22. That's it
|
||||
in terms of host side configuration.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Inside the container, the <code>/etc/systemd/system/sshd.socket</code>
|
||||
unit file must be created
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[Unit]
|
||||
Description=SSH Socket for Per-Connection Servers
|
||||
|
||||
[Socket]
|
||||
ListenStream=23
|
||||
Accept=yes
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <code>ListenStream</code> value listed in this unit file, must
|
||||
match the value used in the host file. When systemd in the container
|
||||
receives the pre-opened FD from libvirt during container startup, it
|
||||
looks at the <code>ListenStream</code> values to figure out which
|
||||
FD to give to which service. The actual service to start is defined
|
||||
by a correspondingly named <code>/etc/systemd/system/sshd@.service</code>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
[Unit]
|
||||
Description=SSH Per-Connection Server for %I
|
||||
|
||||
[Service]
|
||||
ExecStart=-/usr/sbin/sshd -i
|
||||
StandardInput=socket
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Finally, make sure this SSH service is set to start on boot of the container,
|
||||
by running the following command inside the container:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# mkdir -p /etc/systemd/system/sockets.target.wants/
|
||||
# ln -s /etc/systemd/system/sshd.socket /etc/systemd/system/sockets.target.wants/
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This example shows how to activate the container based on an incoming
|
||||
SSH connection. If the container was also configured to have an httpd
|
||||
service, it may be desirable to activate it upon either an httpd or a
|
||||
sshd connection attempt. In this case, the <code>mycontainer.socket</code>
|
||||
file in the host would simply list multiple socket ports. Inside the
|
||||
container a separate <code>xxxxx.socket</code> file would need to be
|
||||
created for each service, with a corresponding <code>ListenStream</code>
|
||||
value set.
|
||||
</p>
|
||||
|
||||
<!--
|
||||
<h2>Container configuration</h2>
|
||||
|
||||
<h3>Init process</h3>
|
||||
|
||||
<h3>Console devices</h3>
|
||||
|
||||
<h3>Filesystem devices</h3>
|
||||
|
||||
<h3>Disk devices</h3>
|
||||
|
||||
<h3>Block devices</h3>
|
||||
|
||||
<h3>USB devices</h3>
|
||||
|
||||
<h3>Character devices</h3>
|
||||
|
||||
<h3>Network devices</h3>
|
||||
-->
|
||||
|
||||
<h2>Container security</h2>
|
||||
|
||||
<h3>sVirt SELinux</h3>
|
||||
|
||||
<p>
|
||||
In the absence of the "user" namespace being used, containers cannot
|
||||
be considered secure against exploits of the host OS. The sVirt SELinux
|
||||
driver provides a way to secure containers even when the "user" namespace
|
||||
is not used. The cost is that writing a policy to allow execution of
|
||||
arbitrary OS is not practical. The SELinux sVirt policy is typically
|
||||
tailored to work with a simpler application confinement use case,
|
||||
as provided by the "libvirt-sandbox" project.
|
||||
</p>
|
||||
|
||||
<h3>Auditing</h3>
|
||||
|
||||
<p>
|
||||
The LXC driver is integrated with libvirt's auditing subsystem, which
|
||||
causes audit messages to be logged whenever there is an operation
|
||||
performed against a container which has impact on host resources.
|
||||
So for example, start/stop, device hotplug will all log audit messages
|
||||
providing details about what action occurred and any resources
|
||||
associated with it. There are the following 3 types of audit messages
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li><code>VIRT_MACHINE_ID</code> - details of the SELinux process and
|
||||
image security labels assigned to the container.</li>
|
||||
<li><code>VIRT_CONTROL</code> - details of an action / operation
|
||||
performed against a container. There are the following types of
|
||||
operation
|
||||
<ul>
|
||||
<li><code>op=start</code> - a container has been started. Provides
|
||||
the machine name, uuid and PID of the <code>libvirt_lxc</code>
|
||||
controller process</li>
|
||||
<li><code>op=init</code> - the init PID of the container has been
|
||||
started. Provides the machine name, uuid and PID of the
|
||||
<code>libvirt_lxc</code> controller process and PID of the
|
||||
init process (in the host PID namespace)</li>
|
||||
<li><code>op=stop</code> - a container has been stopped. Provides
|
||||
the machine name, uuid</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><code>VIRT_RESOURCE</code> - details of a host resource
|
||||
associated with a container action.</li>
|
||||
</ul>
|
||||
|
||||
<h3>Device access</h3>
|
||||
|
||||
<p>
|
||||
All containers are launched with the CAP_MKNOD capability cleared
|
||||
and removed from the bounding set. Libvirt will ensure that the
|
||||
/dev filesystem is pre-populated with all devices that a container
|
||||
is allowed to use. In addition, the cgroup "device" controller is
|
||||
configured to block read/write/mknod from all devices except those
|
||||
that a container is authorized to use.
|
||||
</p>
|
||||
|
||||
<h2><a id="exconfig">Example configurations</a></h2>
|
||||
|
||||
<h3>Example config version 1</h3>
|
||||
<p></p>
|
||||
<pre>
|
||||
<domain type='lxc'>
|
||||
<name>vm1</name>
|
||||
<memory>500000</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/bin/sh</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In the <emulator> element, be sure you specify the correct path
|
||||
to libvirt_lxc, if it does not live in /usr/libexec on your system.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The next example assumes there is a private root filesystem
|
||||
(perhaps hand-crafted using busybox, or installed from media,
|
||||
debootstrap, whatever) under /opt/vm-1-root:
|
||||
</p>
|
||||
<p></p>
|
||||
<pre>
|
||||
<domain type='lxc'>
|
||||
<name>vm1</name>
|
||||
<memory>32768</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/init</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<filesystem type='mount'>
|
||||
<source dir='/opt/vm-1-root'/>
|
||||
<target dir='/'/>
|
||||
</filesystem>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h2><a id="capabilities">Altering the available capabilities</a></h2>
|
||||
|
||||
<p>
|
||||
By default the libvirt LXC driver drops some capabilities among which CAP_MKNOD.
|
||||
However <span class="since">since 1.2.6</span> libvirt can be told to keep or
|
||||
drop some capabilities using a domain configuration like the following:
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<features>
|
||||
<capabilities policy='default'>
|
||||
<mknod state='on'/>
|
||||
<sys_chroot state='off'/>
|
||||
</capabilities>
|
||||
</features>
|
||||
...
|
||||
</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>
|
||||
...
|
||||
<features>
|
||||
<capabilities policy='deny'>
|
||||
<mknod state='on'/>
|
||||
</capabilities>
|
||||
</features>
|
||||
...
|
||||
</pre>
|
||||
<p>
|
||||
Note that allowing capabilities that are normally dropped by default can seriously
|
||||
affect the security of the container and the host.
|
||||
</p>
|
||||
|
||||
<h2><a id="share">Inherit namespaces</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt allows you to inherit the namespace from container/process just like lxc tools
|
||||
or docker provides to share the network namespace. The following can be used to share
|
||||
required namespaces. If we want to share only one then the other namespaces can be ignored.
|
||||
The netns option is specific to sharenet. It can be used in cases we want to use existing network namespace
|
||||
rather than creating new network namespace for the container. In this case privnet option will be
|
||||
ignored.
|
||||
</p>
|
||||
<pre>
|
||||
<domain type='lxc' xmlns:lxc='http://libvirt.org/schemas/domain/lxc/1.0'>
|
||||
...
|
||||
<lxc:namespace>
|
||||
<lxc:sharenet type='netns' value='red'/>
|
||||
<lxc:shareuts type='name' value='container1'/>
|
||||
<lxc:shareipc type='pid' value='12345'/>
|
||||
</lxc:namespace>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The use of namespace passthrough requires libvirt >= 1.2.19
|
||||
</p>
|
||||
|
||||
<h2><a id="usage">Container usage / management</a></h2>
|
||||
|
||||
<p>
|
||||
As with any libvirt virtualization driver, LXC containers can be
|
||||
managed via a wide variety of libvirt based tools. At the lowest
|
||||
level the <code>virsh</code> command can be used to perform many
|
||||
tasks, by passing the <code>-c lxc:///system</code> argument. As an
|
||||
alternative to repeating the URI with every command, the <code>LIBVIRT_DEFAULT_URI</code>
|
||||
environment variable can be set to <code>lxc:///system</code>. The
|
||||
examples that follow outline some common operations with virsh
|
||||
and LXC. For further details about usage of virsh consult its
|
||||
manual page.
|
||||
</p>
|
||||
|
||||
<h3><a id="usageSave">Defining (saving) container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh define</code> command takes an XML configuration
|
||||
document and loads it into libvirt, saving the configuration on disk
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system define myguest.xml
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageView">Viewing container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh dumpxml</code> command can be used to view the
|
||||
current XML configuration of a container. By default the XML
|
||||
output reflects the current state of the container. If the
|
||||
container is running, it is possible to explicitly request the
|
||||
persistent configuration, instead of the current live configuration
|
||||
using the <code>--inactive</code> flag
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system dumpxml myguest
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageStart">Starting containers</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh start</code> command can be used to start a
|
||||
container from a previously defined persistent configuration
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system start myguest
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
It is also possible to start so called "transient" containers,
|
||||
which do not require a persistent configuration to be saved
|
||||
by libvirt, using the <code>virsh create</code> command.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system create myguest.xml
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a id="usageStop">Stopping containers</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh shutdown</code> command can be used
|
||||
to request a graceful shutdown of the container. By default
|
||||
this command will first attempt to send a message to the
|
||||
init process via the <code>/dev/initctl</code> device node.
|
||||
If no such device node exists, then it will send SIGTERM
|
||||
to PID 1 inside the container.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system shutdown myguest
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If the container does not respond to the graceful shutdown
|
||||
request, it can be forcibly stopped using the <code>virsh destroy</code>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system destroy myguest
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a id="usageReboot">Rebooting a container</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh reboot</code> command can be used
|
||||
to request a graceful shutdown of the container. By default
|
||||
this command will first attempt to send a message to the
|
||||
init process via the <code>/dev/initctl</code> device node.
|
||||
If no such device node exists, then it will send SIGHUP
|
||||
to PID 1 inside the container.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system reboot myguest
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageDelete">Undefining (deleting) a container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh undefine</code> command can be used to delete the
|
||||
persistent configuration of a container. If the guest is currently
|
||||
running, this will turn it into a "transient" guest.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system undefine myguest
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageConnect">Connecting to a container console</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh console</code> command can be used to connect
|
||||
to the text console associated with a container.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system console myguest
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If the container has been configured with multiple console devices,
|
||||
then the <code>--devname</code> argument can be used to choose the
|
||||
console to connect to.
|
||||
In LXC, multiple consoles will be named
|
||||
as 'console0', 'console1', 'console2', etc.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system console myguest --devname console1
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageEnter">Running commands in a container</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh lxc-enter-namespace</code> command can be used
|
||||
to enter the namespaces and security context of a container
|
||||
and then execute an arbitrary command.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system lxc-enter-namespace myguest -- /bin/ls -al /dev
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageTop">Monitoring container utilization</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virt-top</code> command can be used to monitor the
|
||||
activity and resource utilization of all containers on a
|
||||
host
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virt-top -c lxc:///system
|
||||
</pre>
|
||||
|
||||
<h3><a id="usageConvert">Converting LXC container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> command can be used to convert
|
||||
most of the LXC container configuration into a domain XML fragment
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
# virsh -c lxc:///system domxml-from-native lxc-tools /var/lib/lxc/myguest/config
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This conversion has some limitations due to the fact that the
|
||||
domxml-from-native command output has to be independent of the host. Here
|
||||
are a few things to take care of before converting:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Replace the fstab file referenced by <tt>lxc.mount</tt> by the corresponding
|
||||
lxc.mount.entry lines.
|
||||
</li>
|
||||
<li>
|
||||
Replace all relative sizes of tmpfs mount entries to absolute sizes. Also
|
||||
make sure that tmpfs entries all have a size option (default is 50%).
|
||||
</li>
|
||||
<li>
|
||||
Define <tt>lxc.cgroup.memory.limit_in_bytes</tt> to properly limit the memory
|
||||
available to the container. The conversion will use 64MiB as the default.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,274 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Host device management</h1>
|
||||
|
||||
<p>
|
||||
Libvirt provides management of both physical and virtual host devices
|
||||
(historically also referred to as node devices) like USB, PCI, SCSI, and
|
||||
network devices. This also includes various virtualization capabilities
|
||||
which the aforementioned devices provide for utilization, for example
|
||||
SR-IOV, NPIV, MDEV, DRM, etc.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The node device driver provides means to list and show details about host
|
||||
devices (<code>virsh nodedev-list</code>,
|
||||
<code>virsh nodedev-dumpxml</code>), which are generic and can be used
|
||||
with all devices. It also provides means to create and destroy devices
|
||||
(<code>virsh nodedev-create</code>, <code>virsh nodedev-destroy</code>)
|
||||
which are meant to be used to create virtual devices, currently only
|
||||
supported by NPIV
|
||||
(<a href="http://wiki.libvirt.org/page/NPIV_in_libvirt">more info about NPIV)</a>).
|
||||
Devices on the host system are arranged in a tree-like hierarchy, with
|
||||
the root node being called <code>computer</code>. The node device driver
|
||||
supports two backends to manage the devices, HAL and udev, with the former
|
||||
being deprecated in favour of the latter.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Details of the XML format of a host device can be found <a
|
||||
href="formatnode.html">here</a>. Of particular interest is the
|
||||
<code>capability</code> element, which describes features supported by
|
||||
the device. Some specific device types are addressed in more detail
|
||||
below.
|
||||
</p>
|
||||
<h2>Basic structure of a node device</h2>
|
||||
<pre>
|
||||
<device>
|
||||
<name>pci_0000_00_17_0</name>
|
||||
<path>/sys/devices/pci0000:00/0000:00:17.0</path>
|
||||
<parent>computer</parent>
|
||||
<driver>
|
||||
<name>ahci</name>
|
||||
</driver>
|
||||
<capability type='pci'>
|
||||
...
|
||||
</capability>
|
||||
</device></pre>
|
||||
|
||||
<ul id="toc"/>
|
||||
|
||||
<h2><a id="PCI">PCI host devices</a></h2>
|
||||
<dl>
|
||||
<dt><code>capability</code></dt>
|
||||
<dd>
|
||||
When used as top level element, the supported values for the
|
||||
<code>type</code> attribute are <code>pci</code> and
|
||||
<code>phys_function</code> (see <a href="#SRIOVCap">SR-IOV below</a>).
|
||||
</dd>
|
||||
</dl>
|
||||
<pre>
|
||||
<device>
|
||||
<name>pci_0000_04_00_1</name>
|
||||
<path>/sys/devices/pci0000:00/0000:00:06.0/0000:04:00.1</path>
|
||||
<parent>pci_0000_00_06_0</parent>
|
||||
<driver>
|
||||
<name>igb</name>
|
||||
</driver>
|
||||
<capability type='pci'>
|
||||
<domain>0</domain>
|
||||
<bus>4</bus>
|
||||
<slot>0</slot>
|
||||
<function>1</function>
|
||||
<product id='0x10c9'>82576 Gigabit Network Connection</product>
|
||||
<vendor id='0x8086'>Intel Corporation</vendor>
|
||||
<iommuGroup number='15'>
|
||||
<address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/>
|
||||
</iommuGroup>
|
||||
<numa node='0'/>
|
||||
<pci-express>
|
||||
<link validity='cap' port='1' speed='2.5' width='2'/>
|
||||
<link validity='sta' speed='2.5' width='2'/>
|
||||
</pci-express>
|
||||
</capability>
|
||||
</device></pre>
|
||||
|
||||
<p>
|
||||
The XML format for a PCI device stays the same for any further
|
||||
capabilities it supports, a single nested <code><capability></code>
|
||||
element will be included for each capability the device supports.
|
||||
</p>
|
||||
|
||||
<h3><a id="SRIOVCap">SR-IOV capability</a></h3>
|
||||
<p>
|
||||
Single root input/output virtualization (SR-IOV) allows sharing of the
|
||||
PCIe resources by multiple virtual environments. That is achieved by
|
||||
slicing up a single full-featured physical resource called physical
|
||||
function (PF) into multiple devices called virtual functions (VFs) sharing
|
||||
their configuration with the underlying PF. Despite the SR-IOV
|
||||
specification, the amount of VFs that can be created on a PF varies among
|
||||
manufacturers.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Suppose the NIC <a href="#PCI">above</a> was also SR-IOV capable, it would
|
||||
also include a nested
|
||||
<code><capability></code> element enumerating all virtual
|
||||
functions available on the physical device (physical port) like in the
|
||||
example below.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<capability type='pci'>
|
||||
...
|
||||
<capability type='virt_functions' maxCount='7'>
|
||||
<address domain='0x0000' bus='0x04' slot='0x10' function='0x1'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x10' function='0x3'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x10' function='0x5'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x10' function='0x7'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x11' function='0x1'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x11' function='0x3'/>
|
||||
<address domain='0x0000' bus='0x04' slot='0x11' function='0x5'/>
|
||||
</capability>
|
||||
...
|
||||
</capability></pre>
|
||||
<p>
|
||||
A SR-IOV child device on the other hand, would then report its top level
|
||||
capability type as a <code>phys_function</code> instead:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<device>
|
||||
...
|
||||
<capability type='phys_function'>
|
||||
<address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
|
||||
</capability>
|
||||
...
|
||||
</device></pre>
|
||||
|
||||
<h3><a id="MDEVCap">MDEV capability</a></h3>
|
||||
<p>
|
||||
A PCI device capable of creating mediated devices will include a nested
|
||||
capability <code>mdev_types</code> which enumerates all supported mdev
|
||||
types on the physical device, along with the type attributes available
|
||||
through sysfs. A detailed description of the XML format for the
|
||||
<code>mdev_types</code> capability can be found
|
||||
<a href="formatnode.html#MDEVCap">here</a>.
|
||||
</p>
|
||||
<p>
|
||||
The following example shows how we might represent an NVIDIA GPU device
|
||||
that supports mediated devices. See below for <a href="#MDEV">more
|
||||
information about mediated devices</a>.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<device>
|
||||
...
|
||||
<driver>
|
||||
<name>nvidia</name>
|
||||
</driver>
|
||||
<capability type='pci'>
|
||||
...
|
||||
<capability type='mdev_types'>
|
||||
<type id='nvidia-11'>
|
||||
<name>GRID M60-0B</name>
|
||||
<deviceAPI>vfio-pci</deviceAPI>
|
||||
<availableInstances>16</availableInstances>
|
||||
</type>
|
||||
<!-- Here would come the rest of the available mdev types -->
|
||||
</capability>
|
||||
...
|
||||
</capability>
|
||||
</device></pre>
|
||||
|
||||
<h2><a id="MDEV">Mediated devices (MDEVs)</a></h2>
|
||||
<p>
|
||||
Mediated devices (<span class="since">Since 3.2.0</span>) are software
|
||||
devices defining resource allocation on the backing physical device which
|
||||
in turn allows the parent physical device's resources to be divided into
|
||||
several mediated devices, thus sharing the physical device's performance
|
||||
among multiple guests. Unlike SR-IOV however, where a PCIe device appears
|
||||
as multiple separate PCIe devices on the host's PCI bus, mediated devices
|
||||
only appear on the mdev virtual bus. Therefore, no detach/reattach
|
||||
procedure from/to the host driver procedure is involved even though
|
||||
mediated devices are used in a direct device assignment manner. A
|
||||
detailed description of the XML format for the <code>mdev</code>
|
||||
capability can be found <a href="formatnode.html#mdev">here</a>.
|
||||
</p>
|
||||
|
||||
<h3>Example of a mediated device</h3>
|
||||
<pre>
|
||||
<device>
|
||||
<name>mdev_4b20d080_1b54_4048_85b3_a6a62d165c01</name>
|
||||
<path>/sys/devices/pci0000:00/0000:00:02.0/4b20d080-1b54-4048-85b3-a6a62d165c01</path>
|
||||
<parent>pci_0000_06_00_0</parent>
|
||||
<driver>
|
||||
<name>vfio_mdev</name>
|
||||
</driver>
|
||||
<capability type='mdev'>
|
||||
<type id='nvidia-11'/>
|
||||
<iommuGroup number='12'/>
|
||||
</capability>
|
||||
</device></pre>
|
||||
|
||||
<p>
|
||||
The support of mediated device's framework in libvirt's node device driver
|
||||
covers the following features:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
list available mediated devices on the host
|
||||
(<span class="since">Since 3.4.0</span>)
|
||||
</li>
|
||||
<li>
|
||||
display device details
|
||||
(<span class="since">Since 3.4.0</span>)
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Because mediated devices are instantiated from vendor specific templates,
|
||||
simply called 'types', information describing these types is contained
|
||||
within the parent device's capabilities
|
||||
(see the example in <a href="#PCI">PCI host devices</a>).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To see the supported mediated device types on a specific physical device
|
||||
use the following:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ ls /sys/class/mdev_bus/<device>/mdev_supported_types</pre>
|
||||
|
||||
<p>
|
||||
Before creating a mediated device, unbind the device from the respective
|
||||
device driver, eg. subchannel I/O driver for a CCW device. Then bind the
|
||||
device to the respective VFIO driver. For a CCW device, also unbind the
|
||||
corresponding subchannel of the CCW device from the subchannel I/O driver
|
||||
and then bind the subchannel (instead of the CCW device) to the vfio_ccw
|
||||
driver. The below example shows the unbinding and binding steps for a CCW
|
||||
device.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
device="0.0.1234"
|
||||
subchannel="0.0.0123"
|
||||
echo $device > /sys/bus/ccw/devices/$device/driver/unbind
|
||||
echo $subchannel > /sys/bus/css/devices/$subchannel/driver/unbind
|
||||
echo $subchannel > /sys/bus/css/drivers/vfio_ccw/bind
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
To manually instantiate a mediated device, use one of the following as a
|
||||
reference. For a CCW device, use the subchannel ID instead of the device
|
||||
ID.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ uuidgen > /sys/class/mdev_bus/<device>/mdev_supported_types/<type>/create
|
||||
...
|
||||
$ echo <UUID> > /sys/class/mdev_bus/<device>/mdev_supported_types/<type>/create</pre>
|
||||
|
||||
<p>
|
||||
Manual removal of a mediated device is then performed as follows:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
$ echo 1 > /sys/bus/mdev/devices/<uuid>/remove</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,123 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>OpenVZ container driver</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
The OpenVZ driver for libvirt allows use and management of container
|
||||
based virtualization on a Linux host OS. Prior to using the OpenVZ
|
||||
driver, the OpenVZ enabled kernel must be installed & booted, and the
|
||||
OpenVZ userspace tools installed. The libvirt driver has been tested
|
||||
with OpenVZ 3.0.22, but other 3.0.x versions should also work without
|
||||
undue trouble.
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://openvz.org/">OpenVZ</a> Linux container
|
||||
system
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="connections">Connections to OpenVZ driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt OpenVZ driver is a single-instance privileged driver,
|
||||
with a driver name of 'openvz'. Some example connection URIs for
|
||||
the libvirt driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
openvz:///system (local access)
|
||||
openvz+unix:///system (local access)
|
||||
openvz://example.com/system (remote access, TLS/x509)
|
||||
openvz+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a id="notes">Notes on bridged networking</a></h2>
|
||||
|
||||
<p>
|
||||
Bridged networking enables a guest domain (ie container) to have its
|
||||
network interface connected directly to the host's physical LAN. Before
|
||||
this can be used there are a couple of configuration pre-requisites for
|
||||
the host OS.
|
||||
</p>
|
||||
|
||||
<h3><a id="host">Host network devices</a></h3>
|
||||
|
||||
<p>
|
||||
One or more of the physical devices must be attached to a bridge. The
|
||||
process for this varies according to the operating system in use, so
|
||||
for up to date notes consult the <a href="http://wiki.libvirt.org">Wiki</a>
|
||||
or your operating system's networking documentation. The basic idea is
|
||||
that the host OS should end up with a bridge device "br0" containing a
|
||||
physical device "eth0", or a bonding device "bond0".
|
||||
</p>
|
||||
|
||||
<h3><a id="tools">OpenVZ tools configuration</a></h3>
|
||||
|
||||
<p>
|
||||
OpenVZ releases later than 3.0.23 ship with a standard network device
|
||||
setup script that is able to setup bridging, named
|
||||
<code>/usr/sbin/vznetaddbr</code>. For releases prior to 3.0.23, this
|
||||
script must be created manually by the host OS administrator. The
|
||||
simplest way is to just download the latest version of this script
|
||||
from a newer OpenVZ release, or upstream source repository. Then
|
||||
a generic configuration file <code>/etc/vz/vznet.conf</code>
|
||||
must be created containing
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
#!/bin/bash
|
||||
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The host OS is now ready to allow bridging of guest containers, which
|
||||
will work whether the container is started with libvirt, or OpenVZ
|
||||
tools.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="example">Example guest domain XML configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The current libvirt OpenVZ driver has a restriction that the
|
||||
domain names must match the OpenVZ container VEID, which by
|
||||
convention start at 100, and are incremented from there. The
|
||||
choice of OS template to use inside the container is determined
|
||||
by the <code>filesystem</code> tag, and the template source name
|
||||
matches the templates known to OpenVZ tools.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<domain type='openvz' id='104'>
|
||||
<name>104</name>
|
||||
<uuid>86c12009-e591-a159-6e9f-91d18b85ef78</uuid>
|
||||
<vcpu>3</vcpu>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/sbin/init</init>
|
||||
</os>
|
||||
<devices>
|
||||
<filesystem type='template'>
|
||||
<source name='fedora-9-i386-minimal'/>
|
||||
<target dir='/'/>
|
||||
</filesystem>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:18:51:5b:ea:bf'/>
|
||||
<source bridge='br0'/>
|
||||
<target dev='veth101.0'/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,700 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>KVM/QEMU hypervisor driver</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
The libvirt KVM/QEMU driver can manage any QEMU emulator from
|
||||
version 1.5.0 or later.
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="https://www.linux-kvm.org/">KVM</a> Linux
|
||||
hypervisor
|
||||
</li>
|
||||
<li>
|
||||
The <a href="https://wiki.qemu.org/Index.html">QEMU</a> emulator
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>QEMU emulators</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu</code>, <code>qemu-system-x86_64</code>,
|
||||
<code>qemu-system-microblaze</code>,
|
||||
<code>qemu-system-microblazeel</code>,
|
||||
<code>qemu-system-mips</code>,<code>qemu-system-mipsel</code>,
|
||||
<code>qemu-system-sparc</code>,<code>qemu-system-ppc</code>. The results
|
||||
of this can be seen from the capabilities XML output.
|
||||
</li>
|
||||
<li>
|
||||
<strong>KVM hypervisor</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu-kvm</code> and <code>/dev/kvm</code> device
|
||||
node. If both are found, then KVM fully virtualized, hardware accelerated
|
||||
guests will be available.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="uris">Connections to QEMU driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt QEMU driver is a multi-instance driver, providing a single
|
||||
system wide privileged driver (the "system" instance), and per-user
|
||||
unprivileged drivers (the "session" instance). The URI driver protocol
|
||||
is "qemu". Some example connection URIs for the libvirt driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
qemu:///session (local access to per-user instance)
|
||||
qemu+unix:///session (local access to per-user instance)
|
||||
|
||||
qemu:///system (local access to system instance)
|
||||
qemu+unix:///system (local access to system instance)
|
||||
qemu://example.com/system (remote access, TLS/x509)
|
||||
qemu+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
qemu+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h3><a id="uriembedded">Embedded driver</a></h3>
|
||||
|
||||
<p>
|
||||
Since 6.1.0 the QEMU driver has experimental support for operating
|
||||
in an embedded mode. In this scenario, rather than connecting to
|
||||
the libvirtd daemon, the QEMU driver runs in the client application
|
||||
process directly. To use this the client application must have
|
||||
registered & be running an instance of the event loop. To open
|
||||
the driver in embedded mode the app use the new URI path and specify
|
||||
a virtual root directory under which the driver will create content.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
qemu:///embed?root=/some/dir
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Broadly speaking the range of functionality is intended to be
|
||||
on a par with that seen when using the traditional system or
|
||||
session libvirt connections to QEMU. The features will of course
|
||||
differ depending on whether the application using the embedded
|
||||
driver is running privileged or unprivileged. For example PCI
|
||||
device assignment or TAP based networking are only available
|
||||
when running privileged. While the embedded mode is still classed
|
||||
as experimental some features may change their default settings
|
||||
between releases.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
By default if the application uses any APIs associated with
|
||||
secondary drivers, these will result in a connection being
|
||||
opened to the corresponding driver in libvirtd. For example,
|
||||
this allows a virtual machine from the embedded QEMU to connect
|
||||
its NIC to a virtual network or connect its disk to a storage
|
||||
volume. Some of the secondary drivers will also be able to support
|
||||
running in embedded mode. Currently this is supported by the
|
||||
secrets driver, to allow for use of VMs with encrypted disks
|
||||
</p>
|
||||
|
||||
<h4><a id="embedTree">Directory tree</a></h4>
|
||||
|
||||
<p>
|
||||
Under the specified root directory the following locations will
|
||||
be used
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
/some/dir
|
||||
|
|
||||
+- log
|
||||
| |
|
||||
| +- qemu
|
||||
| +- swtpm
|
||||
|
|
||||
+- etc
|
||||
| |
|
||||
| +- qemu
|
||||
| +- pki
|
||||
| |
|
||||
| +- qemu
|
||||
|
|
||||
+- run
|
||||
| |
|
||||
| +- qemu
|
||||
| +- swtpm
|
||||
|
|
||||
+- cache
|
||||
| |
|
||||
| +- qemu
|
||||
|
|
||||
+- lib
|
||||
|
|
||||
+- qemu
|
||||
+- swtpm
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Note that UNIX domain sockets used for QEMU virtual machines had
|
||||
a maximum filename length of 108 characters. Bear this in mind
|
||||
when picking a root directory to avoid risk of exhausting the
|
||||
filename space. The application is responsible for recursively
|
||||
purging the contents of this directory tree once they no longer
|
||||
require a connection, though it can also be left intact for reuse
|
||||
when opening a future connection.
|
||||
</p>
|
||||
|
||||
<h4><a id="embedAPI">API usage with event loop</a></h4>
|
||||
|
||||
<p>
|
||||
To use the QEMU driver in embedded mode the application must
|
||||
register an event loop with libvirt. Many of the QEMU driver
|
||||
API calls will rely on the event loop processing data. With this
|
||||
in mind, applications must <strong>NEVER</strong> invoke API
|
||||
calls from the event loop thread itself, only other threads.
|
||||
Not following this rule will lead to deadlocks in the API.
|
||||
This restriction is intended to be lifted in a future release
|
||||
of libvirt, once QMP processing moves to a dedicated thread.
|
||||
</p>
|
||||
|
||||
<h2><a id="security">Driver security architecture</a></h2>
|
||||
|
||||
<p>
|
||||
There are multiple layers to security in the QEMU driver, allowing for
|
||||
flexibility in the use of QEMU based virtual machines.
|
||||
</p>
|
||||
|
||||
<h3><a id="securitydriver">Driver instances</a></h3>
|
||||
|
||||
<p>
|
||||
As explained above there are two ways to access the QEMU driver
|
||||
in libvirt. The "qemu:///session" family of URIs connect to a
|
||||
libvirtd instance running as the same user/group ID as the client
|
||||
application. Thus the QEMU instances spawned from this driver will
|
||||
share the same privileges as the client application. The intended
|
||||
use case for this driver is desktop virtualization, with virtual
|
||||
machines storing their disk images in the user's home directory and
|
||||
being managed from the local desktop login session.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The "qemu:///system" family of URIs connect to a
|
||||
libvirtd instance running as the privileged system account 'root'.
|
||||
Thus the QEMU instances spawned from this driver may have much
|
||||
higher privileges than the client application managing them.
|
||||
The intended use case for this driver is server virtualization,
|
||||
where the virtual machines may need to be connected to host
|
||||
resources (block, PCI, USB, network devices) whose access requires
|
||||
elevated privileges.
|
||||
</p>
|
||||
|
||||
<h3><a id="securitydac">POSIX users/groups</a></h3>
|
||||
|
||||
<p>
|
||||
In the "session" instance, the POSIX users/groups model restricts QEMU
|
||||
virtual machines (and libvirtd in general) to only have access to resources
|
||||
with the same user/group ID as the client application. There is no
|
||||
finer level of configuration possible for the "session" instances.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the "system" instance, libvirt releases from 0.7.0 onwards allow
|
||||
control over the user/group that the QEMU virtual machines are run
|
||||
as. A build of libvirt with no configuration parameters set will
|
||||
still run QEMU processes as root:root. It is possible to change
|
||||
this default by using the --with-qemu-user=$USERNAME and
|
||||
--with-qemu-group=$GROUPNAME arguments to 'configure' during
|
||||
build. It is strongly recommended that vendors build with both
|
||||
of these arguments set to 'qemu'. Regardless of this build time
|
||||
default, administrators can set a per-host default setting in
|
||||
the <code>/etc/libvirt/qemu.conf</code> configuration file via
|
||||
the <code>user=$USERNAME</code> and <code>group=$GROUPNAME</code>
|
||||
parameters. When a non-root user or group is configured, the
|
||||
libvirt QEMU driver will change uid/gid to match immediately
|
||||
before executing the QEMU binary for a virtual machine.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If QEMU virtual machines from the "system" instance are being
|
||||
run as non-root, there will be greater restrictions on what
|
||||
host resources the QEMU process will be able to access. The
|
||||
libvirtd daemon will attempt to manage permissions on resources
|
||||
to minimise the likelihood of unintentional security denials,
|
||||
but the administrator / application developer must be aware of
|
||||
some of the consequences / restrictions.
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<p>
|
||||
The directories <code>/var/run/libvirt/qemu/</code>,
|
||||
<code>/var/lib/libvirt/qemu/</code> and
|
||||
<code>/var/cache/libvirt/qemu/</code> must all have their
|
||||
ownership set to match the user / group ID that QEMU
|
||||
guests will be run as. If the vendor has set a non-root
|
||||
user/group for the QEMU driver at build time, the
|
||||
permissions should be set automatically at install time.
|
||||
If a host administrator customizes user/group in
|
||||
<code>/etc/libvirt/qemu.conf</code>, they will need to
|
||||
manually set the ownership on these directories.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
When attaching USB and PCI devices to a QEMU guest,
|
||||
QEMU will need to access files in <code>/dev/bus/usb</code>
|
||||
and <code>/sys/bus/pci/devices</code> respectively. The libvirtd daemon
|
||||
will automatically set the ownership on specific devices
|
||||
that are assigned to a guest at start time. There should
|
||||
not be any need for administrator changes in this respect.
|
||||
</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>
|
||||
Any files/devices used as guest disk images must be
|
||||
accessible to the user/group ID that QEMU guests are
|
||||
configured to run as. The libvirtd daemon will automatically
|
||||
set the ownership of the file/device path to the correct
|
||||
user/group ID. Applications / administrators must be aware
|
||||
though that the parent directory permissions may still
|
||||
deny access. The directories containing disk images
|
||||
must either have their ownership set to match the user/group
|
||||
configured for QEMU, or their UNIX file permissions must
|
||||
have the 'execute/search' bit enabled for 'others'.
|
||||
</p>
|
||||
<p>
|
||||
The simplest option is the latter one, of just enabling
|
||||
the 'execute/search' bit. For any directory to be used
|
||||
for storing disk images, this can be achieved by running
|
||||
the following command on the directory itself, and any
|
||||
parent directories
|
||||
</p>
|
||||
<pre>
|
||||
chmod o+x /path/to/directory
|
||||
</pre>
|
||||
<p>
|
||||
In particular note that if using the "system" instance
|
||||
and attempting to store disk images in a user home
|
||||
directory, the default permissions on $HOME are typically
|
||||
too restrictive to allow access.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The libvirt maintainers <strong>strongly recommend against</strong>
|
||||
running QEMU as the root user/group. This should not be required
|
||||
in most supported usage scenarios, as libvirt will generally do the
|
||||
right thing to grant QEMU access to files it is permitted to
|
||||
use when it is running non-root.
|
||||
</p>
|
||||
|
||||
<h3><a id="securitycap">Linux process capabilities</a></h3>
|
||||
|
||||
<p>
|
||||
In versions of libvirt prior to 6.0.0, even if QEMU was configured
|
||||
to run as the root user / group, libvirt would strip all process
|
||||
capabilities. This meant that QEMU could only read/write files
|
||||
owned by root, or with open permissions. In reality, stripping
|
||||
capabilities did not have any security benefit, as it was trivial
|
||||
to get commands to run in another context with full capabilities,
|
||||
for example, by creating a cronjob.
|
||||
</p>
|
||||
<p>
|
||||
Thus since 6.0.0, if QEMU is running as root, it will keep all
|
||||
process capabilities. Behaviour when QEMU is running non-root
|
||||
is unchanged, it still has no capabilities.
|
||||
</p>
|
||||
|
||||
<h3><a id="securityselinux">SELinux basic confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The basic SELinux protection for QEMU virtual machines is intended to
|
||||
protect the host OS from a compromised virtual machine process. There
|
||||
is no protection between guests.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the basic model, all QEMU virtual machines run under the confined
|
||||
domain <code>root:system_r:qemu_t</code>. It is required that any
|
||||
disk image assigned to a QEMU virtual machine is labelled with
|
||||
<code>system_u:object_r:virt_image_t</code>. In a default deployment,
|
||||
package vendors/distributor will typically ensure that the directory
|
||||
<code>/var/lib/libvirt/images</code> has this label, such that any
|
||||
disk images created in this directory will automatically inherit the
|
||||
correct labelling. If attempting to use disk images in another
|
||||
location, the user/administrator must ensure the directory has be
|
||||
given this requisite label. Likewise physical block devices must
|
||||
be labelled <code>system_u:object_r:virt_image_t</code>.
|
||||
</p>
|
||||
<p>
|
||||
Not all filesystems allow for labelling of individual files. In
|
||||
particular NFS, VFat and NTFS have no support for labelling. In
|
||||
these cases administrators must use the 'context' option when
|
||||
mounting the filesystem to set the default label to
|
||||
<code>system_u:object_r:virt_image_t</code>. In the case of
|
||||
NFS, there is an alternative option, of enabling the <code>virt_use_nfs</code>
|
||||
SELinux boolean.
|
||||
</p>
|
||||
|
||||
<h3><a id="securitysvirt">SELinux sVirt confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The SELinux sVirt protection for QEMU virtual machines builds to the
|
||||
basic level of protection, to also allow individual guests to be
|
||||
protected from each other.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the sVirt model, each QEMU virtual machine runs under its own
|
||||
confined domain, which is based on <code>system_u:system_r:svirt_t:s0</code>
|
||||
with a unique category appended, eg, <code>system_u:system_r:svirt_t:s0:c34,c44</code>.
|
||||
The rules are setup such that a domain can only access files which are
|
||||
labelled with the matching category level, eg
|
||||
<code>system_u:object_r:svirt_image_t:s0:c34,c44</code>. This prevents one
|
||||
QEMU process accessing any file resources that are prevent to another QEMU
|
||||
process.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
There are two ways of assigning labels to virtual machines under sVirt.
|
||||
In the default setup, if sVirt is enabled, guests will get an automatically
|
||||
assigned unique label each time they are booted. The libvirtd daemon will
|
||||
also automatically relabel exclusive access disk images to match this
|
||||
label. Disks that are marked as <shared> will get a generic
|
||||
label <code>system_u:system_r:svirt_image_t:s0</code> allowing all guests
|
||||
read/write access them, while disks marked as <readonly> will
|
||||
get a generic label <code>system_u:system_r:svirt_content_t:s0</code>
|
||||
which allows all guests read-only access.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
With statically assigned labels, the application should include the
|
||||
desired guest and file labels in the XML at time of creating the
|
||||
guest with libvirt. In this scenario the application is responsible
|
||||
for ensuring the disk images & similar resources are suitably
|
||||
labelled to match, libvirtd will not attempt any relabelling.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If the sVirt security model is active, then the node capabilities
|
||||
XML will include its details. If a virtual machine is currently
|
||||
protected by the security model, then the guest XML will include
|
||||
its assigned labels. If enabled at compile time, the sVirt security
|
||||
model will always be activated if SELinux is available on the host
|
||||
OS. To disable sVirt, and revert to the basic level of SELinux
|
||||
protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
|
||||
file can be used to change the setting to <code>security_driver="none"</code>
|
||||
</p>
|
||||
|
||||
<h3><a id="securitysvirtaa">AppArmor sVirt confinement</a></h3>
|
||||
|
||||
<p>
|
||||
When using basic AppArmor protection for the libvirtd daemon and
|
||||
QEMU virtual machines, the intention is to protect the host OS
|
||||
from a compromised virtual machine process. There is no protection
|
||||
between guests.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The AppArmor sVirt protection for QEMU virtual machines builds on
|
||||
this basic level of protection, to also allow individual guests to
|
||||
be protected from each other.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In the sVirt model, if a profile is loaded for the libvirtd daemon,
|
||||
then each <code>qemu:///system</code> QEMU virtual machine will have
|
||||
a profile created for it when the virtual machine is started if one
|
||||
does not already exist. This generated profile uses a profile name
|
||||
based on the UUID of the QEMU virtual machine and contains rules
|
||||
allowing access to only the files it needs to run, such as its disks,
|
||||
pid file and log files. Just before the QEMU virtual machine is
|
||||
started, the libvirtd daemon will change into this unique profile,
|
||||
preventing the QEMU process from accessing any file resources that
|
||||
are present in another QEMU process or the host machine.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The AppArmor sVirt implementation is flexible in that it allows an
|
||||
administrator to customize the template file in
|
||||
<code>/etc/apparmor.d/libvirt/TEMPLATE</code> for site-specific
|
||||
access for all newly created QEMU virtual machines. Also, when a new
|
||||
profile is generated, two files are created:
|
||||
<code>/etc/apparmor.d/libvirt/libvirt-<uuid></code> and
|
||||
<code>/etc/apparmor.d/libvirt/libvirt-<uuid>.files</code>. The
|
||||
former can be fine-tuned by the administrator to allow custom access
|
||||
for this particular QEMU virtual machine, and the latter will be
|
||||
updated appropriately when required file access changes, such as when
|
||||
a disk is added. This flexibility allows for situations such as
|
||||
having one virtual machine in complain mode with all others in
|
||||
enforce mode.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
While users can define their own AppArmor profile scheme, a typical
|
||||
configuration will include a profile for <code>/usr/sbin/libvirtd</code>,
|
||||
<code>/usr/lib/libvirt/virt-aa-helper</code> or
|
||||
<code>/usr/libexec/virt-aa-helper</code>(a helper program which the
|
||||
libvirtd daemon uses instead of manipulating AppArmor directly), and
|
||||
an abstraction to be included by <code>/etc/apparmor.d/libvirt/TEMPLATE</code>
|
||||
(typically <code>/etc/apparmor.d/abstractions/libvirt-qemu</code>).
|
||||
An example profile scheme can be found in the examples/apparmor
|
||||
directory of the source distribution.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If the sVirt security model is active, then the node capabilities
|
||||
XML will include its details. If a virtual machine is currently
|
||||
protected by the security model, then the guest XML will include
|
||||
its assigned profile name. If enabled at compile time, the sVirt
|
||||
security model will be activated if AppArmor is available on the host
|
||||
OS and a profile for the libvirtd daemon is loaded when libvirtd is
|
||||
started. To disable sVirt, and revert to the basic level of AppArmor
|
||||
protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
|
||||
file can be used to change the setting to <code>security_driver="none"</code>.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a id="securityacl">Cgroups device ACLs</a></h3>
|
||||
|
||||
<p>
|
||||
Linux kernels have a capability known as "cgroups" which is used
|
||||
for resource management. It is implemented via a number of "controllers",
|
||||
each controller covering a specific task/functional area. One of the
|
||||
available controllers is the "devices" controller, which is able to
|
||||
setup whitelists of block/character devices that a cgroup should be
|
||||
allowed to access. If the "devices" controller is mounted on a host,
|
||||
then libvirt will automatically create a dedicated cgroup for each
|
||||
QEMU virtual machine and setup the device whitelist so that the QEMU
|
||||
process can only access shared devices, and explicitly disks images
|
||||
backed by block devices.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The list of shared devices a guest is allowed access to is
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
/dev/null, /dev/full, /dev/zero,
|
||||
/dev/random, /dev/urandom,
|
||||
/dev/ptmx, /dev/kvm,
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In the event of unanticipated needs arising, this can be customized
|
||||
via the <code>/etc/libvirt/qemu.conf</code> file.
|
||||
To mount the cgroups device controller, the following command
|
||||
should be run as root, prior to starting libvirtd
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
mkdir /dev/cgroup
|
||||
mount -t cgroup none /dev/cgroup -o devices
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
libvirt will then place each virtual machine in a cgroup at
|
||||
<code>/dev/cgroup/libvirt/qemu/$VMNAME/</code>
|
||||
</p>
|
||||
|
||||
<h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
|
||||
<p>The QEMU driver currently supports a single native
|
||||
config format known as <code>qemu-argv</code>. The data for this format
|
||||
is expected to be a single line first a list of environment variables,
|
||||
then the QEMu binary name, finally followed by the QEMU command line
|
||||
arguments</p>
|
||||
|
||||
<h3><a id="xmlimport">Converting from QEMU args to domain XML</a></h3>
|
||||
|
||||
<p>
|
||||
<b>Note:</b> this operation is <span class="removed"> deleted as of
|
||||
5.5.0</span> and will return an error.
|
||||
</p>
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to
|
||||
convert an existing set of QEMU args into a guest description
|
||||
using libvirt Domain XML that can then be used by libvirt.
|
||||
Please note that this command is intended to be used to convert
|
||||
existing qemu guests previously started from the command line to
|
||||
be managed through libvirt. It should not be used a method of
|
||||
creating new guests from scratch. New guests should be created
|
||||
using an application calling the libvirt APIs (see
|
||||
the <a href="apps.html">libvirt applications page</a> for some
|
||||
examples) or by manually crafting XML to pass to virsh.
|
||||
</p>
|
||||
|
||||
<h3><a id="xmlexport">Converting from domain XML to QEMU args</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
guest description using libvirt Domain XML, into a set of QEMU args
|
||||
that can be run manually. Note that currently the command line formatted
|
||||
by libvirt is no longer suited for manually running qemu as the
|
||||
configuration expects various resources and open file descriptors passed
|
||||
to the process which are usually prepared by libvirtd.
|
||||
</p>
|
||||
|
||||
<h2><a id="qemucommand">Pass-through of arbitrary qemu
|
||||
commands</a></h2>
|
||||
|
||||
<p>Libvirt provides an XML namespace and an optional
|
||||
library <code>libvirt-qemu.so</code> for dealing specifically
|
||||
with qemu. When used correctly, these extensions allow testing
|
||||
specific qemu features that have not yet been ported to the
|
||||
generic libvirt XML and API interfaces. However, they
|
||||
are <b>unsupported</b>, in that the library is not guaranteed to
|
||||
have a stable API, abusing the library or XML may result in
|
||||
inconsistent state the crashes libvirtd, and upgrading either
|
||||
qemu-kvm or libvirtd may break behavior of a domain that was
|
||||
relying on a qemu-specific pass-through. If you find yourself
|
||||
needing to use them to access a particular qemu feature, then
|
||||
please post an RFE to the libvirt mailing list to get that
|
||||
feature incorporated into the stable libvirt XML and API
|
||||
interfaces.
|
||||
</p>
|
||||
<p>The library provides two
|
||||
API: <code>virDomainQemuMonitorCommand</code>, for sending an
|
||||
arbitrary monitor command (in either HMP or QMP format) to a
|
||||
qemu guest (<span class="since">Since 0.8.3</span>),
|
||||
and <code>virDomainQemuAttach</code>, for registering a qemu
|
||||
domain that was manually started so that it can then be managed
|
||||
by libvirtd (<span class="since">Since 0.9.4</span>,
|
||||
<span class="removed">removed as of 5.5.0</span>).
|
||||
</p>
|
||||
<p>Additionally, the following XML additions allow fine-tuning of
|
||||
the command line given to qemu when starting a domain
|
||||
(<span class="since">Since 0.8.3</span>). In order to use the
|
||||
XML additions, it is necessary to issue an XML namespace request
|
||||
(the special <code>xmlns:<i>name</i></code> attribute) that
|
||||
pulls in <code>http://libvirt.org/schemas/domain/qemu/1.0</code>;
|
||||
typically, the namespace is given the name
|
||||
of <code>qemu</code>. With the namespace in place, it is then
|
||||
possible to add an element <code><qemu:commandline></code>
|
||||
under <code>domain</code>, with the following sub-elements
|
||||
repeated as often as needed:
|
||||
</p>
|
||||
<dl>
|
||||
<dt><code>qemu:arg</code></dt>
|
||||
<dd>Add an additional command-line argument to the qemu
|
||||
process when starting the domain, given by the value of the
|
||||
attribute <code>value</code>.
|
||||
</dd>
|
||||
<dt><code>qemu:env</code></dt>
|
||||
<dd>Add an additional environment variable to the qemu
|
||||
process when starting the domain, given with the name-value
|
||||
pair recorded in the attributes <code>name</code>
|
||||
and optional <code>value</code>.</dd>
|
||||
</dl>
|
||||
<p>Example:</p><pre>
|
||||
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
|
||||
<name>QEMU-fedora-i686</name>
|
||||
<memory>219200</memory>
|
||||
<os>
|
||||
<type arch='i686' machine='pc'>hvm</type>
|
||||
</os>
|
||||
<devices>
|
||||
<emulator>/usr/bin/qemu-system-x86_64</emulator>
|
||||
</devices>
|
||||
<qemu:commandline>
|
||||
<qemu:arg value='-newarg'/>
|
||||
<qemu:env name='QEMU_ENV' value='VAL'/>
|
||||
</qemu:commandline>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h2><a id="xmlnsfeatures">QEMU feature configuration for testing</a></h2>
|
||||
|
||||
<p>
|
||||
In some cases e.g. when developing a new feature or for testing it may
|
||||
be required to control a given qemu feature (or qemu capability) to test
|
||||
it before it's complete or disable it for debugging purposes.
|
||||
<span class="since">Since 5.5.0</span> it's possible to use the same
|
||||
special qemu namespace as above
|
||||
(<code>http://libvirt.org/schemas/domain/qemu/1.0</code>) and use
|
||||
<code><qemu:capabilities></code> element to add
|
||||
(<code><qemu:add capability="capname"/></code>) or remove
|
||||
(<code><qemu:del capability="capname"/></code>) capability bits.
|
||||
The naming of the feature bits is the same libvirt uses in the status
|
||||
XML. Note that this feature is meant for experiments only and should
|
||||
_not_ be used in production.
|
||||
</p>
|
||||
|
||||
<p>Example:</p><pre>
|
||||
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
|
||||
<name>testvm</name>
|
||||
|
||||
[...]
|
||||
|
||||
<qemu:capabilities>
|
||||
<qemu:add capability='blockdev'/>
|
||||
<qemu:del capability='drive'/>
|
||||
</qemu:capabilities>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<h3>QEMU emulated guest on x86_64</h3>
|
||||
|
||||
<pre><domain type='qemu'>
|
||||
<name>QEMU-fedora-i686</name>
|
||||
<uuid>c7a5fdbd-cdaf-9455-926a-d65c16db1809</uuid>
|
||||
<memory>219200</memory>
|
||||
<currentMemory>219200</currentMemory>
|
||||
<vcpu>2</vcpu>
|
||||
<os>
|
||||
<type arch='i686' machine='pc'>hvm</type>
|
||||
<boot dev='cdrom'/>
|
||||
</os>
|
||||
<devices>
|
||||
<emulator>/usr/bin/qemu-system-x86_64</emulator>
|
||||
<disk type='file' device='cdrom'>
|
||||
<source file='/home/user/boot.iso'/>
|
||||
<target dev='hdc'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/home/user/fedora.img'/>
|
||||
<target dev='hda'/>
|
||||
</disk>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<graphics type='vnc' port='-1'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3>KVM hardware accelerated guest on i686</h3>
|
||||
|
||||
<pre><domain type='kvm'>
|
||||
<name>demo2</name>
|
||||
<uuid>4dea24b3-1d52-d8f3-2516-782e98a23fa0</uuid>
|
||||
<memory>131072</memory>
|
||||
<vcpu>1</vcpu>
|
||||
<os>
|
||||
<type arch="i686">hvm</type>
|
||||
</os>
|
||||
<clock sync="localtime"/>
|
||||
<devices>
|
||||
<emulator>/usr/bin/qemu-kvm</emulator>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/var/lib/libvirt/images/demo2.img'/>
|
||||
<target dev='hda'/>
|
||||
</disk>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
<mac address='24:42:53:21:52:45'/>
|
||||
</interface>
|
||||
<graphics type='vnc' port='-1' keymap='de'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,7 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Remote management driver</h1>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,82 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Secret information management</h1>
|
||||
|
||||
<p>
|
||||
The secrets driver in libvirt provides a simple interface for
|
||||
storing and retrieving secret information.
|
||||
</p>
|
||||
|
||||
<h2><a id="uris">Connections to SECRET driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt SECRET driver is a multi-instance driver, providing a single
|
||||
system wide privileged driver (the "system" instance), and per-user
|
||||
unprivileged drivers (the "session" instance). A connection to the secret
|
||||
driver is automatically available when opening a connection to one of the
|
||||
stateful primary hypervisor drivers. It is none the less also possible to
|
||||
explicitly open just the secret driver, using the URI protocol "secret"
|
||||
Some example connection URIs for the driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
secret:///session (local access to per-user instance)
|
||||
secret+unix:///session (local access to per-user instance)
|
||||
|
||||
secret:///system (local access to system instance)
|
||||
secret+unix:///system (local access to system instance)
|
||||
secret://example.com/system (remote access, TLS/x509)
|
||||
secret+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
secret+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h3><a id="uriembedded">Embedded driver</a></h3>
|
||||
|
||||
<p>
|
||||
Since 6.1.0 the secret driver has experimental support for operating
|
||||
in an embedded mode. In this scenario, rather than connecting to
|
||||
the libvirtd daemon, the secret driver runs in the client application
|
||||
process directly. To open the driver in embedded mode the app use the
|
||||
new URI path and specify a virtual root directory under which the
|
||||
driver will create content.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
secret:///embed?root=/some/dir
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Under the specified root directory the following locations will
|
||||
be used
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
/some/dir
|
||||
|
|
||||
+- etc
|
||||
| |
|
||||
| +- secrets
|
||||
|
|
||||
+- run
|
||||
|
|
||||
+- secrets
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The application is responsible for recursively purging the contents
|
||||
of this directory tree once they no longer require a connection,
|
||||
though it can also be left intact for reuse when opening a future
|
||||
connection.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The range of functionality is intended to be on a par with that
|
||||
seen when using the traditional system or session libvirt connections
|
||||
to QEMU. Normal practice would be to open the secret driver in embedded
|
||||
mode any time one of the other drivers is opened in embedded mode so
|
||||
that the two drivers can interact in-process.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,27 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Test "mock" driver</h1>
|
||||
|
||||
<h2>Connections to Test driver</h2>
|
||||
|
||||
<p>
|
||||
The libvirt Test driver is a per-process fake hypervisor driver,
|
||||
with a driver name of 'test'. The driver maintains all its state
|
||||
in memory. It can start with a pre-configured default config, or
|
||||
be given a path to an alternate config. Some example connection URIs
|
||||
for the libvirt driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
test:///default (local access, default config)
|
||||
test:///path/to/driver/config.xml (local access, custom config)
|
||||
test+unix:///default (local access, default config, via daemon)
|
||||
test://example.com/default (remote access, TLS/x509)
|
||||
test+tcp://example.com/default (remote access, SASl/Kerberos)
|
||||
test+ssh://root@example.com/default (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,172 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>VirtualBox hypervisor driver</h1>
|
||||
<p>
|
||||
The libvirt VirtualBox driver can manage any VirtualBox version
|
||||
from version 4.0 onwards
|
||||
(<span class="since">since libvirt 3.0.0</span>).
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.virtualbox.org/">VirtualBox</a>
|
||||
hypervisor
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Connections to VirtualBox driver</h2>
|
||||
|
||||
<p>
|
||||
The libvirt VirtualBox driver provides per-user drivers (the "session" instance).
|
||||
The uri of the driver protocol is "vbox". Some example connection URIs for the driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
vbox:///session (local access to per-user instance)
|
||||
vbox+unix:///session (local access to per-user instance)
|
||||
vbox+tcp://user@example.com/session (remote access, SASl/Kerberos)
|
||||
vbox+ssh://user@example.com/session (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<strong>NOTE: as of libvirt 1.0.6, the VirtualBox driver will always
|
||||
run inside the libvirtd daemon, instead of being built-in to the
|
||||
libvirt.so library directly. This change was required due to the
|
||||
fact that VirtualBox code is LGPLv2-only licensed, which is not
|
||||
compatible with the libvirt.so license of LGPLv2-or-later. The
|
||||
daemon will be auto-started when the first connection to VirtualBox
|
||||
is requested. This change also means that it will not be possible
|
||||
to use VirtualBox URIs on the Windows platform, until additional
|
||||
work is completed to get the libvirtd daemon working there.</strong>
|
||||
</p>
|
||||
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<pre>
|
||||
<domain type='vbox'>
|
||||
<name>vbox</name>
|
||||
<uuid>4dab22b31d52d8f32516782e98ab3fa0</uuid>
|
||||
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<boot dev='cdrom'/>
|
||||
<boot dev='hd'/>
|
||||
<boot dev='fd'/>
|
||||
<boot dev='network'/>
|
||||
</os>
|
||||
|
||||
<memory>654321</memory>
|
||||
<vcpu>1</vcpu>
|
||||
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
<apic/>
|
||||
</features>
|
||||
|
||||
<devices>
|
||||
<!--Set IDE controller model to PIIX4 (default PIIX3)-->
|
||||
<controller type='ide' model='piix4'/>
|
||||
|
||||
<controller type='scsi' index='0'/>
|
||||
|
||||
<!--VirtualBox SAS Controller-->
|
||||
<controller type='scsi' index='1' model='lsisas1068'/>
|
||||
|
||||
<disk type='file' device='cdrom'>
|
||||
<source file='/home/user/Downloads/slax-6.0.9.iso'/>
|
||||
<target dev='hdc'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/home/user/tmp/vbox.vdi'/>
|
||||
<target dev='hdd'/>
|
||||
</disk>
|
||||
|
||||
<!--Attach to the SCSI controller (index=0, default)-->
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/home/user/tmp/vbox2.vdi'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
</disk>
|
||||
|
||||
<!--Attach to the SAS controller (index=1)-->
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/home/user/tmp/vbox3.vdi'/>
|
||||
<target dev='sda' bus='scsi'/>
|
||||
<address type='drive' controller='1' bus='0' target='0' unit='0'/>
|
||||
</disk>
|
||||
|
||||
<disk type='file' device='floppy'>
|
||||
<source file='/home/user/tmp/WIN98C.IMG'/>
|
||||
<target dev='fda'/>
|
||||
</disk>
|
||||
|
||||
<filesystem type='mount'>
|
||||
<source dir='/home/user/stuff'/>
|
||||
<target dir='my-shared-folder'/>
|
||||
</filesystem>
|
||||
|
||||
<!--BRIDGE-->
|
||||
<interface type='bridge'>
|
||||
<source bridge='eth0'/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<model type='am79c973'/>
|
||||
</interface>
|
||||
|
||||
<!--NAT-->
|
||||
<interface type='user'>
|
||||
<mac address='56:16:3e:5d:c7:9e'/>
|
||||
<model type='82540eM'/>
|
||||
</interface>
|
||||
|
||||
<graphics type='desktop'/>
|
||||
|
||||
<!--Activate the VRDE server with a port in 3389-3689 range-->
|
||||
<graphics type='rdp' autoport='yes' multiUser='yes'/>
|
||||
|
||||
<sound model='sb16'/>
|
||||
|
||||
<parallel type='dev'>
|
||||
<source path='/dev/pts/1'/>
|
||||
<target port='0'/>
|
||||
</parallel>
|
||||
|
||||
<parallel type='dev'>
|
||||
<source path='/dev/pts/2'/>
|
||||
<target port='1'/>
|
||||
</parallel>
|
||||
|
||||
<serial type="dev">
|
||||
<source path="/dev/ttyS0"/>
|
||||
<target port="0"/>
|
||||
</serial>
|
||||
|
||||
<serial type="pipe">
|
||||
<source path="/tmp/serial.txt"/>
|
||||
<target port="1"/>
|
||||
</serial>
|
||||
|
||||
<hostdev mode='subsystem' type='usb'>
|
||||
<source>
|
||||
<vendor id='0x1234'/>
|
||||
<product id='0xbeef'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
|
||||
<hostdev mode='subsystem' type='usb'>
|
||||
<source>
|
||||
<vendor id='0x4321'/>
|
||||
<product id='0xfeeb'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,70 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>Virtuozzo driver</h1>
|
||||
<ul id="toc"></ul>
|
||||
<p>
|
||||
The libvirt vz driver can manage Virtuozzo starting from version 6.0.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.odin.com/products/virtuozzo/">Virtuozzo</a> Solution.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a id="uri">Connections to the Virtuozzo driver</a></h2>
|
||||
<p>
|
||||
The libvirt Virtuozzo driver is a single-instance privileged driver, with a driver name of 'virtuozzo'. Some example connection URIs for the libvirt driver are:
|
||||
</p>
|
||||
<pre>
|
||||
vz:///system (local access)
|
||||
vz+unix:///system (local access)
|
||||
vz://example.com/system (remote access, TLS/x509)
|
||||
vz+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
vz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a id="example">Example guest domain XML configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Virtuozzo driver require at least one hard disk for new domains
|
||||
at this time. It is used for defining directory, where VM should
|
||||
be created.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
<domain type='vz'>
|
||||
<name>demo</name>
|
||||
<uuid>54cdecad-4492-4e31-a209-33cc21d64057</uuid>
|
||||
<description>some description</description>
|
||||
<memory unit='KiB'>1048576</memory>
|
||||
<currentMemory unit='KiB'>1048576</currentMemory>
|
||||
<vcpu placement='static'>2</vcpu>
|
||||
<os>
|
||||
<type arch='x86_64'>hvm</type>
|
||||
</os>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>destroy</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/storage/vol1'/>
|
||||
<target dev='hda'/>
|
||||
</disk>
|
||||
<video>
|
||||
<model type='vga' vram='33554432' heads='1'>
|
||||
<acceleration accel3d='no' accel2d='no'/>
|
||||
</model>
|
||||
</video>
|
||||
</devices>
|
||||
</domain>
|
||||
|
||||
</pre>
|
||||
|
||||
</body></html>
|
||||
@@ -1,89 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>VMware Workstation / Player / Fusion hypervisors driver</h1>
|
||||
<p>
|
||||
The libvirt VMware driver should be able to manage any Workstation,
|
||||
Player, Fusion version supported by the VMware VIX API. See the
|
||||
compatibility list
|
||||
<a href="http://www.vmware.com/support/developer/vix-api/vix110_reference/">here</a>.
|
||||
</p>
|
||||
<p>
|
||||
This driver uses the "vmrun" utility which is distributed with the VMware VIX API.
|
||||
You can download the VIX API
|
||||
from <a href="http://www.vmware.com/support/developer/vix-api/">here</a>.
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.vmware.com/">VMware Workstation and
|
||||
Player</a> hypervisors
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://www.vmware.com/fusion">VMware Fusion</a>
|
||||
hypervisor
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Connections to VMware driver</h2>
|
||||
|
||||
<p>
|
||||
The libvirt VMware driver provides per-user drivers (the "session" instance).
|
||||
Three uris are available:
|
||||
</p>
|
||||
<ul>
|
||||
<li>"vmwareplayer" for VMware Player</li>
|
||||
<li>"vmwarews" for VMware Workstation</li>
|
||||
<li>"vmwarefusion" for VMware Fusion</li>
|
||||
</ul>
|
||||
<p>
|
||||
Some example connection URIs for the driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
vmwareplayer:///session (local access to VMware Player per-user instance)
|
||||
vmwarews:///session (local access to VMware Workstation per-user instance)
|
||||
vmwarefusion:///session (local access to VMware Fusion per-user instance)
|
||||
vmwarews+tcp://user@example.com/session (remote access to VMware Workstation, SASl/Kerberos)
|
||||
vmwarews+ssh://user@example.com/session (remote access to VMware Workstation, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<pre>
|
||||
<domain type='vmware'>
|
||||
<name>vmware</name>
|
||||
<uuid>bea92244-8885-4562-828b-3b086731c5b1</uuid>
|
||||
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
</os>
|
||||
|
||||
<memory>524288</memory>
|
||||
<vcpu>1</vcpu>
|
||||
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
</features>
|
||||
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<source file='/home/user/tmp/disk.vmdk'/>
|
||||
<target bus='ide' dev='hda'/>
|
||||
</disk>
|
||||
|
||||
<interface type='bridge'>
|
||||
<target dev='/dev/vmnet1'/>
|
||||
<source bridge=''/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
</interface>
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,318 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1>libxl hypervisor driver for Xen</h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<p>
|
||||
The libvirt libxl driver provides the ability to manage virtual
|
||||
machines on any Xen release from 4.6.0 onwards.
|
||||
</p>
|
||||
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="https://www.xenproject.org">Xen</a>
|
||||
hypervisor on Linux and Solaris hosts
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt libxl driver uses Xen's libxl API, also known as
|
||||
libxenlight, to implement libvirt's hypervisor driver
|
||||
functionality. libxl provides a consolidated interface for
|
||||
managing a Xen host and its virtual machines, unlike old
|
||||
versions of Xen where applications often had to communicate
|
||||
with xend, xenstored, and the hypervisor itself via hypercalls.
|
||||
With libxl the only pre-requisit is a properly installed Xen
|
||||
host with the libxl toolstack running in a service domain
|
||||
(often Domain-0).
|
||||
</p>
|
||||
|
||||
<h2><a id="uri">Connections to libxl driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt libxl driver is a single-instance privileged driver,
|
||||
with a driver name of 'xen'. Some example connection URIs for
|
||||
the libxl driver are:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
xen:///system (local access, direct)
|
||||
xen+unix:///system (local access, via daemon)
|
||||
xen://example.com/system (remote access, TLS/x509)
|
||||
xen+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
xen+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
|
||||
<p>
|
||||
The libxl driver currently supports three native
|
||||
config formats. The first, known as <code>xen-xm</code>, is the
|
||||
original Xen virtual machine config format used by the legacy
|
||||
xm/xend toolstack. The second, known as <code>xen-sxpr</code>,
|
||||
is also one of the original formats that was used by xend's
|
||||
legacy HTTP RPC service (<span class='removed'>removed in 5.6.0</span>)
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The third format is <code>xen-xl</code>, which is the virtual
|
||||
machine config format supported by modern Xen. The <code>xen-xl</code>
|
||||
format is described in the xl.cfg(5) man page.
|
||||
</p>
|
||||
|
||||
<h3><a id="xmlimport">Converting from XM config files to domain XML</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to convert an
|
||||
existing set of xl, xm, or sxpr config files to libvirt Domain XML,
|
||||
which can then be used by libvirt.
|
||||
</p>
|
||||
|
||||
<pre>$ virsh -c xen:///system domxml-from-native xen-xm rhel5.cfg
|
||||
<domain type='xen'>
|
||||
<name>rhel5pv</name>
|
||||
<uuid>8f07fe28-753f-2729-d76d-bdbd892f949a</uuid>
|
||||
<memory>2560000</memory>
|
||||
<currentMemory>307200</currentMemory>
|
||||
<vcpu>4</vcpu>
|
||||
<bootloader>/usr/bin/pygrub</bootloader>
|
||||
<os>
|
||||
<type arch='x86_64' machine='xenpv'>linux</type>
|
||||
</os>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>restart</on_crash>
|
||||
<devices>
|
||||
<disk type='file' device='disk'>
|
||||
<driver name='tap' type='aio'/>
|
||||
<source file='/var/lib/xen/images/rhel5pv.img'/>
|
||||
<target dev='xvda' bus='xen'/>
|
||||
</disk>
|
||||
<disk type='file' device='disk'>
|
||||
<driver name='tap' type='qcow'/>
|
||||
<source file='/root/qcow1-xen.img'/>
|
||||
<target dev='xvdd' bus='xen'/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:60:36:ba'/>
|
||||
<source bridge='xenbr0'/>
|
||||
</interface>
|
||||
<console type='pty'>
|
||||
<target port='0'/>
|
||||
</console>
|
||||
<input type='mouse' bus='xen'/>
|
||||
<graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3><a id="xmlexport">Converting from domain XML to XM config files</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
guest description using libvirt Domain XML into xl, xm, or sxpr config
|
||||
format.
|
||||
</p>
|
||||
|
||||
<pre>$ virsh -c xen:///system domxml-to-native xen-xm rhel5pv.xml
|
||||
name = "rhel5pv"
|
||||
uuid = "8f07fe28-753f-2729-d76d-bdbd892f949a"
|
||||
maxmem = 2500
|
||||
memory = 300
|
||||
vcpus = 4
|
||||
bootloader = "/usr/bin/pygrub"
|
||||
kernel = "/var/lib/xen/boot_kernel.0YK-cS"
|
||||
ramdisk = "/var/lib/xen/boot_ramdisk.vWgrxK"
|
||||
extra = "ro root=/dev/VolGroup00/LogVol00 rhgb quiet"
|
||||
on_poweroff = "destroy"
|
||||
on_reboot = "restart"
|
||||
on_crash = "restart"
|
||||
sdl = 0
|
||||
vnc = 1
|
||||
vncunused = 1
|
||||
vnclisten = "0.0.0.0"
|
||||
disk = [ "tap:aio:/var/lib/xen/images/rhel5pv.img,xvda,w", "tap:qcow:/root/qcow1-xen.img,xvdd,w" ]
|
||||
vif = [ "mac=00:16:3e:60:36:ba,bridge=virbr0,script=vif-bridge,vifname=vif5.0" ]</pre>
|
||||
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<p>
|
||||
Below are some example XML configurations for Xen guest domains.
|
||||
For full details of the available options, consult the <a href="formatdomain.html">domain XML format</a>
|
||||
guide.
|
||||
</p>
|
||||
|
||||
<h3>Paravirtualized guest bootloader</h3>
|
||||
|
||||
<p>
|
||||
Using a bootloader allows a paravirtualized guest to be booted using
|
||||
a kernel stored inside its virtual disk image
|
||||
</p>
|
||||
|
||||
<pre><domain type='xen' >
|
||||
<name>fc8</name>
|
||||
<bootloader>/usr/bin/pygrub</bootloader>
|
||||
<os>
|
||||
<type>linux</type>
|
||||
</os>
|
||||
<memory>131072</memory>
|
||||
<vcpu>1</vcpu>
|
||||
<devices>
|
||||
<disk type='file'>
|
||||
<source file='/var/lib/xen/images/fc4.img'/>
|
||||
<target dev='sda1'/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='aa:00:00:00:00:11'/>
|
||||
<script path='/etc/xen/scripts/vif-bridge'/>
|
||||
</interface>
|
||||
<console tty='/dev/pts/5'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3>Paravirtualized guest direct kernel boot</h3>
|
||||
|
||||
<p>
|
||||
For installation of paravirtualized guests it is typical to boot the
|
||||
domain using a kernel and initrd stored in the host OS
|
||||
</p>
|
||||
|
||||
<pre><domain type='xen' >
|
||||
<name>fc8</name>
|
||||
<os>
|
||||
<type>linux</type>
|
||||
<kernel>/var/lib/xen/install/vmlinuz-fedora8-x86_64</kernel>
|
||||
<initrd>/var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64</initrd>
|
||||
<cmdline> kickstart=http://example.com/myguest.ks </cmdline>
|
||||
</os>
|
||||
<memory>131072</memory>
|
||||
<vcpu>1</vcpu>
|
||||
<devices>
|
||||
<disk type='file'>
|
||||
<source file='/var/lib/xen/images/fc4.img'/>
|
||||
<target dev='sda1'/>
|
||||
</disk>
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='aa:00:00:00:00:11'/>
|
||||
<script path='/etc/xen/scripts/vif-bridge'/>
|
||||
</interface>
|
||||
<graphics type='vnc' port='-1'/>
|
||||
<console tty='/dev/pts/5'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3>Fullyvirtualized guest BIOS boot</h3>
|
||||
|
||||
<p>
|
||||
Fullyvirtualized guests use the emulated BIOS to boot off the primary
|
||||
harddisk, CDROM or Network PXE ROM.
|
||||
</p>
|
||||
|
||||
<pre><domain type='xen' id='3'>
|
||||
<name>fv0</name>
|
||||
<uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<loader>/usr/lib/xen/boot/hvmloader</loader>
|
||||
<boot dev='hd'/>
|
||||
</os>
|
||||
<memory>524288</memory>
|
||||
<vcpu>1</vcpu>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>restart</on_crash>
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
<apic/>
|
||||
</features>
|
||||
<clock sync="localtime"/>
|
||||
<devices>
|
||||
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<script path='vif-bridge'/>
|
||||
</interface>
|
||||
<disk type='file'>
|
||||
<source file='/var/lib/xen/images/fv0'/>
|
||||
<target dev='hda'/>
|
||||
</disk>
|
||||
<disk type='file' device='cdrom'>
|
||||
<source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/>
|
||||
<target dev='hdc'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<disk type='file' device='floppy'>
|
||||
<source file='/root/fd.img'/>
|
||||
<target dev='fda'/>
|
||||
</disk>
|
||||
<graphics type='vnc' port='5904'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3>Fullyvirtualized guest direct kernel boot</h3>
|
||||
|
||||
<p>
|
||||
With Xen 3.2.0 or later it is possible to bypass the BIOS and directly
|
||||
boot a Linux kernel and initrd as a fullyvirtualized domain. This allows
|
||||
for complete automation of OS installation, for example using the Anaconda
|
||||
kickstart support.
|
||||
</p>
|
||||
|
||||
<pre><domain type='xen' id='3'>
|
||||
<name>fv0</name>
|
||||
<uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<loader>/usr/lib/xen/boot/hvmloader</loader>
|
||||
<kernel>/var/lib/xen/install/vmlinuz-fedora8-x86_64</kernel>
|
||||
<initrd>/var/lib/xen/install/initrd-vmlinuz-fedora8-x86_64</initrd>
|
||||
<cmdline> kickstart=http://example.com/myguest.ks </cmdline>
|
||||
</os>
|
||||
<memory>524288</memory>
|
||||
<vcpu>1</vcpu>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>restart</on_crash>
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
<apic/>
|
||||
</features>
|
||||
<clock sync="localtime"/>
|
||||
<devices>
|
||||
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<script path='vif-bridge'/>
|
||||
</interface>
|
||||
<disk type='file'>
|
||||
<source file='/var/lib/xen/images/fv0'/>
|
||||
<target dev='hda'/>
|
||||
</disk>
|
||||
<disk type='file' device='cdrom'>
|
||||
<source file='/var/lib/xen/images/fc5-x86_64-boot.iso'/>
|
||||
<target dev='hdc'/>
|
||||
<readonly/>
|
||||
</disk>
|
||||
<disk type='file' device='floppy'>
|
||||
<source file='/root/fd.img'/>
|
||||
<target dev='fda'/>
|
||||
</disk>
|
||||
<graphics type='vnc' port='5904'/>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,84 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1 >Handling of errors</h1>
|
||||
<p>The main goals of libvirt when it comes to error handling are:</p>
|
||||
<ul>
|
||||
<li>provide as much detail as possible</li>
|
||||
<li>provide the information as soon as possible</li>
|
||||
<li>dont force the library user into one style of error handling</li>
|
||||
</ul>
|
||||
<p>As result the library provide both synchronous, callback based and
|
||||
asynchronous error reporting. When an error happens in the library code the
|
||||
error is logged, allowing to retrieve it later and if the user registered an
|
||||
error callback it will be called synchronously. Once the call to libvirt ends
|
||||
the error can be detected by the return value and the full information for
|
||||
the last logged error can be retrieved.</p>
|
||||
<p>To avoid as much as possible troubles with a global variable in a
|
||||
multithreaded environment, libvirt will associate when possible the errors to
|
||||
the current connection they are related to, that way the error is stored in a
|
||||
dynamic structure which can be made thread specific. Error callback can be
|
||||
set specifically to a connection with</p>
|
||||
<p>So error handling in the code is the following:</p>
|
||||
<ol>
|
||||
<li>if the error can be associated to a connection for example when failing
|
||||
to look up a domain
|
||||
<ol><li>if there is a callback associated to the connection set with <a href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
|
||||
call it with the error information</li><li>otherwise if there is a global callback set with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
|
||||
call it with the error information</li><li>otherwise call <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
|
||||
which is the default error function of the library issuing the error
|
||||
on stderr</li><li>save the error in the connection for later retrieval with <a href="html/libvirt-virterror.html#virConnGetLastError">virConnGetLastError</a></li></ol></li>
|
||||
<li>otherwise like when failing to create a hypervisor connection:
|
||||
<ol><li>if there is a global callback set with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
|
||||
call it with the error information</li><li>otherwise call <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
|
||||
which is the default error function of the library issuing the error
|
||||
on stderr</li><li>save the error in the connection for later retrieval with <a href="html/libvirt-virterror.html#virGetLastError">virGetLastError</a></li></ol></li>
|
||||
</ol>
|
||||
<p>In all cases the error information is provided as a <a href="html/libvirt-virterror.html#virErrorPtr">virErrorPtr</a> pointer to
|
||||
read-only structure <a href="html/libvirt-virterror.html#virError">virError</a> containing the
|
||||
following fields:</p>
|
||||
<ul>
|
||||
<li>code: an error number from the <a href="html/libvirt-virterror.html#virErrorNumber">virErrorNumber</a>
|
||||
enum</li>
|
||||
<li>domain: an enum indicating which part of libvirt raised the error see
|
||||
<a href="html/libvirt-virterror.html#virErrorDomain">virErrorDomain</a></li>
|
||||
<li>level: the error level, usually VIR_ERR_ERROR, though there is room for
|
||||
warnings like VIR_ERR_WARNING</li>
|
||||
<li>message: the full human-readable formatted string of the error</li>
|
||||
<li>conn: if available a pointer to the <a href="html/libvirt-libvirt-host.html#virConnectPtr">virConnectPtr</a>
|
||||
connection to the hypervisor where this happened</li>
|
||||
<li>dom: if available a pointer to the <a href="html/libvirt-libvirt-domain.html#virDomainPtr">virDomainPtr</a> domain
|
||||
targeted in the operation</li>
|
||||
</ul>
|
||||
<p>and then extra raw information about the error which may be initialized
|
||||
to 0 or NULL if unused</p>
|
||||
<ul>
|
||||
<li>str1, str2, str3: string information, usually str1 is the error
|
||||
message format</li>
|
||||
<li>int1, int2: integer information</li>
|
||||
</ul>
|
||||
<p>So usually, setting up specific error handling with libvirt consist of
|
||||
registering a handler with <a href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a> or
|
||||
with <a href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
|
||||
check the value of the code value, take appropriate action, if needed let
|
||||
libvirt print the error on stderr by calling <a href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>.
|
||||
For asynchronous error handing, set such a function doing nothing to avoid
|
||||
the error being reported on stderr, and call virConnGetLastError or
|
||||
virGetLastError when an API call returned an error value. It can be a good
|
||||
idea to use <a href="html/libvirt-virterror.html#virResetLastError">virResetError</a> or <a href="html/libvirt-virterror.html#virConnResetLastError">virConnResetLastError</a>
|
||||
once an error has been processed fully.</p>
|
||||
<p>At the python level, there only a global reporting callback function at
|
||||
this point, see the error.py example about it:</p>
|
||||
<pre>def handler(ctxt, err):
|
||||
global errno
|
||||
|
||||
#print "handler(%s, %s)" % (ctxt, err)
|
||||
errno = err
|
||||
|
||||
libvirt.registerErrorHandler(handler, 'context') </pre>
|
||||
<p>the second argument to the registerErrorHandler function is passed as the
|
||||
first argument of the callback like in the C version. The error is a tuple
|
||||
containing the same field as a virError in C, but cast to Python.</p>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 872 B |
Binary file not shown.
|
Before Width: | Height: | Size: 1.8 KiB |
BIN
docs/favicon.ico
BIN
docs/favicon.ico
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
@@ -1,514 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE html>
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1 >Firewall and network filtering in libvirt</h1>
|
||||
<p>There are three pieces of libvirt functionality which do network
|
||||
filtering of some type.
|
||||
<br /><br />
|
||||
At a high level they are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>The virtual network driver
|
||||
<br /><br />
|
||||
This provides an isolated bridge device (ie no physical NICs
|
||||
enslaved). Guest TAP devices are attached to this bridge.
|
||||
Guests can talk to each other and the host, and optionally the
|
||||
wider world.
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>The QEMU driver MAC filtering
|
||||
<br /><br />
|
||||
This provides a generic filtering of MAC addresses to prevent
|
||||
the guest spoofing its MAC address. This is mostly obsoleted by
|
||||
the next item, so won't be discussed further.
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>The network filter driver
|
||||
<br /><br />
|
||||
This provides fully configurable, arbitrary network filtering
|
||||
of traffic on guest NICs. Generic rulesets are defined at the
|
||||
host level to control traffic in some manner. Rules sets are
|
||||
then associated with individual NICs of a guest. While not as
|
||||
expressive as directly using iptables/ebtables, this can still
|
||||
do nearly everything you would want to on a guest NIC filter.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a id="fw-virtual-network-driver">The virtual network driver</a>
|
||||
</h3>
|
||||
<p>The typical configuration for guests is to use bridging of the
|
||||
physical NIC on the host to connect the guest directly to the LAN.
|
||||
In RHEL6 there is also the possibility of using macvtap/sr-iov
|
||||
and VEPA connectivity. None of this stuff plays nicely with wireless
|
||||
NICs, since they will typically silently drop any traffic with a
|
||||
MAC address that doesn't match that of the physical NIC.
|
||||
</p>
|
||||
<p>Thus the virtual network driver in libvirt was invented. This takes
|
||||
the form of an isolated bridge device (ie one with no physical NICs
|
||||
enslaved). The TAP devices associated with the guest NICs are attached
|
||||
to the bridge device. This immediately allows guests on a single host
|
||||
to talk to each other and to the host OS (modulo host IPtables rules).
|
||||
</p>
|
||||
<p>libvirt then uses iptables to control what further connectivity is
|
||||
available. There are three configurations possible for a virtual
|
||||
network at time of writing:
|
||||
</p>
|
||||
<ul>
|
||||
<li>isolated: all off-node traffic is completely blocked</li>
|
||||
<li>nat: outbound traffic to the LAN is allowed, but MASQUERADED</li>
|
||||
<li>forward: outbound traffic to the LAN is allowed</li>
|
||||
</ul>
|
||||
<p>The latter 'forward' case requires the virtual network be on a
|
||||
separate sub-net from the main LAN, and that the LAN admin has
|
||||
configured routing for this subnet. In the future we intend to
|
||||
add support for IP subnetting and/or proxy-arp. This allows for
|
||||
the virtual network to use the same subnet as the main LAN and
|
||||
should avoid need for the LAN admin to configure special routing.
|
||||
</p>
|
||||
<p>Libvirt will optionally also provide DHCP services to the virtual
|
||||
network using DNSMASQ. In all cases, we need to allow DNS/DHCP
|
||||
queries to the host OS. Since we can't predict whether the host
|
||||
firewall setup is already allowing this, we insert 4 rules into
|
||||
the head of the INPUT chain
|
||||
</p>
|
||||
<pre>
|
||||
target prot opt in out source destination
|
||||
ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
|
||||
ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
|
||||
ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
|
||||
ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67</pre>
|
||||
<p>Note we have restricted our rules to just the bridge associated
|
||||
with the virtual network, to avoid opening undesirable holes in
|
||||
the host firewall wrt the LAN/WAN.
|
||||
</p>
|
||||
<p>The next rules depend on the type of connectivity allowed, and go
|
||||
in the main FORWARD chain:
|
||||
</p>
|
||||
<ul>
|
||||
<li>type=isolated
|
||||
<br /><br />
|
||||
Allow traffic between guests. Deny inbound. Deny outbound.
|
||||
<pre>
|
||||
target prot opt in out source destination
|
||||
ACCEPT all -- virbr1 virbr1 0.0.0.0/0 0.0.0.0/0
|
||||
REJECT all -- * virbr1 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
|
||||
REJECT all -- virbr1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable</pre>
|
||||
</li>
|
||||
<li>type=nat
|
||||
<br /><br />
|
||||
Allow inbound related to an established connection. Allow
|
||||
outbound, but only from our expected subnet. Allow traffic
|
||||
between guests. Deny all other inbound. Deny all other outbound.
|
||||
<pre>
|
||||
target prot opt in out source destination
|
||||
ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED
|
||||
ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
|
||||
ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
|
||||
REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
|
||||
REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable</pre>
|
||||
</li>
|
||||
<li>type=routed
|
||||
<br /><br />
|
||||
Allow inbound, but only to our expected subnet. Allow
|
||||
outbound, but only from our expected subnet. Allow traffic
|
||||
between guests. Deny all other inbound. Deny all other outbound.
|
||||
<pre>
|
||||
target prot opt in out source destination
|
||||
ACCEPT all -- * virbr2 0.0.0.0/0 192.168.124.0/24
|
||||
ACCEPT all -- virbr2 * 192.168.124.0/24 0.0.0.0/0
|
||||
ACCEPT all -- virbr2 virbr2 0.0.0.0/0 0.0.0.0/0
|
||||
REJECT all -- * virbr2 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
|
||||
REJECT all -- virbr2 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable</pre>
|
||||
</li>
|
||||
<li>Finally, with type=nat, there is also an entry in the POSTROUTING
|
||||
chain to apply masquerading:
|
||||
<pre>
|
||||
target prot opt in out source destination
|
||||
MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24</pre>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a id="fw-firewalld-and-virtual-network-driver">firewalld and the virtual network driver</a>
|
||||
</h3>
|
||||
<p>
|
||||
If <a href="https://firewalld.org">firewalld</a> is active on
|
||||
the host, libvirt will attempt to place the bridge interface of
|
||||
a libvirt virtual network into the firewalld zone named
|
||||
"libvirt" (thus making all guest->host traffic on that network
|
||||
subject to the rules of the "libvirt" zone). This is done
|
||||
because, if firewalld is using its nftables backend (available
|
||||
since firewalld 0.6.0) the default firewalld zone (which would
|
||||
be used if libvirt didn't explicitly set the zone) prevents
|
||||
forwarding traffic from guests through the bridge, as well as
|
||||
preventing DHCP, DNS, and most other traffic from guests to
|
||||
host. The zone named "libvirt" is installed into the firewalld
|
||||
configuration by libvirt (not by firewalld), and allows
|
||||
forwarded traffic through the bridge as well as DHCP, DNS, TFTP,
|
||||
and SSH traffic to the host - depending on firewalld's backend
|
||||
this will be implemented via either iptables or nftables
|
||||
rules. libvirt's own rules outlined above will *always* be
|
||||
iptables rules regardless of which backend is in use by
|
||||
firewalld.
|
||||
</p>
|
||||
<p>
|
||||
NB: It is possible to manually set the firewalld zone for a
|
||||
network's interface with the "zone" attribute of the network's
|
||||
"bridge" element.
|
||||
</p>
|
||||
<p>
|
||||
NB: Prior to libvirt 5.1.0, the firewalld "libvirt" zone did not
|
||||
exist, and prior to firewalld 0.7.0 a feature crucial to making
|
||||
the "libvirt" zone operate properly (rich rule priority
|
||||
settings) was not implemented in firewalld. In cases where one
|
||||
or the other of the two packages is missing the necessary
|
||||
functionality, it's still possible to have functional guest
|
||||
networking by setting the firewalld backend to "iptables" (in
|
||||
firewalld prior to 0.6.0, this was the only backend available).
|
||||
</p>
|
||||
|
||||
<h3><a id="fw-network-filter-driver">The network filter driver</a>
|
||||
</h3>
|
||||
<p>This driver provides a fully configurable network filtering capability
|
||||
that leverages ebtables, iptables and ip6tables. This was written by
|
||||
the libvirt guys at IBM and although its XML schema is defined by libvirt,
|
||||
the conceptual model is closely aligned with the DMTF CIM schema for
|
||||
network filtering:
|
||||
</p>
|
||||
<p><a href="http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf">http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf</a></p>
|
||||
<p>The filters are managed in libvirt as a top level, standalone object.
|
||||
This allows the filters to then be referenced by any libvirt object
|
||||
that requires their functionality, instead tying them only to use
|
||||
by guest NICs. In the current implementation, filters can be associated
|
||||
with individual guest NICs via the libvirt domain XML format. In the
|
||||
future we might allow filters to be associated with the virtual network
|
||||
objects. Further we're expecting to define a new 'virtual switch' object
|
||||
to remove the complexity of configuring bridge/sriov/vepa networking
|
||||
modes. This make also end up making use of network filters.
|
||||
</p>
|
||||
<p>There are a new set of virsh commands for managing network filters:</p>
|
||||
<ul>
|
||||
<li>virsh nwfilter-define
|
||||
<br /><br />
|
||||
define or update a network filter from an XML file
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>virsh nwfilter-undefine
|
||||
<br /><br />
|
||||
undefine a network filter
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>virsh nwfilter-dumpxml
|
||||
<br /><br />
|
||||
network filter information in XML
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>virsh nwfilter-list
|
||||
<br /><br />
|
||||
list network filters
|
||||
<br /><br />
|
||||
</li>
|
||||
<li>virsh nwfilter-edit
|
||||
<br /><br />
|
||||
edit XML configuration for a network filter
|
||||
</li>
|
||||
</ul>
|
||||
<p>There are equivalently named C APIs for each of these commands.</p>
|
||||
<p>As with all objects libvirt manages, network filters are configured
|
||||
using an XML format. At a high level the format looks like this:
|
||||
</p>
|
||||
<pre>
|
||||
<filter name='no-spamming' chain='XXXX'>
|
||||
<uuid>d217f2d7-5a04-0e01-8b98-ec2743436b74</uuid>
|
||||
|
||||
<rule ...>
|
||||
....
|
||||
</rule>
|
||||
|
||||
<filterref filter='XXXX'/>
|
||||
</filter></pre>
|
||||
<p>Every filter has a name and UUID which serve as unique identifiers.
|
||||
A filter can have zero-or-more <code><rule></code> elements which
|
||||
are used to actually define network controls. Filters can be arranged
|
||||
into a DAG, so zero-or-more <code><filterref/></code> elements are
|
||||
also allowed. Cycles in the graph are not allowed.
|
||||
</p>
|
||||
<p>The <code><rule></code> element is where all the interesting stuff
|
||||
happens. It has three attributes, an action, a traffic direction and an
|
||||
optional priority. E.g.:
|
||||
</p>
|
||||
<pre><rule action='drop' direction='out' priority='500'></pre>
|
||||
<p>Within the rule there are a wide variety of elements allowed, which
|
||||
do protocol specific matching. Supported protocols currently include
|
||||
<code>mac</code>, <code>arp</code>, <code>rarp</code>, <code>ip</code>,
|
||||
<code>ipv6</code>, <code>tcp/ip</code>, <code>icmp/ip</code>,
|
||||
<code>igmp/ip</code>, <code>udp/ip</code>, <code>udplite/ip</code>,
|
||||
<code>esp/ip</code>, <code>ah/ip</code>, <code>sctp/ip</code>,
|
||||
<code>tcp/ipv6</code>, <code>icmp/ipv6</code>, <code>igmp/ipv6</code>,
|
||||
<code>udp/ipv6</code>, <code>udplite/ipv6</code>, <code>esp/ipv6</code>,
|
||||
<code>ah/ipv6</code>, <code>sctp/ipv6</code>. Each protocol defines what
|
||||
is valid inside the <rule> element. The general pattern though is:
|
||||
</p>
|
||||
<pre>
|
||||
<protocol match='yes|no' attribute1='value1' attribute2='value2'/></pre>
|
||||
<p>So, eg a TCP protocol, matching ports 0-1023 would be expressed as:</p>
|
||||
<pre><tcp match='yes' srcportstart='0' srcportend='1023'/></pre>
|
||||
<p>Attributes can included references to variables defined by the
|
||||
object using the rule. So the guest XML format allows each NIC
|
||||
to have a MAC address and IP address defined. These are made
|
||||
available to filters via the variables <code><b>$IP</b></code> and
|
||||
<code><b>$MAC</b></code>.
|
||||
</p>
|
||||
<p>So to define a filter that prevents IP address spoofing we can
|
||||
simply match on source IP address <code>!= $IP</code> like this:
|
||||
</p>
|
||||
<pre>
|
||||
<filter name='no-ip-spoofing' chain='ipv4'>
|
||||
<rule action='drop' direction='out'>
|
||||
<ip match='no' srcipaddr='<b>$IP</b>' />
|
||||
</rule>
|
||||
</filter></pre>
|
||||
<p>I'm not going to go into details on all the other protocol
|
||||
matches you can do, because it'll take far too much space.
|
||||
You can read about the options
|
||||
<a href="formatnwfilter.html#nwfelemsRulesProto">here</a>.
|
||||
</p>
|
||||
<p>Out of the box in RHEL6/Fedora rawhide, libvirt ships with a
|
||||
set of default useful rules:
|
||||
</p>
|
||||
<pre>
|
||||
# virsh nwfilter-list
|
||||
UUID Name
|
||||
----------------------------------------------------------------
|
||||
15b1ab2b-b1ac-1be2-ed49-2042caba4abb allow-arp
|
||||
6c51a466-8d14-6d11-46b0-68b1a883d00f allow-dhcp
|
||||
7517ad6c-bd90-37c8-26c9-4eabcb69848d allow-dhcp-server
|
||||
3d38b406-7cf0-8335-f5ff-4b9add35f288 allow-incoming-ipv4
|
||||
5ff06320-9228-2899-3db0-e32554933415 allow-ipv4
|
||||
db0b1767-d62b-269b-ea96-0cc8b451144e clean-traffic
|
||||
f88f1932-debf-4aa1-9fbe-f10d3aa4bc95 no-arp-spoofing
|
||||
772f112d-52e4-700c-0250-e178a3d91a7a no-ip-multicast
|
||||
7ee20370-8106-765d-f7ff-8a60d5aaf30b no-ip-spoofing
|
||||
d5d3c490-c2eb-68b1-24fc-3ee362fc8af3 no-mac-broadcast
|
||||
fb57c546-76dc-a372-513f-e8179011b48a no-mac-spoofing
|
||||
dba10ea7-446d-76de-346f-335bd99c1d05 no-other-l2-traffic
|
||||
f5c78134-9da4-0c60-a9f0-fb37bc21ac1f no-other-rarp-traffic
|
||||
7637e405-4ccf-42ac-5b41-14f8d03d8cf3 qemu-announce-self
|
||||
9aed52e7-f0f3-343e-fe5c-7dcb27b594e5 qemu-announce-self-rarp</pre>
|
||||
<p>Most of these are just building blocks. The interesting one here
|
||||
is 'clean-traffic'. This pulls together all the building blocks
|
||||
into one filter that you can then associate with a guest NIC.
|
||||
This stops the most common bad things a guest might try, IP
|
||||
spoofing, arp spoofing and MAC spoofing. To look at the rules for
|
||||
any of these just do:
|
||||
</p>
|
||||
<pre>virsh nwfilter-dumpxml FILTERNAME|UUID</pre>
|
||||
<p>They are all stored in <code>/etc/libvirt/nwfilter</code>, but don't
|
||||
edit the files there directly. Use <code>virsh nwfilter-define</code>
|
||||
to update them. This ensures the guests have their iptables/ebtables
|
||||
rules recreated.
|
||||
</p>
|
||||
<p>To associate the clean-traffic filter with a guest, edit the
|
||||
guest XML config and change the <code><interface></code> element
|
||||
to include a <code><filterref></code> and also specify the
|
||||
whitelisted <code><ip address/></code> the guest is allowed to
|
||||
use:
|
||||
</p>
|
||||
<pre>
|
||||
<interface type='bridge'>
|
||||
<mac address='52:54:00:56:44:32'/>
|
||||
<source bridge='br1'/>
|
||||
<ip address='10.33.8.131'/>
|
||||
<target dev='vnet0'/>
|
||||
<model type='virtio'/>
|
||||
<filterref filter='clean-traffic'/>
|
||||
</interface></pre>
|
||||
<p>If no <code><ip address></code> is included, the network filter
|
||||
driver will activate its 'learning mode'. This uses libpcap to snoop on
|
||||
network traffic the guest sends and attempts to identify the
|
||||
first IP address it uses. It then locks traffic to this address.
|
||||
Obviously this isn't entirely secure, but it does offer some
|
||||
protection against the guest being trojaned once up and running.
|
||||
In the future we intend to enhance the learning mode so that it
|
||||
looks for DHCPOFFERS from a trusted DHCP server and only allows
|
||||
the offered IP address to be used.
|
||||
</p>
|
||||
<p>Now, how is all this implemented...?</p>
|
||||
<p>The network filter driver uses a combination of ebtables, iptables and
|
||||
ip6tables, depending on which protocols are referenced in a filter. The
|
||||
out of the box 'clean-traffic' filter rules only require use of
|
||||
ebtables. If you want to do matching at tcp/udp/etc protocols (eg to add
|
||||
a new filter 'no-email-spamming' to block port 25), then iptables will
|
||||
also be used.
|
||||
</p>
|
||||
<p>The driver attempts to keep its rules separate from those that
|
||||
the host admin might already have configured. So the first thing
|
||||
it does with ebtables, is to add two hooks in POSTROUTING and
|
||||
PREROUTING chains, to redirect traffic to custom chains. These
|
||||
hooks match on the TAP device name of the guest NIC, so they
|
||||
should not interact badly with any administrator defined rules:
|
||||
</p>
|
||||
<pre>
|
||||
Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
|
||||
-i vnet0 -j libvirt-I-vnet0
|
||||
|
||||
Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
|
||||
-o vnet0 -j libvirt-O-vnet0</pre>
|
||||
<p>To keep things manageable and easy to follow, the driver will then
|
||||
create further sub-chains for each protocol then it needs to match
|
||||
against:
|
||||
</p>
|
||||
<pre>
|
||||
Bridge chain: libvirt-I-vnet0, entries: 5, policy: ACCEPT
|
||||
-p IPv4 -j I-vnet0-ipv4
|
||||
-p ARP -j I-vnet0-arp
|
||||
-p 0x8035 -j I-vnet0-rarp
|
||||
-p 0x835 -j ACCEPT
|
||||
-j DROP
|
||||
|
||||
Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
|
||||
-p IPv4 -j O-vnet0-ipv4
|
||||
-p ARP -j O-vnet0-arp
|
||||
-p 0x8035 -j O-vnet0-rarp
|
||||
-j DROP</pre>
|
||||
<p>Finally, here comes the actual implementation of the filters. This
|
||||
example shows the 'clean-traffic' filter implementation.
|
||||
I'm not going to explain what this is doing now. :-)
|
||||
</p>
|
||||
<pre>
|
||||
Bridge chain: I-vnet0-ipv4, entries: 2, policy: ACCEPT
|
||||
-s ! 52:54:0:56:44:32 -j DROP
|
||||
-p IPv4 --ip-src ! 10.33.8.131 -j DROP
|
||||
|
||||
Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
|
||||
-j ACCEPT
|
||||
|
||||
Bridge chain: I-vnet0-arp, entries: 6, policy: ACCEPT
|
||||
-s ! 52:54:0:56:44:32 -j DROP
|
||||
-p ARP --arp-mac-src ! 52:54:0:56:44:32 -j DROP
|
||||
-p ARP --arp-ip-src ! 10.33.8.131 -j DROP
|
||||
-p ARP --arp-op Request -j ACCEPT
|
||||
-p ARP --arp-op Reply -j ACCEPT
|
||||
-j DROP
|
||||
|
||||
Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT
|
||||
-p ARP --arp-op Reply --arp-mac-dst ! 52:54:0:56:44:32 -j DROP
|
||||
-p ARP --arp-ip-dst ! 10.33.8.131 -j DROP
|
||||
-p ARP --arp-op Request -j ACCEPT
|
||||
-p ARP --arp-op Reply -j ACCEPT
|
||||
-j DROP
|
||||
|
||||
Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT
|
||||
-p 0x8035 -s 52:54:0:56:44:32 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
|
||||
-j DROP
|
||||
|
||||
Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT
|
||||
-p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
|
||||
-j DROP</pre>
|
||||
<p>NB, we would have liked to include the prefix 'libvirt-' in all
|
||||
of our chain names, but unfortunately the kernel limits names
|
||||
to a very short maximum length. So only the first two custom
|
||||
chains can include that prefix. The others just include the
|
||||
TAP device name + protocol name.
|
||||
</p>
|
||||
<p>If I define a new filter 'no-spamming' and then add this to the
|
||||
'clean-traffic' filter, I can illustrate how iptables usage works:
|
||||
</p>
|
||||
<pre>
|
||||
# cat > /root/spamming.xml <<EOF
|
||||
<filter name='no-spamming' chain='root'>
|
||||
<uuid>d217f2d7-5a04-0e01-8b98-ec2743436b74</uuid>
|
||||
<rule action='drop' direction='out' priority='500'>
|
||||
<tcp dstportstart='25' dstportend='25'/>
|
||||
</rule>
|
||||
</filter>
|
||||
EOF
|
||||
# virsh nwfilter-define /root/spamming.xml
|
||||
# virsh nwfilter-edit clean-traffic</pre>
|
||||
|
||||
<p>...add <code><filterref filter='no-spamming'/></code></p>
|
||||
<p>All active guests immediately have their iptables/ebtables rules
|
||||
rebuilt.
|
||||
</p>
|
||||
<p>The network filter driver deals with iptables in a very similar
|
||||
way. First it separates out its rules from those the admin may
|
||||
have defined, by adding a couple of hooks into the INPUT/FORWARD
|
||||
chains:
|
||||
</p>
|
||||
<pre>
|
||||
Chain INPUT (policy ACCEPT 13M packets, 21G bytes)
|
||||
target prot opt in out source destination
|
||||
libvirt-host-in all -- * * 0.0.0.0/0 0.0.0.0/0
|
||||
|
||||
Chain FORWARD (policy ACCEPT 5532K packets, 3010M bytes)
|
||||
target prot opt in out source destination
|
||||
libvirt-in all -- * * 0.0.0.0/0 0.0.0.0/0
|
||||
libvirt-out all -- * * 0.0.0.0/0 0.0.0.0/0
|
||||
libvirt-in-post all -- * * 0.0.0.0/0 0.0.0.0/0</pre>
|
||||
<p>These custom chains then do matching based on the TAP device
|
||||
name, so they won't open holes in the admin defined matches for
|
||||
the LAN/WAN (if any).
|
||||
</p>
|
||||
<pre>
|
||||
Chain libvirt-host-in (1 references)
|
||||
target prot opt in out source destination
|
||||
HI-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-in vnet0
|
||||
|
||||
Chain libvirt-in (1 references)
|
||||
target prot opt in out source destination
|
||||
FI-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-in vnet0
|
||||
|
||||
Chain libvirt-in-post (1 references)
|
||||
target prot opt in out source destination
|
||||
ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vnet0
|
||||
|
||||
Chain libvirt-out (1 references)
|
||||
target prot opt in out source destination
|
||||
FO-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-out vnet0</pre>
|
||||
<p>Finally, we can see the interesting bit which is the actual
|
||||
implementation of my filter to block port 25 access:
|
||||
</p>
|
||||
<pre>
|
||||
Chain FI-vnet0 (1 references)
|
||||
target prot opt in out source destination
|
||||
DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
|
||||
|
||||
Chain FO-vnet0 (1 references)
|
||||
target prot opt in out source destination
|
||||
DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:25
|
||||
|
||||
Chain HI-vnet0 (1 references)
|
||||
target prot opt in out source destination
|
||||
DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25</pre>
|
||||
<p>One thing in looking at this you may notice is that if there
|
||||
are many guests all using the same filters, we will be duplicating
|
||||
the iptables rules over and over for each guest. This is merely a
|
||||
limitation of the current rules engine implementation. At the libvirt
|
||||
object modelling level you can clearly see we've designed the model
|
||||
so filter rules are defined in one place, and indirectly referenced
|
||||
by guests. Thus it should be possible to change the implementation in
|
||||
the future so we can share the actual iptables/ebtables rules for
|
||||
each guest to create a more scalable system. The stuff in current libvirt
|
||||
is more or less the very first working implementation we've had of this,
|
||||
so there's not been much optimization work done yet.
|
||||
</p>
|
||||
<p>Also notice that at the XML level we don't expose the fact we
|
||||
are using iptables or ebtables at all. The rule definition is done in
|
||||
terms of network protocols. Thus if we ever find a need, we could
|
||||
plug in an alternative implementation that calls out to a different
|
||||
firewall implementation instead of ebtables/iptables (providing that
|
||||
implementation was suitably expressive of course)
|
||||
</p>
|
||||
<p>Finally, in terms of problems we have in deployment. The biggest
|
||||
problem is that if the admin does <code>service iptables restart</code>
|
||||
all our work gets blown away. We've experimented with using lokkit
|
||||
to record our custom rules in a persistent config file, but that
|
||||
caused different problem. Admins who were not using lokkit for
|
||||
their config found that all their own rules got blown away. So
|
||||
we threw away our lokkit code. Instead we document that if you
|
||||
run <code>service iptables restart</code>, you need to send SIGHUP to
|
||||
libvirt to make it recreate its rules.
|
||||
</p>
|
||||
<p>More in depth documentation on this is <a href="formatnwfilter.html">here</a>.</p>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,104 +0,0 @@
|
||||
=======
|
||||
License
|
||||
=======
|
||||
|
||||
Copyright (C) 2015 Red Hat, Inc.,
|
||||
|
||||
This Font Software is licensed under the SIL Open Font License, Version 1.1.
|
||||
This license is copied below, and is also available with a FAQ at:
|
||||
|
||||
http://scripts.sil.org/OFL
|
||||
|
||||
|
||||
=====================
|
||||
SIL OPEN FONT LICENSE
|
||||
=====================
|
||||
|
||||
Version 1.1 - 26 February 2007
|
||||
|
||||
PREAMBLE
|
||||
========
|
||||
|
||||
The goals of the Open Font License (OFL) are to stimulate worldwide development
|
||||
of collaborative font projects, to support the font creation efforts of
|
||||
academic and linguistic communities, and to provide a free and open framework
|
||||
in which fonts may be shared and improved in partnership with others.
|
||||
|
||||
The OFL allows the licensed fonts to be used, studied, modified and
|
||||
redistributed freely as long as they are not sold by themselves. The fonts,
|
||||
including any derivative works, can be bundled, embedded, redistributed and/or
|
||||
sold with any software provided that any reserved names are not used by
|
||||
derivative works. The fonts and derivatives, however, cannot be released under
|
||||
any other type of license. The requirement for fonts to remain under this
|
||||
license does not apply to any document created using the fonts or their
|
||||
derivatives.
|
||||
|
||||
DEFINITIONS
|
||||
===========
|
||||
|
||||
“Font Software” refers to the set of files released by the Copyright Holder(s)
|
||||
under this license and clearly marked as such. This may include source files,
|
||||
build scripts and documentation.
|
||||
|
||||
“Reserved Font Name” refers to any names specified as such after the copyright
|
||||
statement(s).
|
||||
|
||||
“Original Version” refers to the collection of Font Software components as
|
||||
distributed by the Copyright Holder(s).
|
||||
|
||||
“Modified Version” refers to any derivative made by adding to, deleting, or
|
||||
substituting—in part or in whole—any of the components of the Original Version,
|
||||
by changing formats or by porting the Font Software to a new environment.
|
||||
|
||||
“Author” refers to any designer, engineer, programmer, technical writer or
|
||||
other person who contributed to the Font Software.
|
||||
|
||||
PERMISSION & CONDITIONS
|
||||
=======================
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
the Font Software, to use, study, copy, merge, embed, modify, redistribute, and
|
||||
sell modified and unmodified copies of the Font Software, subject to the
|
||||
following conditions:
|
||||
|
||||
1) Neither the Font Software nor any of its individual components, in Original
|
||||
or Modified Versions, may be sold by itself.
|
||||
|
||||
2) Original or Modified Versions of the Font Software may be bundled,
|
||||
redistributed and/or sold with any software, provided that each copy contains
|
||||
the above copyright notice and this license. These can be included either as
|
||||
stand-alone text files, human-readable headers or in the appropriate machine-
|
||||
readable metadata fields within text or binary files as long as those fields
|
||||
can be easily viewed by the user.
|
||||
|
||||
3) No Modified Version of the Font Software may use the Reserved Font Name(s)
|
||||
unless explicit written permission is granted by the corresponding Copyright
|
||||
Holder. This restriction only applies to the primary font name as presented to
|
||||
the users.
|
||||
|
||||
4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software
|
||||
shall not be used to promote, endorse or advertise any Modified Version, except
|
||||
to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s)
|
||||
or with their explicit written permission.
|
||||
|
||||
5) The Font Software, modified or unmodified, in part or in whole, must be
|
||||
distributed entirely under this license, and must not be distributed under any
|
||||
other license. The requirement for fonts to remain under this license does not
|
||||
apply to any document created using the Font Software.
|
||||
|
||||
TERMINATION
|
||||
===========
|
||||
|
||||
This license becomes null and void if any of the above conditions are not met.
|
||||
|
||||
DISCLAIMER
|
||||
==========
|
||||
|
||||
THE FONT SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT,
|
||||
TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR
|
||||
ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL,
|
||||
INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF
|
||||
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE
|
||||
THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user