Browse Source

libvirt Debian release 8.5.0-1

-----BEGIN PGP SIGNATURE-----
 
 iQJDBAABCgAtFiEEO48t9niVypx3EjLf954fxUKFg6wFAmLUMpMPHGVvZkBraXl1
 a28ub3JnAAoJEPeeH8VChYOsifIQALR2KxOE/f8c63Lm4f5ncc8hI/ecfMQ6h0G/
 hI0wPdZgSL9d205TbquXjwYPt9zPOSysbGAw+mBPcNztvVhMYzGADaU+O4Vvc7pw
 L6MioSivy3HFQgJGXs6Ddkk3oV31tuHW8FcmGUGLQMrBapMFnW4XgYtB2xTs1qTl
 eUe9MvfLm2k05UeezpwlX+hEKV7rdEg+9NVGBCGf5ptRVhULZ1r9d1CFApH7rXaF
 EFbbzV140v9skr7XhM8kmh4Jt3xpSR0ZYk58ZBNclzWbnOSUdZkds6ka5Gyb2fpg
 wEM0m3Ur8d0afvWkDWH5dwscc0t+WGW1MgV1+x5wXjQbtw/uvXu2NFDClgMeBS4c
 saFfL3swCBJFBccdK2QcamSHbgLMQAO1syDkTuQQ4VIHPXipsqOL4rNupafUNGB5
 72aW+Z/7Lc6HRHPpeAwJCkfYU+B4UMhuwDs2PVlThAp2tXa+Ek9ddWdA2TnTJk6X
 E8TKPMeZCe+nwvMs+0MoGFazvQVzB8TFPqRSd6l1CJ+ejll/F+UaQtHz6k5URysK
 BOewyvzf2dduLFzUvl2MsYiY/6gLjs+Koi91k8HxkYcd/xPMEybEXcam1XCoFmdz
 LPZP+1umDH3/24N0y42liBDahjVw/5pX375eIXJT0jff+cBYJFQCKGsCuzIEvPP6
 iT4vol2H
 =ASV8
 -----END PGP SIGNATURE-----

Merge tag 'debian/8.5.0-1'

libvirt Debian release 8.5.0-1
master
Andreas Messer 6 months ago
parent
commit
b3ab7df815
  1. 6
      AUTHORS.rst
  2. 68
      NEWS.rst
  3. 7
      build-aux/syntax-check.mk
  4. 10
      debian/changelog
  5. 10
      debian/control
  6. 3
      debian/libvirt-daemon-config-network.postinst
  7. 3
      debian/libvirt-daemon-config-network.postrm
  8. 3
      debian/libvirt-daemon-config-nwfilter.postinst
  9. 3
      debian/libvirt-daemon-config-nwfilter.postrm
  10. 6
      debian/libvirt-daemon-system-sysv.lintian-overrides
  11. 1
      debian/libvirt-daemon-system.links
  12. 8
      debian/libvirt-daemon-system.lintian-overrides
  13. 1
      debian/libvirt0.install
  14. 5
      debian/libvirt0.symbols
  15. 4
      debian/patches/debian/Use-sensible-editor-by-default.patch
  16. 4
      debian/patches/forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch
  17. 4
      debian/patches/forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch
  18. 2
      debian/patches/forward/Skip-vircgrouptest.patch
  19. 2
      docs/api.rst
  20. 2
      docs/bindings.rst
  21. 14
      docs/contact.rst
  22. 2
      docs/docs.rst
  23. 2
      docs/drvlxc.rst
  24. 6
      docs/formatbackup.rst
  25. 10
      docs/formatcaps.rst
  26. 2
      docs/formatcheckpoint.rst
  27. 459
      docs/formatdomain.rst
  28. 20
      docs/formatdomaincaps.rst
  29. 8
      docs/formatnetwork.rst
  30. 4
      docs/formatnetworkport.rst
  31. 2
      docs/formatnode.rst
  32. 12
      docs/formatsecret.rst
  33. 8
      docs/formatsnapshot.rst
  34. 2
      docs/formatstorageencryption.rst
  35. 12
      docs/kbase/domainstatecapture.rst
  36. 2
      docs/kbase/internals/eventloop.rst
  37. 2
      docs/kbase/internals/migration.rst
  38. 16
      docs/kbase/internals/rpc.rst
  39. 10
      docs/kbase/kvm-realtime.rst
  40. 6
      docs/kbase/launch_security_sev.rst
  41. 2
      docs/kbase/locking-sanlock.rst
  42. 2
      docs/kbase/memorydevices.rst
  43. 2
      docs/kbase/s390_protected_virt.rst
  44. 8
      docs/kbase/tlscerts.rst
  45. 181
      docs/manpages/virsh.rst
  46. 11
      docs/meson.build
  47. 2
      docs/page.xsl
  48. 4
      docs/remote.rst
  49. 6
      docs/storage.rst
  50. 2
      docs/submitting-patches.rst
  51. 4
      docs/uri.rst
  52. 3
      examples/c/misc/event-test.c
  53. 59
      include/libvirt/libvirt-domain.h
  54. 5
      libvirt.spec
  55. 3
      libvirt.spec.in
  56. 2
      meson.build
  57. 1
      po/LINGUAS
  58. 318
      po/as.po
  59. 270
      po/bg.po
  60. 304
      po/bn_IN.po
  61. 258
      po/bs.po
  62. 270
      po/ca.po
  63. 318
      po/cs.po
  64. 263
      po/da.po
  65. 318
      po/de.po
  66. 250
      po/el.po
  67. 318
      po/en_GB.po
  68. 316
      po/es.po
  69. 269
      po/fi.po
  70. 285
      po/fr.po
  71. 318
      po/gu.po
  72. 311
      po/hi.po
  73. 263
      po/hu.po
  74. 270
      po/id.po
  75. 290
      po/it.po
  76. 323
      po/ja.po
  77. 37364
      po/ka.po
  78. 324
      po/kn.po
  79. 370
      po/ko.po
  80. 18670
      po/libvirt.pot
  81. 263
      po/mk.po
  82. 319
      po/ml.po
  83. 318
      po/mr.po
  84. 251
      po/ms.po
  85. 258
      po/nb.po
  86. 301
      po/nl.po
  87. 312
      po/or.po
  88. 318
      po/pa.po
  89. 301
      po/pl.po
  90. 270
      po/pt.po
  91. 319
      po/pt_BR.po
  92. 353
      po/ru.po
  93. 242
      po/si.po
  94. 270
      po/sr.po
  95. 270
      po/sr@latin.po
  96. 1389
      po/sv.po
  97. 322
      po/ta.po
  98. 312
      po/te.po
  99. 242
      po/tr.po
  100. 324
      po/uk.po

6
AUTHORS.rst

@ -485,6 +485,7 @@ Patches have also been contributed by:
* Lin Ma <morecache@gmail.com>
* Lincoln Myers <lincoln_myers@yahoo.com>
* Liu Dayu <liu.dayu@zte.com.cn>
* Liu Yiding <liuyd.fnst@fujitsu.com>
* Liuji (Jeremy) <jeremy.liu@huawei.com>
* Lorin Hochstein <lorin@isi.edu>
* Lubomir Rintel <lkundrak@v3.sk>
@ -511,6 +512,7 @@ Patches have also been contributed by:
* Marian Neagul <marian@info.uvt.ro>
* Mark Asselstine <mark.asselstine@windriver.com>
* Mark McLoughlin <markmc@redhat.com>
* Mark Mielke <mark.mielke@gmail.com>
* Mark Wu <dwu@redhat.com>
* Marko Myllynen <myllynen@redhat.com>
* Markus Groß <gross@univention.de>
@ -628,6 +630,7 @@ Patches have also been contributed by:
* Pavel Timofeev <timp87@gmail.com>
* Paweł Krześniak <pawel.krzesniak@gmail.com>
* Peng Liang <liangpeng10@huawei.com>
* Peng Liang <tcx4c70@gmail.com>
* Peng Zhou <ailvpeng25@gmail.com>
* Peter Chubb <Peter.Chubb@data61.csiro.au>
* Peter Feiner <peter@gridcentric.ca>
@ -708,6 +711,7 @@ Patches have also been contributed by:
* SeongHyun Jo <caelus9536@gmail.com>
* Serge E. Hallyn <serge.hallyn@canonical.com>
* Serge Hallyn <serge.hallyn@ubuntu.com>
* Sergey A <sw@atrus.ru>
* Sergey Bronnikov <sergeyb@openvz.org>
* Sergey Fionov <fionov@gmail.com>
* Shahar Klein <shaharklein@yahoo.com>
@ -764,6 +768,7 @@ Patches have also been contributed by:
* Tang Chen <tangchen@cn.fujitsu.com>
* Taowei <uaedante@gmail.com>
* Taowei Luo <uaedante@gmail.com>
* Temuri Doghonadze <temuri.doghonadze@gmail.com>
* Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
* Thang Pham <thang.pham@us.ibm.com>
* Thibault VINCENT <thibault.vincent@smartjog.com>
@ -835,6 +840,7 @@ Patches have also been contributed by:
* Xu He Jie <xuhj@linux.vnet.ibm.com>
* Xu Yandong <xuyandong2@huawei.com>
* Xuesong Zhang <xuzhang@redhat.com>
* Yalan Zhang <yalzhang@redhat.com>
* Yalei Li <274268859@qq.com>
* Yan Fu <yafu@redhat.com>
* Yan Wang <wangyan122@huawei.com>

68
NEWS.rst

@ -8,6 +8,74 @@ the changes introduced by each of them.
For a more fine-grained view, use the `git log`_.
v8.5.0 (2022-07-01)
===================
* **New features**
* qemu: Introduce support for network backed NVRAM
Users can now use remote store NVRAM image by specifying newly introduced
attribute `type='network'` with `<nvram>` element.
* qemu: Add support for post-copy migration recovery
A new ``VIR_MIGRATE_POSTCOPY_RESUME`` flag (``virsh migrate --postcopy-resume``)
was introduced for recovering from a failed post-copy migration.
* Introduce thread_pool_min and thread_pool_max attributes to IOThread
New attributes ``thread_pool_min`` and ``thread_pool_max`` were introduced
to ``<iothread/>`` as well as new ``<defaultiothread/>`` element with the
same attributes. This way it's possible to instruct QEMU to spawn enough
worker threads for an IOThread upfront, resulting in predictable time
needed to process an I/O request.
* **Improvements**
* Define a TFTP server without a DHCP server in network configuration
It's now possible to define a network with no DHCP server but with a TFTP
server. This may be useful when DHCP service is provided by other entity on
the network than libvirt spawned dnsmasq.
* **Bug fixes**
* qemu: Restore label to temp file in qemuDomainScreenshot()
When virDomainScreenshot() is called, libvirt instructs QEMU to save the
screenshot into a temporary file. This file needs to be labelled correctly,
so that QEMU can access it. And since the file is temporary (it's deleted
after the screenshot was taken) the corresponding label restore was
missing. This proven to be problematic for profile based models, like
AppArmor, where the temporary files were added into the profile but never
removed, which resulted in longer profile recalculation times.
* qemuBuildInterfaceConnect: Initialize @tapfd array
Due to an uninitialized array, unsuccessful attempt to start a guest with
an ``<interface/>`` might have resulted in closing of a random FD and thus
sudden disconnect of a client or other random failures.
* qemu: Fix hotplug of network interfaces
A logic bug introduced in a recent refactor was fixed. The bug caused a
problem when hot-adding a network interface, which failed with the
following error::
error: internal error: unable to execute QEMU command 'netdev_add': File descriptor named '(null)' has not been found
* Fix ``startupPolicy`` validation for ``block`` disks
Setting of ``startupPolicy`` for a block disk would result in an error due
to a logic bug in a recent refactor.
* qemu: Fix crash when overriding device properties via ``<qemu:override>`` element
Adding an override for a device property would result in a crash of the qemu
driver.
v8.4.0 (2022-06-01)
===================

7
build-aux/syntax-check.mk

@ -1087,6 +1087,13 @@ sc_prohibit_backup_files:
{ echo 'found version controlled backup file' 1>&2; \
exit 1; } || :
# prohibit remote references to local file in RST files
sc_avoid_remote_reference_to_local_file:
@prohibit='<#' \
in_vc_files='\.rst$$' \
halt='use local reference within a file' \
$(_sc_search_regexp)
# This Perl code is slightly obfuscated. Not only is each "$" doubled
# because it's in a Makefile, but the $$c's are comments; we cannot
# use "#" due to the way the script ends up concatenated onto one line.

10
debian/changelog

@ -1,3 +1,13 @@
libvirt (8.5.0-1) unstable; urgency=medium
* [74b9b5c] New upstream version 8.5.0
* [94a98bd] control: Fix cross building
- Explicitly request :native versions of several Build-Depends
* [417c882] control: Bump Standards-Version to 4.6.1
- No changes needed
-- Andrea Bolognani <eof@kiyuko.org> Sun, 17 Jul 2022 17:12:07 +0200
libvirt (8.4.0-1devuan1) unstable; urgency=medium
* Merge Debian release 8.4.0-1

10
debian/control

@ -49,13 +49,13 @@ Build-Depends:
libyajl-dev,
lvm2 [linux-any],
meson (>= 0.54.0~),
nfs-common,
numad [linux-any],
nfs-common:native,
numad:native [linux-any],
open-iscsi [linux-any],
po-debconf,
python3-docutils,
python3:any,
qemu-system-common,
python3:native,
qemu-system-common:native,
qemu-utils,
systemtap-sdt-dev [linux-any],
xsltproc,
@ -63,7 +63,7 @@ Vcs-Browser: https://git.devuan.org/devuan/libvirt
Vcs-Git: https://git.devuan.org/devuan/libvirt.git
Origin: Devuan
Homepage: https://libvirt.org/
Standards-Version: 4.6.0
Standards-Version: 4.6.1
Rules-Requires-Root: no
Package: libvirt-clients

3
debian/libvirt-daemon-config-network.postinst

@ -105,9 +105,6 @@ case "$1" in
# services, restart them so that they can pick up the new settings
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if systemctl is-active -q virtnetworkd; then
systemctl restart virtnetworkd
fi
if systemctl is-active -q libvirtd; then
systemctl restart libvirtd
fi

3
debian/libvirt-daemon-config-network.postrm

@ -55,9 +55,6 @@ case "$1" in
# Since we might have changed the on-disk configuration for some
# services, restart them so that they can pick up the new settings
if [ -d /run/systemd/system ]; then
if systemctl is-active -q virtnetworkd; then
systemctl restart virtnetworkd
fi
if systemctl is-active -q libvirtd; then
systemctl restart libvirtd
fi

3
debian/libvirt-daemon-config-nwfilter.postinst

@ -146,9 +146,6 @@ case "$1" in
# services, restart them so that they can pick up the new settings
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if systemctl is-active -q virtnwfilterd; then
systemctl restart virtnwfilterd
fi
if systemctl is-active -q libvirtd; then
systemctl restart libvirtd
fi

3
debian/libvirt-daemon-config-nwfilter.postrm

@ -94,9 +94,6 @@ case "$1" in
# Since we might have changed the on-disk configuration for some
# services, restart them so that they can pick up the new settings
if [ -d /run/systemd/system ]; then
if systemctl is-active -q virtnwfilterd; then
systemctl restart virtnwfilterd
fi
if systemctl is-active -q libvirtd; then
systemctl restart libvirtd
fi

6
debian/libvirt-daemon-system-sysv.lintian-overrides

@ -1,8 +1,8 @@
# The expected options are all implemented - just not in a way that Lintian
# is capable of recognizing
libvirt-daemon-system-sysv: init.d-script-does-not-implement-required-option etc/init.d/libvirt-guests *
libvirt-daemon-system-sysv: init.d-script-does-not-implement-status-option etc/init.d/libvirt-guests
libvirt-daemon-system-sysv: init.d-script-does-not-source-init-functions etc/init.d/libvirt-guests
libvirt-daemon-system-sysv: init.d-script-does-not-implement-required-option * [etc/init.d/libvirt-guests]
libvirt-daemon-system-sysv: init.d-script-does-not-implement-status-option [etc/init.d/libvirt-guests]
libvirt-daemon-system-sysv: init.d-script-does-not-source-init-functions [etc/init.d/libvirt-guests]
libvirt-daemon-system-sysv: missing-systemd-service-for-init.d-script
# Lintian would like an explicit Pre-Depends on init-system-helpers (>= 1.54~)
# to be declared, but we already know that any version of Debian we might want

1
debian/libvirt-daemon-system.links

@ -1 +0,0 @@
usr/share/doc/libvirt-daemon/README.Debian.gz usr/share/doc/libvirt-daemon-system/README.Debian.gz

8
debian/libvirt-daemon-system.lintian-overrides

@ -1,5 +1,5 @@
# SysV init support is implemented in the libvirt-daemon-system-sysv package
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/libvirt-guests.service
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/libvirtd.service
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/virtlockd.service
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/virtlogd.service
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script [lib/systemd/system/libvirt-guests.service]
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script [lib/systemd/system/libvirtd.service]
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script [lib/systemd/system/virtlockd.service]
libvirt-daemon-system: package-supports-alternative-init-but-no-init.d-script [lib/systemd/system/virtlogd.service]

1
debian/libvirt0.install

@ -128,6 +128,7 @@ usr/share/locale/hu/LC_MESSAGES/libvirt.mo
usr/share/locale/id/LC_MESSAGES/libvirt.mo
usr/share/locale/it/LC_MESSAGES/libvirt.mo
usr/share/locale/ja/LC_MESSAGES/libvirt.mo
usr/share/locale/ka/LC_MESSAGES/libvirt.mo
usr/share/locale/kn/LC_MESSAGES/libvirt.mo
usr/share/locale/ko/LC_MESSAGES/libvirt.mo
usr/share/locale/mk/LC_MESSAGES/libvirt.mo

5
debian/libvirt0.symbols

@ -133,7 +133,8 @@ libvirt.so.0 libvirt0 #MINVER#
*@LIBVIRT_7.8.0 7.9.0
*@LIBVIRT_8.0.0 8.0.0
*@LIBVIRT_8.4.0 8.4.0
*@LIBVIRT_PRIVATE_8.4.0 8.4.0
*@LIBVIRT_8.5.0 8.5.0
*@LIBVIRT_PRIVATE_8.5.0 8.5.0
libvirt-qemu.so.0 libvirt0 #MINVER#
*@LIBVIRT_QEMU_0.8.3 0.8.3
@ -156,4 +157,4 @@ libvirt-admin.so.0 libvirt0 #MINVER#
*@LIBVIRT_ADMIN_1.3.0 1.2.18
*@LIBVIRT_ADMIN_2.0.0 2.0.0~rc1
*@LIBVIRT_ADMIN_3.0.0 3.0.0
*@LIBVIRT_ADMIN_PRIVATE_8.4.0 8.4.0
*@LIBVIRT_ADMIN_PRIVATE_8.5.0 8.5.0

4
debian/patches/debian/Use-sensible-editor-by-default.patch

@ -10,10 +10,10 @@ Forwarded: not-needed
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/vsh.c b/tools/vsh.c
index 499794c..038adb0 100644
index 0066504..e84ea77 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -2435,7 +2435,7 @@ vshEditWriteToTempFile(vshControl *ctl, const char *doc)
@@ -2434,7 +2434,7 @@ vshEditWriteToTempFile(vshControl *ctl, const char *doc)
/* Hard-code default editor used as a fallback if not configured by
* VISUAL or EDITOR environment variables. */

4
debian/patches/forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch

@ -13,10 +13,10 @@ require the 'TERM' environment variable to be set to the terminal type.
1 file changed, 2 insertions(+)
diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index 1af2778..8cb79fe 100644
index 32f506d..830c8d8 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -856,6 +856,8 @@ int virNetSocketNewConnectSSH(const char *nodename,
@@ -855,6 +855,8 @@ int virNetSocketNewConnectSSH(const char *nodename,
virCommandAddEnvPass(cmd, "KRB5CCNAME");
virCommandAddEnvPass(cmd, "SSH_AUTH_SOCK");
virCommandAddEnvPass(cmd, "SSH_ASKPASS");

4
debian/patches/forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch

@ -10,10 +10,10 @@ Closes: #663931
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index 176e2f8..b17f0ac 100644
index 7e246d2..5bb1549 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -1249,7 +1249,7 @@ void virWaitForDevices(void)
@@ -1247,7 +1247,7 @@ void virWaitForDevices(void)
if (!(udev = virFindFileInPath(UDEVADM)))
return;

2
debian/patches/forward/Skip-vircgrouptest.patch

@ -9,7 +9,7 @@ without sysfs mounted.
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/vircgrouptest.c b/tests/vircgrouptest.c
index 7d54df1..83c68c6 100644
index e29bc09..969bed0 100644
--- a/tests/vircgrouptest.c
+++ b/tests/vircgrouptest.c
@@ -20,7 +20,7 @@

2
docs/api.rst

@ -27,7 +27,7 @@ wise thing to do in most cases. See the `connection URI <uri.html>`__
page for a full descriptions of the values allowed.
OnDevice the application obtains a
`virConnectPtr </html/libvirt-libvirt-host.html#virConnectPtr>`__
`virConnectPtr <html/libvirt-libvirt-host.html#virConnectPtr>`__
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

2
docs/bindings.rst

@ -57,6 +57,6 @@ For information on using libvirt on **Windows** `please see the Windows
support page <windows.html>`__.
Support, requests or help for libvirt bindings are welcome on the
`mailing list <https://www.redhat.com/mailman/listinfo/libvir-list/>`__,
`mailing list <https://listman.redhat.com/mailman/listinfo/libvir-list/>`__,
as usual try to provide enough background information and make sure you
use recent version, see the `help page <bugs.html>`__.

14
docs/contact.rst

@ -21,9 +21,9 @@ There are three mailing-lists:
**libvir-list@redhat.com** (for development)
Archives
https://www.redhat.com/archives/libvir-list
https://listman.redhat.com/archives/libvir-list
List info
https://www.redhat.com/mailman/listinfo/libvir-list
https://listman.redhat.com/mailman/listinfo/libvir-list
This is a high volume mailing list. It is a place for discussions about the
**development** of libvirt.
@ -37,9 +37,9 @@ There are three mailing-lists:
**libvirt-users@redhat.com** (for users)
Archives
https://www.redhat.com/archives/libvirt-users
https://listman.redhat.com/archives/libvirt-users
List info
https://www.redhat.com/mailman/listinfo/libvirt-users
https://listman.redhat.com/mailman/listinfo/libvirt-users
This is a moderate volume mailing list. It is a place for discussions
involving libvirt **users**.
@ -53,9 +53,9 @@ There are three mailing-lists:
**libvirt-announce@redhat.com** (for release notices)
Archives
https://www.redhat.com/archives/libvirt-announce
https://listman.redhat.com/archives/libvirt-announce
List info
https://www.redhat.com/mailman/listinfo/libvirt-announce
https://listman.redhat.com/mailman/listinfo/libvirt-announce
This is a low volume mailing list, with restricted posting, for announcements
of new libvirt releases.
@ -80,7 +80,7 @@ Some of the libvirt developers may be found on IRC on the `OFTC
IRC <https://oftc.net>`__ network. Use the settings:
- server: irc.oftc.net
- port: 6667 (the usual IRC port)
- port: 6697 (the usual IRC TLS port)
- channel: #virt
NB There is no guarantee that someone will be watching or able to reply

2
docs/docs.rst

@ -26,7 +26,7 @@ Deployment / operation
`Remote access <remote.html>`__
Enable remote access over TCP
`TLS certs <tlscerts.html>`__
`TLS certs <kbase/tlscerts.html>`__
Generate and deploy x509 certificates for TLS
`Authentication <auth.html>`__

2
docs/drvlxc.rst

@ -37,7 +37,7 @@ In order to separate processes inside a container from those in the primary
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 `UID or GID mapping <formatdomain.html#elementsOSContainer>`__, the
declares a `UID or GID mapping <formatdomain.html#container-boot>`__, the
'user' namespace will be enabled to apply these. **A suitably configured UID/GID
mapping is a pre-requisite to making containers secure, in the absence of sVirt
confinement.**

6
docs/formatbackup.rst

@ -37,7 +37,7 @@ were supplied). The following child elements and attributes are supported:
``server``
Present only for a pull mode backup. Contains the same attributes as the
```protocol`` element of a disk <formatdomain.html#elementsDisks>`__ attached
```protocol`` element of a disk <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ attached
via NBD in the domain (such as transport, socket, name, port, or tls),
necessary to set up an NBD server that exposes the content of each disk at
the time the backup is started.
@ -61,7 +61,7 @@ were supplied). The following child elements and attributes are supported:
``name``
A mandatory attribute which must match the ``<target dev='name'/>`` of
one of the `disk devices <formatdomain.html#elementsDisks>`__ specified
one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ specified
for the domain at the time of the checkpoint.
``backup``
@ -122,7 +122,7 @@ were supplied). The following child elements and attributes are supported:
file is not deleted after the backup but the contents of the file don't
make sense outside of the backup. The same applies for the block device
which must be formatted appropriately. Similarly to the domain
```disk`` <formatdomain.html#elementsDisks>`__ definition ``scratch``
```disk`` <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ definition ``scratch``
and ``target`` can contain ``seclabel`` and/or ``encryption``
subelements to configure the corresponding properties.

10
docs/formatcaps.rst

@ -84,20 +84,20 @@ The ``<guest/>`` element will typically wrap up the following elements:
Size of CPU word in bits, for example 64.
``emulator``
Emulator (device model) path, for use in
`emulator <formatdomain.html#elementEmulator>`__ element of domain XML.
`emulator <formatdomain.html#devices>`__ element of domain XML.
``loader``
Loader path, for use in `loader <formatdomain.html#elementLoader>`__
Loader path, for use in `loader <formatdomain.html#bios-bootloader>`__
element of domain XML.
``machine``
Machine type, for use in
`machine <formatdomain.html#attributeOSTypeMachine>`__ attribute of
`machine <formatdomain.html#operating-system-booting>`__ attribute of
os/type element in domain XML. For example Xen supports ``xenfv`` for HVM,
``xenpv`` for PV, or ``xenpvh`` for PVH.
``domain``
The ``type`` attribute of this element specifies the type of hypervisor
required to run the domain. Use in
`type <formatdomain.html#attributeDomainType>`__ attribute of the domain
root element.
`type <formatdomain.html#element-and-attribute-overview>`__ attribute of
the domain root element.
``features``
This optional element encases possible features that can be used with a guest
of described type. Possible subelements are:

2
docs/formatcheckpoint.rst

@ -69,7 +69,7 @@ The top-level ``domaincheckpoint`` element may contain the following elements:
``name``
A mandatory attribute which must match either the
``<target dev='name'/>`` or an unambiguous ``<source file='name'/>`` of
one of the `disk devices <formatdomain.html#elementsDisks>`__ specified
one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ specified
for the domain at the time of the checkpoint.
``checkpoint``

459
docs/formatdomain.rst

File diff suppressed because it is too large

20
docs/formatdomaincaps.rst

@ -18,7 +18,7 @@ more recent to support VFIO, while legacy KVM is achievable just fine with older
qemus.
The main difference between
`virConnectGetCapabilities </html/libvirt-libvirt-host.html#virConnectGetCapabilities>`__
`virConnectGetCapabilities <html/libvirt-libvirt-host.html#virConnectGetCapabilities>`__
and the emulator capabilities API is, the former one aims more on the host
capabilities (e.g. NUMA topology, security models in effect, etc.) while the
latter one specializes on the hypervisor capabilities.
@ -68,14 +68,14 @@ The root element that emulator capability XML document starts with has name
``path``
The full path to the emulator binary.
``domain``
Describes the `virtualization type <formatdomain.html#elements>`__ (or so
Describes the `virtualization type <formatdomain.html#element-and-attribute-overview>`__ (or so
called domain type).
``machine``
The domain's `machine type <formatdomain.html#elementsOSBIOS>`__. Since not
The domain's `machine type <formatdomain.html#bios-bootloader>`__. Since not
every hypervisor has a sense of machine types this element might be omitted
in such drivers.
``arch``
The domain's `architecture <formatdomain.html#elementsOSBIOS>`__.
The domain's `architecture <formatdomain.html#bios-bootloader>`__.
CPU Allocation
~~~~~~~~~~~~~~
@ -98,7 +98,7 @@ BIOS bootloader
~~~~~~~~~~~~~~~
Sometimes users might want to tweak some BIOS knobs or use UEFI. For cases like
that, `os <formatdomain.html#elementsOSBIOS>`__ element exposes what values can
that, `os <formatdomain.html#bios-bootloader>`__ element exposes what values can
be passed to its children.
::
@ -165,7 +165,7 @@ CPU configuration
~~~~~~~~~~~~~~~~~
The ``cpu`` element exposes options usable for configuring `guest
CPUs <formatdomain.html#elementsCPU>`__.
CPUs <formatdomain.html#cpu-model-and-topology>`__.
::
@ -232,7 +232,7 @@ I/O Threads
~~~~~~~~~~~
The ``iothread`` elements indicates whether or not `I/O
threads <formatdomain.html#elementsIOThreadsAllocation>`__ are supported.
threads <formatdomain.html#iothreads-allocation>`__ are supported.
::
@ -527,7 +527,7 @@ each of the elements or attributes. For example, the ``gic`` element has an
attribute ``version`` which can support the values ``2`` or ``3``.
For information about the purpose of each feature, see the `relevant
section <formatdomain.html#elementsFeatures>`__ in the domain XML documentation.
section <formatdomain.html#hypervisor-features>`__ in the domain XML documentation.
GIC capabilities
^^^^^^^^^^^^^^^^
@ -568,7 +568,7 @@ s390-pv capability
Reports whether the hypervisor supports the Protected Virtualization. In order
to use Protected Virtualization with libvirt have a look at the `launchSecurity
element in the domain XML <formatdomain.html#launchSecurity>`__. For more
element in the domain XML <formatdomain.html#launch-security>`__. For more
details on the Protected Virtualization feature please see `Protected
Virtualization on s390 <kbase/s390_protected_virt.html>`__.
@ -583,7 +583,7 @@ transparently encrypted with a key unique to that VM.
For more details on the SEV feature, please follow resources in the AMD
developer's document store. In order to use SEV with libvirt have a look at `SEV
in domain XML <formatdomain.html#launchSecurity>`__
in domain XML <formatdomain.html#launch-security>`__
``cbitpos``
When memory encryption is enabled, one of the physical address bits (aka the

8
docs/formatnetwork.rst

@ -61,7 +61,7 @@ The first elements provide basic metadata about the virtual network.
The optional parameter ``trustGuestRxFilters`` can be used to set that
attribute of the same name for each domain interface connected to this
network ( :since:`since 1.2.10` ). See the `Network
interfaces <formatdomain.html#elementsNICS>`__ section of the domain XML
interfaces <formatdomain.html#network-interfaces>`__ section of the domain XML
documentation for more details. Note that an explicit setting of this
attribute in a portgroup or the individual domain interface will override the
setting in the network.
@ -253,7 +253,7 @@ to the physical LAN (if at all).
interfaces to be used for a "direct" connection via macvtap using
macvtap's "bridge" mode (if the forward element has one or more
``<interface>`` subelements, :since:`Since 0.9.4` ) (see `Direct
attachment to physical interface <formatdomain.html#elementsNICSDirect>`__
attachment to physical interface <formatdomain.html#direct-attachment-to-physical-interface>`__
for descriptions of the various macvtap modes). libvirt doesn't attempt to
manage the bridge interface at all, thus the ``<bridge>`` element's
``stp`` and ``delay`` attributes are not allowed; no iptables rules, IP
@ -599,7 +599,7 @@ as the 'default' portgroup for the network), and each portgroup has a name, as
well as various attributes and subelements associated with it. The currently
supported subelements are ``<bandwidth>`` (described in `Quality of service`_)
and ``<virtualport>`` (documented
`here <formatdomain.html#elementsNICSDirect>`__). If a domain interface
`here <formatdomain.html#direct-attachment-to-physical-interface>`__). If a domain interface
definition specifies a portgroup (by adding a ``portgroup`` attribute to the
``<source>`` subelement), that portgroup's info will be merged into the
interface's configuration. If no portgroup is given in the interface definition,
@ -616,7 +616,7 @@ starting.
portgroups also support the optional parameter ``trustGuestRxFilters`` which can
be used to set that attribute of the same name for each domain interface using
this portgroup ( :since:`since 1.2.10` ). See the `Network
interfaces <formatdomain.html#elementsNICS>`__ section of the domain XML
interfaces <formatdomain.html#network-interfaces>`__ section of the domain XML
documentation for more details. Note that an explicit setting of this attribute
in the portgroup overrides the network-wide setting, and an explicit setting in
the individual domain interface will override the setting in the portgroup.

4
docs/formatnetworkport.rst

@ -98,7 +98,7 @@ The following elements are common to one or more of the plug types listed later
``virtualport``
The ``virtualport`` element describes metadata that needs to be provided to
the underlying network subsystem. It is described in the domain XML
`interface documentation <formatdomain.html#elementsNICS>`__.
`interface documentation <formatdomain.html#network-interfaces>`__.
Plugs
~~~~~
@ -151,7 +151,7 @@ interface.
The ``dev`` attribute provides the name of the physical network interface to
which the port will be connected. The ``mode`` attribute describes how the
connection will be setup and takes the same values described in the `domain
XML <formatdomain.html#elementsNICSDirect>`__.
XML <formatdomain.html#direct-attachment-to-physical-interface>`__.
Host PCI
^^^^^^^^

2
docs/formatnode.rst

@ -12,7 +12,7 @@ Node Device XML
There are several libvirt functions, all with the prefix ``virNodeDevice``,
which deal with management of host devices that can be handed to guests via
passthrough as <hostdev> elements in `the domain
XML <formatdomain.html#elementsHostDev>`__. These devices are represented as a
XML <formatdomain.html#host-device-assignment>`__. These devices are represented as a
hierarchy, where a device on a bus has a parent of the bus controller device;
the root of the hierarchy is the node named "computer".

12
docs/formatsecret.rst

@ -65,7 +65,7 @@ using ``virsh secret-set-value``.
The volume type secret can be supplied either in volume XML during creation of a
`storage volume <formatstorage.html#storage-volume-xml>`__ in order to provide
the passphrase to encrypt the volume or in domain XML
`disk device <formatdomain.html#elementsDisks>`__ in order to provide the
`disk device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ in order to provide the
passphrase to decrypt the volume, :since:`since 2.1.0` . An example follows:
::
@ -101,7 +101,7 @@ This secret is associated with a Ceph RBD (rados block device). The
``<usage type='ceph'>`` element must contain a single ``name`` element that
specifies a usage name for the secret. The Ceph secret can then be used by UUID
or by this usage name via the ``<auth>`` element of a `disk
device <formatdomain.html#elementsDisks>`__ or a `storage pool
device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ or a `storage pool
(rbd) <formatstorage.html>`__. :since:`Since 0.9.7` . The following is an
example of the steps to be taken. First create a ceph-secret.xml file:
@ -132,7 +132,7 @@ See `Setting secret values in virsh`_ on how to set the value of the secret
using ``virsh secret-set-value``.
The ceph secret can then be used by UUID or by the usage name via the ``<auth>``
element in a domain's `<disk> <formatdomain.html#elementsDisks>`__ element as
element in a domain's `<disk> <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ element as
follows:
::
@ -157,7 +157,7 @@ This secret is associated with an iSCSI target for CHAP authentication. The
``<usage type='iscsi'>`` element must contain a single ``target`` element that
specifies a usage name for the secret. The iSCSI secret can then be used by UUID
or by this usage name via the ``<auth>`` element of a `disk
device <formatdomain.html#elementsDisks>`__ or a `storage pool
device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ or a `storage pool
(iscsi) <formatstorage.html>`__. :since:`Since 1.0.4` . The following is an
example of the XML that may be used to generate a secret for iSCSI CHAP
authentication. Assume the following sample entry in an iSCSI authentication
@ -207,7 +207,7 @@ See `Setting secret values in virsh`_ on how to set the value of the secret
using ``virsh secret-set-value``.
The iSCSI secret can then be used by UUID or by the usage name via the
``<auth>`` element in a domain's `<disk> <formatdomain.html#elementsDisks>`__
``<auth>`` element in a domain's `<disk> <formatdomain.html#hard-drives-floppy-disks-cdroms>`__
element as follows:
::
@ -268,7 +268,7 @@ This secret is associated with a virtualized TPM (vTPM) and serves as a
passphrase for deriving a key from for encrypting the state of the vTPM. The
``<usage type='vtpm'>`` element must contain a single ``name`` element that
specifies a usage name for the secret. The vTPM secret can then be used by UUID
via the ``<encryption>`` element of a `tpm <formatdomain.html#elementsTpm>`__
via the ``<encryption>`` element of a `tpm <formatdomain.html#tpm-device>`__
when using an emulator. :since:`Since 5.6.0` . The following is an example of
the steps to be taken. First create a vtpm-secret.xml file:

8
docs/formatsnapshot.rst

@ -115,11 +115,11 @@ The top-level ``domainsnapshot`` element may contain the following elements:
This sub-element describes the snapshot properties of a specific disk.
The attribute ``name`` is mandatory, and must match either the ``<target
dev='name'/>`` (recommended) or an unambiguous ``<source file='name'/>``
of one of the `disk devices <formatdomain.html#elementsDisks>`__
of one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__
specified for the domain at the time of the snapshot. The attribute
``snapshot`` is optional, and the possible values are the same as the
``snapshot`` attribute for `disk devices
<formatdomain.html#elementsDisks>`__ (``no``, ``internal``, or
<formatdomain.html#hard-drives-floppy-disks-cdroms>`__ (``no``, ``internal``, or
``external``). Some hypervisors like ESX require that if specified, the
snapshot mode must not override any snapshot mode attached to the
corresponding domain disk, while others like qemu allow this field to
@ -140,7 +140,7 @@ The top-level ``domainsnapshot`` element may contain the following elements:
overwrite the default ``file`` type. The ``type`` attribute along with
the format of the ``source`` sub-element is identical to the ``source``
element used in domain disk definitions. See the `disk devices
<formatdomain.html#elementsDisks>`__ section documentation for further
<formatdomain.html#hard-drives-floppy-disks-cdroms>`__ section documentation for further
information. Libvirt currently supports the ``type`` element in the qemu
driver and supported values are ``file``, ``block`` and ``network``
:since:`(since 1.2.2)`.
@ -159,7 +159,7 @@ The top-level ``domainsnapshot`` element may contain the following elements:
The ``source`` element also may contain the ``seclabel`` element
(described in the `domain XML documentation
<formatdomain.html#seclabel>`__) which can be used to override the
<formatdomain.html#security-label>`__) which can be used to override the
domain security labeling policy for ``source``.
``driver``

2
docs/formatstorageencryption.rst

@ -107,7 +107,7 @@ to a qemu VM using the qemu VM driver. A single
Examples
--------
Assuming a `luks volume type secret <formatsecret.html#VolumeUsageType>`__ is
Assuming a `luks volume type secret <formatsecret.html#usage-type-volume>`__ is
already defined, a simple example specifying use of the ``luks`` format for
either volume creation without a specific cipher being defined or as part of a
domain volume definition:

12
docs/kbase/domainstatecapture.rst

@ -176,12 +176,12 @@ capture have these properties:
contents are not also saved. Since creating an external snapshot
changes which disk image resource is in use by the guest, this API
can be coupled with
`virDomainBlockCommit() <html/libvirt-libvirt-domain.html#virDomainBlockCommit>`__
`virDomainBlockCommit() <../html/libvirt-libvirt-domain.html#virDomainBlockCommit>`__
to restore things back to the guest using its original disk image,
where a third-party tool can read the backing file prior to the live
commit. See also the `XML details <formatsnapshot.html>`__ used with
commit. See also the `XML details <../formatsnapshot.html>`__ used with
this command.
`virDomainFSFreeze <html/libvirt-libvirt-domain.html#virDomainFSFreeze>`__, `virDomainFSThaw <html/libvirt-libvirt-domain.html#virDomainFSThaw>`__
`virDomainFSFreeze <../html/libvirt-libvirt-domain.html#virDomainFSFreeze>`__, `virDomainFSThaw <../html/libvirt-libvirt-domain.html#virDomainFSThaw>`__
This pair of APIs does not directly capture guest state, but can be
used to coordinate with a trusted live guest that state capture is
about to happen, and therefore guest I/O should be quiesced so that
@ -191,7 +191,7 @@ capture have these properties:
to these functions. Also, note that freezing guest I/O is only
possible with trusted guests running a guest agent, and that some
guests place maximum time limits on how long I/O can be frozen.
`virDomainCheckpointCreateXML <html/libvirt-libvirt-domain-checkpoint.html#virDomainCheckpointCreateXML>`__
`virDomainCheckpointCreateXML <../html/libvirt-libvirt-domain-checkpoint.html#virDomainCheckpointCreateXML>`__
This API does not actually capture guest state, rather it makes it
possible to track which portions of guest disks have changed between
a checkpoint and the current live execution of the guest. However,
@ -201,9 +201,9 @@ capture have these properties:
at the creation of an external snapshot with
``virDomainSnapshotCreateXML2()``, since a second incremental backup
is most useful when using the checkpoint created during the first.
See also the `XML details <formatcheckpoint.html>`__ used with this
See also the `XML details <../formatcheckpoint.html>`__ used with this
command.
`virDomainBackupBegin <html/libvirt-libvirt-domain.html#virDomainBackupBegin>`__, `virDomainBackupEnd <html/libvirt-libvirt-domain.html#virDomainBackupEnd>`__
`virDomainBackupBegin <../html/libvirt-libvirt-domain.html#virDomainBackupBegin>`__
This API wraps approaches for capturing the state of disks of a
running guest, but does not track accompanying guest memory state.
The capture is consistent to the start of the operation, where the

2
docs/kbase/internals/eventloop.rst

@ -47,7 +47,7 @@ To work with event loop from our code we have plenty of APIs.
- ``virEventRemoveTimeout``: Unregisters a timer.
For more information on these APIs continue reading
`here <../html/libvirt-libvirt-event.html>`__.
`here <../../html/libvirt-libvirt-event.html>`__.
Worker pool
-----------

2
docs/kbase/internals/migration.rst

@ -7,7 +7,7 @@ Libvirt migration internals
Migration is a multi-step operation with at least two distinct actors,
the source and the destination libvirtd daemons, and a lot of failure
points. This document describes the basic migration workflow in the
code level, as a way to complement `the base migration docs <../migration.html>`_
code level, as a way to complement `the base migration docs <../../migration.html>`_
and help developers to get up to speed quicker with the code.
In this document, unless stated otherwise, these conventions are followed:

16
docs/kbase/internals/rpc.rst

@ -27,8 +27,8 @@ outstanding method. The protocol was loosely inspired by the design of SunRPC.
The definition of the RPC protocol is in the file ``src/rpc/virnetprotocol.x``
in the libvirt source tree.
`Packet framing <protocolframing>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Packet framing
~~~~~~~~~~~~~~
On the wire, there is no explicit packet framing marker. Instead each packet is
preceded by an unsigned 32-bit integer giving the total length of the packet in
@ -45,8 +45,8 @@ the framing looks like this:
|~ Len ~|~ Data ~|~ Len ~|~ Data ~|~ Len ~|~ Data ~|~
`Packet data <protocoldata>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Packet data
~~~~~~~~~~~
The data in each packet is split into two parts, a short fixed length header,
followed by a variable length payload. So a packet from the illustration above
@ -61,8 +61,8 @@ is more correctly shown as
|~ Len ~|~ Header ~|~ Payload .... ~|
`Packet header <protocolheader>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Packet header
~~~~~~~~~~~~~
The header contains 6 fields, encoded as signed/unsigned 32-bit integers.
@ -119,8 +119,8 @@ The header contains 6 fields, encoded as signed/unsigned 32-bit integers.
#. continue: for streams this indicates that further data packets will be
following
`Packet payload <protocolpayload>`__
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Packet payload
~~~~~~~~~~~~~~
The payload of a packet will vary depending on the ``type`` and ``status``
fields from the header.

10
docs/kbase/kvm-realtime.rst

@ -128,7 +128,7 @@ host core that is in the `isolcpus` reserved set. The QEMU emulator threads
need to be pinned to host CPUs that are not in the `isolcpus` reserved set.
The vCPUs need to be given a real time CPU scheduler policy.
When configuring the `guest CPU count <../formatdomain.html#elementsCPUAllocation>`_,
When configuring the `guest CPU count <../formatdomain.html#cpu-allocation>`_,
do not include any CPU affinity at this stage:
::
@ -137,7 +137,7 @@ do not include any CPU affinity at this stage:
The guest CPUs now need to be placed individually. In this case, they will all
be put within the same host socket, such that they can be exposed as core
siblings. This is achieved using the `CPU tuning config <../formatdomain.html#elementsCPUTuning>`_:
siblings. This is achieved using the `CPU tuning config <../formatdomain.html#cpu-tuning>`_:
::
@ -150,7 +150,7 @@ siblings. This is achieved using the `CPU tuning config <../formatdomain.html#el
<vcpusched vcpus='0-4' scheduler='fifo' priority='1'/>
</cputune>
The `guest CPU model <formatdomain.html#elementsCPU>`_ now needs to be
The `guest CPU model <../formatdomain.html#cpu-model-and-topology>`_ now needs to be
configured to pass through the host model unchanged, with topology matching the
placement:
@ -162,7 +162,7 @@ placement:
</cpu>
The performance monitoring unit virtualization needs to be disabled
via the `hypervisor features <../formatdomain.html#elementsFeatures>`_:
via the `hypervisor features <../formatdomain.html#hypervisor-features>`_:
::
@ -178,7 +178,7 @@ Memory configuration
The host memory used for guest RAM needs to be allocated from huge pages on the
second NUMA node, and all other memory allocation needs to be locked into RAM
with memory page sharing disabled.
This is achieved by using the `memory backing config <formatdomain.html#elementsMemoryBacking>`_:
This is achieved by using the `memory backing config <../formatdomain.html#memory-backing>`_:
::

6
docs/kbase/launch_security_sev.rst

@ -154,7 +154,7 @@ VM Configuration
================
SEV is enabled in the XML by specifying the
`<launchSecurity> <https://libvirt.org/formatdomain.html#launchSecurity>`__
`<launchSecurity> <https://libvirt.org/formatdomain.html#launch-security>`__
element. However, specifying ``launchSecurity`` isn't enough to boot an
SEV VM. Further configuration requirements are discussed below.
@ -295,7 +295,9 @@ In order to make virtio devices work, we need to use
``<driver iommu='on'/>`` inside the given device XML element in order
to enable DMA API in the virtio driver.
::
Starting with QEMU 6.0.0 QEMU will set this for us by default. For earlier
versions though, you will need to explicitly enable this in the device XML as
follows::
# virsh edit <domain>
<domain>

2
docs/kbase/locking-sanlock.rst

@ -173,7 +173,7 @@ Domain configuration
In case sanlock loses access to disk locks for some reason, it will kill
all domains that lost their locks. This default behavior may be changed
using `on_lockfailure element <../formatdomain.html#elementsEvents>`__ in
using `on_lockfailure element <../formatdomain.html#events-configuration>`__ in
domain XML. When this element is present, sanlock will call
``sanlock_helper`` (provided by libvirt) with the specified action. This
helper binary will connect to libvirtd and thus it may need to

2
docs/kbase/memorydevices.rst

@ -79,7 +79,7 @@ Furthermore, DIMMs can have ``<source/>`` element which configures backend for
devices. For NVDIMMs the element is mandatory and reflects where the content
is saved.
See `memory devices documentation <../formatdomain.html#elementsMemory>`_.
See `memory devices documentation <../formatdomain.html#memory-devices>`_.
``virtio-mem`` model
====================

2
docs/kbase/s390_protected_virt.rst

@ -128,7 +128,7 @@ As the virtio data structures of secure guests are not accessible
by the host, it is necessary to use shared memory ('bounce buffers').
Since libvirt 7.6.0 the
`<launchSecurity> <https://libvirt.org/formatdomain.html#launchSecurity>`__
`<launchSecurity> <https://libvirt.org/formatdomain.html#launch-security>`__
element with type ``s390-pv`` should be used on protected virtualization guests.
Without ``launchSecurity`` you must enable all virtio devices to use shared
buffers by configuring them with platform_iommu enabled.

8
docs/kbase/tlscerts.rst

@ -84,12 +84,12 @@ clients. There are two distinct checks involved:
- The client should know that it is connecting to the right server. Checking
done by client by matching the certificate that the server sends to the
server's hostname. May be disabled by adding ``?no_verify=1`` to the `remote
URI <uri.html#Remote_URI_parameters>`__.
URI <../uri.html#tls-transport>`__.
- The server should know that only permitted clients are connecting. This can
be done based on client's IP address, or on client's IP address and client's
certificate. Checking done by the server. May be enabled and disabled in the
`libvirtd.conf file <remote.html#libvirtd-configuration-file>`__.
`libvirtd.conf file <../remote.html#libvirtd-configuration-file>`__.
For full certificate checking you will need to have certificates issued by a
recognised `Certificate Authority
@ -99,7 +99,7 @@ CA, you can set up your own CA and tell your server(s) and clients to trust
certificates issues by your own CA. Follow the instructions in the next section.
Be aware that the `default configuration for
libvirtd <remote.html#libvirtd-configuration-file>`__ allows any client to
libvirtd <../remote.html#libvirtd-configuration-file>`__ allows any client to
connect provided they have a valid certificate issued by the CA for their own IP
address. You may want to change this to make it less (or more) permissive,
depending on your needs.
@ -180,7 +180,7 @@ for validation may be discontinued entirely, so it is strongly recommended to
include the SAN fields.
In the example below, clients will be connecting to the server using a
`URI <uri.html#URI_remote>`__ of ``qemu://compute1.libvirt.org/system``, so the
`URI <../uri.html#remote-uris>`__ of ``qemu://compute1.libvirt.org/system``, so the
CN must be "``compute1.libvirt.org``".
Make a private key for the server:

181
docs/manpages/virsh.rst

@ -895,7 +895,7 @@ domain capabilities XML (printed by ``domcapabilities`` command). In
addition to the <cpu> element itself, this command accepts
full domain XML, capabilities XML, or domain capabilities XML containing
the CPU definition. For more information on guest CPU definition see:
`https://libvirt.org/formatdomain.html#elementsCPU <https://libvirt.org/formatdomain.html#elementsCPU>`__. If *--error* is
`https://libvirt.org/formatdomain.html#elementsCPU <https://libvirt.org/formatdomain.html#cpu-model-and-topology>`__. If *--error* is
specified, the command will return an error when the given CPU is
incompatible with host CPU and a message providing more details about the
incompatibility will be printed out. If *--validate* is specified, validates
@ -943,7 +943,7 @@ host CPU model found in the domain capabilities XML (printed by the
``domcapabilities`` command). In addition to the <cpu> element itself, this
command accepts full domain XML, capabilities XML, or domain capabilities XML
containing the CPU definition. For more information on guest CPU definition
see: `https://libvirt.org/formatdomain.html#elementsCPU <https://libvirt.org/formatdomain.html#elementsCPU>`__.
see: `https://libvirt.org/formatdomain.html#elementsCPU <https://libvirt.org/formatdomain.html#cpu-model-and-topology>`__.
The *virttype* option specifies the virtualization type (usable in the 'type'
attribute of the <domain> top level element from the domain XML). *emulator*
@ -1959,10 +1959,16 @@ backup-dumpxml
::
backup-dumpxml domain
backup-dumpxml [--xpath EXPRESSION] [--wrap] domain
Output XML describing the current backup job.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
domiflist
---------
@ -2053,10 +2059,16 @@ domjobabort
::
domjobabort domain
domjobabort domain [--postcopy]
Abort the currently running domain job.
When the job to be aborted is a migration which entered post-copy mode, it
cannot be aborted as none of the hosts involved in migration has a complete
state of the domain. Optional *--postcopy* can be used to interrupt such
migration although doing so may effectively suspend the domain until the
migration is resumed (see also *--postcopy-resume* option of ``migrate``).
domjobinfo
----------
@ -2646,7 +2658,8 @@ dumpxml
::
dumpxml domain [--inactive] [--security-info] [--update-cpu] [--migratable]
dumpxml [--inactive] [--security-info] [--update-cpu] [--migratable]
[--xpath EXPRESSION] [--wrap] domain
Output the domain information as an XML dump to stdout, this format can be used
by the ``create`` command. Additional options affecting the XML dump may be
@ -2659,6 +2672,13 @@ migrations, i.e., compatible with older libvirt releases and possibly amended
with internal run-time options. This option may automatically enable other
options (*--update-cpu*, *--security-info*, ...) as necessary.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
edit
----
@ -2993,7 +3013,8 @@ iothreadset
::
iothreadset domain iothread_id [[--poll-max-ns ns] [--poll-grow factor]
[--poll-shrink divisor]]
[--poll-shrink divisor] [--thread-pool-min value]
[--thread-pool-max value]]
[[--config] [--live] | [--current]]
Modifies an existing iothread of the domain using the specified
@ -3010,6 +3031,16 @@ for a running guest. Saving, destroying, stopping, etc. the guest will
result in the polling values returning to hypervisor defaults at the
next start, restore, etc.
The *--thread-pool-min* and *--thread-pool-max* options then set lower and
upper bound, respectively of number of threads in worker pool of given
iothread. For changes to an inactive configuration -1 can be specified to
remove corresponding boundary from the domain configuration. For changes to a
running guest it's recommended to set the upper boundary first
(*--thread-pool-max*) and only after that set the lower boundary
(*--thread-pool-min*). It is allowed for the lower boundary to be the same as
the upper boundary, however it's not allowed for the upper boundary to be value
of zero.
If *--live* is specified, affect a running guest. If the guest is not
running an error is returned.
If *--current* is specified or *--live* is not specified, then handle
@ -3073,12 +3104,19 @@ managedsave-dumpxml
::
managedsave-dumpxml domain [--security-info]
managedsave-dumpxml [--security-info] [--xpath EXPRESSION] [--wrap] domain
Extract the domain XML that was in effect at the time the saved state
file *file* was created with the ``managedsave`` command. Using
*--security-info* will also include security sensitive information.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
managedsave-edit
----------------
@ -3246,7 +3284,8 @@ migrate
migrate [--live] [--offline] [--direct] [--p2p [--tunnelled]]
[--persistent] [--undefinesource] [--suspend] [--copy-storage-all]
[--copy-storage-inc] [--change-protection] [--unsafe] [--verbose]
[--rdma-pin-all] [--abort-on-error] [--postcopy] [--postcopy-after-precopy]
[--rdma-pin-all] [--abort-on-error] [--postcopy]
[--postcopy-after-precopy] [--postcopy-resume] [--zerocopy]
domain desturi [migrateuri] [graphicsuri] [listen-address] [dname]
[--timeout seconds [--timeout-suspend | --timeout-postcopy]]
[--xml file] [--migrate-disks disk-list] [--disks-port port]
@ -3302,7 +3341,11 @@ Once migration is running, the user may switch to post-copy using the
automatically switch to post-copy after the first pass of pre-copy is finished.
The maximum bandwidth consumed during the post-copy phase may be limited using
*--postcopy-bandwidth*. The maximum bandwidth consumed during the pre-copy phase
may be limited using *--bandwidth*.
may be limited using *--bandwidth*. In case connection between the hosts breaks
while migration is in post-copy mode, the domain cannot be resumed on either
source or destination host and the ``migrate`` command will report an error
leaving the domain active on both hosts. To recover from such situation repeat
the original ``migrate`` command with an additional *--postcopy-resume* flag.
*--auto-converge* forces convergence during live migration. The initial
guest CPU throttling rate can be set with *auto-converge-initial*. If the
@ -3319,6 +3362,11 @@ high (and thus allowing the domain to lock most of the host's memory). Doing so
may be dangerous to both the domain and the host itself since the host's kernel
may run out of memory.
*--zerocopy* requests zero-copy mechanism to be used for migrating memory pages.
For QEMU/KVM this means QEMU will be temporarily allowed to lock all guest
pages in host's memory, although only those that are queued for transfer will
be locked at the same time.
``Note``: Individual hypervisors usually do not support all possible types of
migration. For example, QEMU does not support direct migration.
@ -3868,12 +3916,19 @@ save-image-dumpxml
::
save-image-dumpxml file [--security-info]
save-image-dumpxml [--security-info] [--xpath EXPRESSION] [--wrap] file
Extract the domain XML that was in effect at the time the saved state
file *file* was created with the ``save`` command. Using
*--security-info* will also include security sensitive information.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
save-image-edit
---------------
@ -4645,7 +4700,7 @@ attach-device
Attach a device to the domain, using a device definition in an XML
file using a device definition element such as <disk> or <interface>
as the top-level element. See the documentation at
`https://libvirt.org/formatdomain.html#elementsDevices <https://libvirt.org/formatdomain.html#elementsDevices>`__ to learn about
`https://libvirt.org/formatdomain.html#elementsDevices <https://libvirt.org/formatdomain.html#devices>`__ to learn about
libvirt XML format for a device. If *--config* is specified the
command alters the persistent guest configuration with the device
attach taking effect the next time libvirt starts the domain.
@ -5006,7 +5061,7 @@ Update the characteristics of a device associated with *domain*,
based on the device definition in an XML *file*. The *--force* option
can be used to force device update, e.g., to eject a CD-ROM even if it is
locked/mounted in the domain. See the documentation at
`https://libvirt.org/formatdomain.html#elementsDevices <https://libvirt.org/formatdomain.html#elementsDevices>`__ to learn about
`https://libvirt.org/formatdomain.html#elementsDevices <https://libvirt.org/formatdomain.html#devices>`__ to learn about
libvirt XML format for a device.
If *--live* is specified, affect a running domain.
@ -5222,7 +5277,7 @@ nodedev-dumpxml
::
nodedev-dumpxml device
nodedev-dumpxml [--xpath EXPRESSION] [--wrap] device
Dump a <device> XML representation for the given node device, including
such information as the device name, which bus owns the device, the
@ -5231,6 +5286,13 @@ libvirt (such as whether device reset is supported). *device* can
be either device name or wwn pair in "wwnn,wwpn" format (only works
for HBA).
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
nodedev-info
------------
@ -5411,13 +5473,20 @@ net-dumpxml
::
net-dumpxml network [--inactive]
net-dumpxml [--inactive] [--xpath EXPRESSION] [--wrap] network
Output the virtual network information as an XML dump to stdout.
If *--inactive* is specified, then physical functions are not
expanded into their associated virtual functions.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
net-edit
--------
@ -5673,10 +5742,17 @@ net-port-dumpxml
::
net-port-dumpxml network port
net-port-dumpxml [--xpath EXPRESSION] [--wrap] network port
Output the network port information as an XML dump to stdout.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
net-port-delete
---------------
@ -5760,12 +5836,19 @@ iface-dumpxml
::
iface-dumpxml interface [--inactive]
iface-dumpxml [--inactive] [--xpath EXPRESSION] [--wrap] interface
Output the host interface information as an XML dump to stdout. If
*--inactive* is specified, then the output reflects the persistent
state of the interface that will be used the next time it is started.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
iface-edit
----------
@ -6236,12 +6319,19 @@ pool-dumpxml
::
pool-dumpxml [--inactive] pool-or-uuid
pool-dumpxml [--inactive] [--xpath EXPRESSION] [--wrap] pool-or-uuid
Returns the XML information about the *pool* object.
*--inactive* tells virsh to dump pool configuration that will be used
on next start of the pool as opposed to the current pool configuration.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
pool-edit
---------
@ -6728,7 +6818,8 @@ vol-dumpxml
::
vol-dumpxml vol-name-or-key-or-path [--pool pool-or-uuid]
vol-dumpxml [--pool pool-or-uuid] [--xpath EXPRESSION] [--wrap]
vol-name-or-key-or-path
Output the volume information as an XML dump to stdout.
@ -6740,6 +6831,13 @@ is in. If the volume name is provided instead of the key or path, then
providing the pool is necessary to find the volume to be uploaded into;
otherwise, the first volume found by the key or path will be used.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
vol-info
--------
@ -6927,10 +7025,17 @@ secret-dumpxml
::
secret-dumpxml secret
secret-dumpxml [--xpath EXPRESSION] [--wrap] secret
Output properties of *secret* (specified by its UUID) as an XML dump to stdout.
If the **--xpath** argument provides an XPath expression, it will be
evaluated against the output XML and only those matching nodes will
be printed. The default behaviour is to print each matching node as
a standalone document, however, for ease of additional processing,
the **--wrap** argument will cause the matching node to be wrapped
in a common root node.
secret-event