[libvirt] [jenkins-ci PATCH 0/5] Fix environment handling
by Andrea Bolognani
My own attempt at fixing libosinfo-master-rpm's failing status,
and then some.
This is an extension of Pavel's attempt[1] in a way; except of
course I think my approach is superior, otherwise I wouldn't have
bothered ;)
It also sets the groundwork for finally moving $VIRT_PREFIX and
friends out of the Jenkins server configuration, where they are
invisible to anyone but the CI admins, and into the git repository
so that they can be tracked alongside the jobs using them.
[1] https://www.redhat.com/archives/libvir-list/2017-November/msg00045.html
Andrea Bolognani (5):
jobs: Rename {make_env} to {global_env}
jobs: Include {global_env} everywhere
jobs: Rename {check_env} to {env}
jobs: Include {env} everywhere
jobs: Include $PATH definition in {global_env}
jobs/autotools.yaml | 17 ++++++++++++-----
jobs/defaults.yaml | 5 +++--
jobs/generic.yaml | 20 ++++++++++++++++----
jobs/go.yaml | 4 ++++
jobs/perl-makemaker.yaml | 9 ++++++---
jobs/perl-modulebuild.yaml | 6 ++++++
jobs/python-distutils.yaml | 6 ++++++
projects/libosinfo.yaml | 2 +-
projects/libvirt.yaml | 2 +-
projects/osinfo-db.yaml | 4 ----
10 files changed, 55 insertions(+), 20 deletions(-)
--
2.14.3
7 years
[libvirt] [PATCH 00/14] Fix serial console behavior on non-x86 architectures
by Andrea Bolognani
See the last commit for a short explanation of what this series
is all about.
Andrea Bolognani (10):
qemu: Add QEMU_CAPS_DEVICE_SPAPR_VTY
conf,qemu: Use type-aware switches where possible
qemu: Introduce qemuDomainChrDefPostParse()
conf: Run devicePostParse() again for the first serial device
conf: Introduce VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_NONE
conf: Drop virDomainChrDeviceType.targetTypeAttr
conf: Add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR
qemu: Support usb-serial and pci-serial on pSeries
conf: Add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PL011
news: Update for serial console fixes
Pino Toscano (4):
conf: add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP/SCLPLM
conf: pass parseFlags down to virDomainDefAddConsoleCompat
conf: convert sclp/sclplm <console> as <serial>
qemu: switch s390/s390x default console back to serial
docs/formatdomain.html.in | 13 +-
docs/news.xml | 12 ++
docs/schemas/domaincommon.rng | 4 +
src/conf/domain_conf.c | 132 +++++++++++++++-----
src/conf/domain_conf.h | 11 +-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 136 +++++++++++++--------
src/qemu/qemu_domain.c | 95 ++++++++++++--
src/qemu/qemu_domain_address.c | 8 +-
src/vz/vz_sdk.c | 5 +-
.../qemuargv2xml-console-compat.xml | 2 +-
tests/qemuargv2xmldata/qemuargv2xml-serial-dev.xml | 2 +-
.../qemuargv2xmldata/qemuargv2xml-serial-file.xml | 2 +-
.../qemuargv2xmldata/qemuargv2xml-serial-many.xml | 4 +-
tests/qemuargv2xmldata/qemuargv2xml-serial-pty.xml | 2 +-
.../qemuargv2xml-serial-tcp-telnet.xml | 2 +-
tests/qemuargv2xmldata/qemuargv2xml-serial-tcp.xml | 2 +-
tests/qemuargv2xmldata/qemuargv2xml-serial-udp.xml | 4 +-
.../qemuargv2xmldata/qemuargv2xml-serial-unix.xml | 2 +-
tests/qemuargv2xmldata/qemuargv2xml-serial-vc.xml | 2 +-
tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 +
...otplug-console-compat-2-live+console-virtio.xml | 4 +-
.../qemuhotplug-console-compat-2-live.xml | 4 +-
.../qemuxml2argv-mach-virt-console-native.args | 1 +
.../qemuxml2argv-mach-virt-console-native.xml | 17 +++
... => qemuxml2argv-mach-virt-console-virtio.args} | 15 +--
.../qemuxml2argv-mach-virt-console-virtio.xml | 19 +++
...muxml2argv-mach-virt-serial+console-native.args | 1 +
...emuxml2argv-mach-virt-serial+console-native.xml | 18 +++
.../qemuxml2argv-mach-virt-serial-compat.args | 1 +
.../qemuxml2argv-mach-virt-serial-compat.xml | 19 +++
...muxml2argv-mach-virt-serial-invalid-machine.xml | 19 +++
...s => qemuxml2argv-mach-virt-serial-native.args} | 12 +-
.../qemuxml2argv-mach-virt-serial-native.xml | 16 +++
.../qemuxml2argv-mach-virt-serial-pci.args | 26 ++++
.../qemuxml2argv-mach-virt-serial-pci.xml | 18 +++
.../qemuxml2argv-mach-virt-serial-usb.args | 27 ++++
.../qemuxml2argv-mach-virt-serial-usb.xml | 21 ++++
.../qemuxml2argv-pseries-basic.args | 2 +-
.../qemuxml2argv-pseries-console-native.args | 1 +
.../qemuxml2argv-pseries-console-native.xml | 17 +++
...gs => qemuxml2argv-pseries-console-virtio.args} | 10 +-
.../qemuxml2argv-pseries-console-virtio.xml | 19 +++
.../qemuxml2argv-pseries-cpu-compat-power9.args | 2 +-
.../qemuxml2argv-pseries-cpu-compat.args | 2 +-
.../qemuxml2argv-pseries-cpu-exact.args | 2 +-
.../qemuxml2argv-pseries-cpu-le.args | 2 +-
.../qemuxml2argv-pseries-panic-missing.args | 2 +-
.../qemuxml2argv-pseries-panic-no-address.args | 2 +-
...qemuxml2argv-pseries-serial+console-native.args | 1 +
.../qemuxml2argv-pseries-serial+console-native.xml | 18 +++
.../qemuxml2argv-pseries-serial-compat.args | 1 +
.../qemuxml2argv-pseries-serial-compat.xml | 19 +++
...qemuxml2argv-pseries-serial-invalid-machine.xml | 19 +++
...rgs => qemuxml2argv-pseries-serial-native.args} | 7 +-
.../qemuxml2argv-pseries-serial-native.xml | 16 +++
...c.args => qemuxml2argv-pseries-serial-pci.args} | 7 +-
.../qemuxml2argv-pseries-serial-pci.xml | 18 +++
...c.args => qemuxml2argv-pseries-serial-usb.args} | 8 +-
.../qemuxml2argv-pseries-serial-usb.xml | 21 ++++
.../qemuxml2argv-pseries-usb-default.args | 2 +-
.../qemuxml2argv-pseries-usb-kbd.args | 2 +-
.../qemuxml2argv-pseries-usb-multi.args | 2 +-
.../qemuxml2argv-pseries-vio-user-assigned.args | 4 +-
.../qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 4 +-
....args => qemuxml2argv-s390-console2serial.args} | 11 +-
.../qemuxml2argv-s390-console2serial.xml | 19 +++
...power9.args => qemuxml2argv-s390-serial-2.args} | 14 +--
.../qemuxml2argv-s390-serial-2.xml | 17 +++
....args => qemuxml2argv-s390-serial-console.args} | 11 +-
.../qemuxml2argv-s390-serial-console.xml | 15 +++
...es-basic.args => qemuxml2argv-s390-serial.args} | 11 +-
.../qemuxml2argvdata/qemuxml2argv-s390-serial.xml | 14 +++
...muxml2argv-serial-tcp-tlsx509-chardev-notls.xml | 4 +-
.../qemuxml2argvdata/qemuxml2argv-user-aliases.xml | 4 +-
tests/qemuxml2argvtest.c | 83 +++++++++++++
.../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 2 +-
.../qemuxml2xmlout-bios-nvram-os-interleave.xml | 2 +-
.../qemuxml2xmlout-chardev-label.xml | 4 +-
.../qemuxml2xmlout-console-compat-auto.xml | 2 +-
.../qemuxml2xmlout-console-compat.xml | 2 +-
.../qemuxml2xmlout-console-compat2.xml | 2 +-
.../qemuxml2xmlout-console-virtio-many.xml | 2 +-
.../qemuxml2xmlout-interface-driver.xml | 2 +-
.../qemuxml2xmlout-interface-server.xml | 4 +-
.../qemuxml2xmlout-mach-virt-console-native.xml | 1 +
...=> qemuxml2xmlout-mach-virt-console-virtio.xml} | 19 +--
...uxml2xmlout-mach-virt-serial+console-native.xml | 1 +
.../qemuxml2xmlout-mach-virt-serial-compat.xml | 29 +++++
.../qemuxml2xmlout-mach-virt-serial-native.xml | 1 +
.../qemuxml2xmlout-mach-virt-serial-pci.xml | 42 +++++++
.../qemuxml2xmlout-mach-virt-serial-usb.xml | 39 ++++++
.../qemuxml2xmlout-net-bandwidth.xml | 2 +-
.../qemuxml2xmlout-net-bandwidth2.xml | 2 +-
.../qemuxml2xmlout-net-coalesce.xml | 2 +-
.../qemuxml2xmloutdata/qemuxml2xmlout-net-mtu.xml | 2 +-
.../qemuxml2xmlout-panic-pseries.xml | 2 +-
.../qemuxml2xmlout-pseries-console-native.xml | 1 +
...l => qemuxml2xmlout-pseries-console-virtio.xml} | 16 +--
.../qemuxml2xmlout-pseries-cpu-compat-power9.xml | 2 +-
.../qemuxml2xmlout-pseries-cpu-compat.xml | 2 +-
.../qemuxml2xmlout-pseries-cpu-exact.xml | 2 +-
.../qemuxml2xmlout-pseries-panic-missing.xml | 2 +-
.../qemuxml2xmlout-pseries-panic-no-address.xml | 2 +-
...emuxml2xmlout-pseries-serial+console-native.xml | 1 +
.../qemuxml2xmlout-pseries-serial-compat.xml | 1 +
...ml => qemuxml2xmlout-pseries-serial-native.xml} | 8 +-
...g.xml => qemuxml2xmlout-pseries-serial-pci.xml} | 14 +--
...g.xml => qemuxml2xmlout-pseries-serial-usb.xml} | 11 +-
.../qemuxml2xmlout-q35-virt-manager-basic.xml | 2 +-
.../qemuxml2xmlout-s390-defaultconsole.xml | 6 +-
.../qemuxml2xmlout-s390-serial-2.xml | 29 +++++
....xml => qemuxml2xmlout-s390-serial-console.xml} | 18 +--
...tconsole.xml => qemuxml2xmlout-s390-serial.xml} | 18 +--
.../qemuxml2xmlout-serial-spiceport-nospice.xml | 2 +-
.../qemuxml2xmlout-serial-spiceport.xml | 2 +-
.../qemuxml2xmlout-serial-target-port-auto.xml | 6 +-
.../qemuxml2xmlout-serial-tcp-tlsx509-chardev.xml | 4 +-
.../qemuxml2xmlout-tap-vhost-incorrect.xml | 2 +-
.../qemuxml2xmlout-tap-vhost.xml | 2 +-
.../qemuxml2xmlout-vhost_queues.xml | 2 +-
tests/qemuxml2xmltest.c | 54 ++++++++
125 files changed, 1186 insertions(+), 284 deletions(-)
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-native.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-native.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-mach-virt-console-virtio.args} (53%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-console-virtio.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial+console-native.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial+console-native.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-compat.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-compat.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-invalid-machine.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-mach-virt-serial-native.args} (62%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-native.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-pci.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-pci.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-usb.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-mach-virt-serial-usb.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-native.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-native.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-console-virtio.args} (59%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-console-virtio.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial+console-native.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial+console-native.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-compat.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-compat.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-invalid-machine.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-native.args} (70%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-native.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-pci.args} (70%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-pci.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-pseries-serial-usb.args} (65%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-serial-usb.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-console2serial.args} (71%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-console2serial.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-cpu-compat-power9.args => qemuxml2argv-s390-serial-2.args} (62%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial-2.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-serial-console.args} (71%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial-console.xml
copy tests/qemuxml2argvdata/{qemuxml2argv-pseries-basic.args => qemuxml2argv-s390-serial.args} (71%)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-s390-serial.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-console-native.xml
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-mach-virt-console-virtio.xml} (50%)
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial+console-native.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-compat.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-native.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-pci.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-mach-virt-serial-usb.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-console-native.xml
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-panic-pseries.xml => qemuxml2xmlout-pseries-console-virtio.xml} (75%)
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-serial+console-native.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-serial-compat.xml
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-native.xml} (82%)
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-pci.xml} (74%)
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-panic-missing.xml => qemuxml2xmlout-pseries-serial-usb.xml} (75%)
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-s390-serial-2.xml
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-s390-serial-console.xml} (50%)
copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-s390-defaultconsole.xml => qemuxml2xmlout-s390-serial.xml} (50%)
--
2.13.6
7 years
[libvirt] [jenkins-ci PATCH 0/3] Add Fedora 27, remove Fedora 25
by Andrea Bolognani
'tis the season.
Andrea Bolognani (3):
Add Fedora 27 builder
Remove Fedora 25 builder
guests: Adjust Fedora 26 install URL
guests/host_vars/libvirt-fedora-26/install.yml | 2 +-
.../install.yml | 2 +-
.../main.yml | 0
guests/inventory | 2 +-
guests/vars/vault.yml | 90 +++++++++++-----------
projects/libosinfo.yaml | 4 +-
projects/libvirt-cim.yaml | 2 +-
projects/libvirt-glib.yaml | 4 +-
projects/libvirt-go-xml.yaml | 2 +-
projects/libvirt-go.yaml | 2 +-
projects/libvirt-perl.yaml | 4 +-
projects/libvirt-python.yaml | 4 +-
projects/libvirt-sandbox.yaml | 4 +-
projects/libvirt-tck.yaml | 4 +-
projects/libvirt.yaml | 6 +-
projects/osinfo-db-tools.yaml | 4 +-
projects/osinfo-db.yaml | 4 +-
projects/virt-manager.yaml | 4 +-
projects/virt-viewer.yaml | 4 +-
19 files changed, 74 insertions(+), 74 deletions(-)
rename guests/host_vars/{libvirt-fedora-25 => libvirt-fedora-27}/install.yml (74%)
rename guests/host_vars/{libvirt-fedora-25 => libvirt-fedora-27}/main.yml (100%)
--
2.14.3
7 years
[libvirt] [PATCH 0/2] tests: commandtest: handle tcmalloc hacking environment
by Nikolay Shirokovskiy
Nikolay Shirokovskiy (2):
tests: commandtest: handle tcmalloc hacking environment
tests: fix typo
tests/commanddata/test10.log | 3 ++-
tests/commanddata/test11.log | 3 ++-
tests/commanddata/test12.log | 3 ++-
tests/commanddata/test13.log | 3 ++-
tests/commanddata/test14.log | 3 ++-
tests/commanddata/test15.log | 3 ++-
tests/commanddata/test2.log | 3 ++-
tests/commanddata/test20.log | 3 ++-
tests/commanddata/test21.log | 3 ++-
tests/commanddata/test3.log | 3 ++-
tests/commanddata/test4.log | 3 ++-
tests/commanddata/test5.log | 3 ++-
tests/commanddata/test7.log | 3 ++-
tests/commanddata/test9.log | 3 ++-
tests/commandhelper.c | 11 +++++++++--
tests/commandtest.c | 2 +-
16 files changed, 38 insertions(+), 17 deletions(-)
--
1.8.3.1
7 years
[libvirt] [PATCH 0/6] Implement query-dump command
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=916061
Details in the patches. Essentially though QEMU 2.6 added the ability
to perform the 'dump-guest-memory' via a thread by adding a 'detach'
boolean to the command. In order to watch the progress of the thread
the 'query-dump' command was added. The query-dump will return just
the current status, the total size to be dumped, and the current
progress. So using the migrate stats data in the DomainJobInfo we
can then save our current progress allowing tools such as virsh to
watch that progress. As an added benefit, the dump-guest-memory is
now truly asynchronous.
John Ferlan (6):
qemu: Fix the qemuDumpToFd definition
qemu: Alter dump-guest-memory command generation
qemu: Add query-dump to the capabilities
qemu: Introduce qemuMonitor[JSON]QueryDump
qemu: Add new @detach parameter to dump-guest-memory
qemu: Allow showing the dump progress for memory only dump
src/qemu/qemu_capabilities.c | 4 +-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_driver.c | 95 ++++++++++++++++++++--
src/qemu/qemu_monitor.c | 25 +++++-
src/qemu/qemu_monitor.h | 25 +++++-
src/qemu/qemu_monitor_json.c | 91 +++++++++++++++++----
src/qemu/qemu_monitor_json.h | 7 +-
.../caps_2.10.0-gicv2.aarch64.xml | 1 +
.../caps_2.10.0-gicv3.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 +
.../caps_2.6.0-gicv2.aarch64.xml | 1 +
.../caps_2.6.0-gicv3.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 +
tests/qemumonitorjsontest.c | 3 +-
24 files changed, 240 insertions(+), 27 deletions(-)
--
2.13.6
7 years
[libvirt] [PATCH] docs: don't use https in XML namespace URIs
by Daniel P. Berrange
The XML namespace URI for the QEMU/LXC drivers must use http as the protocol
otherwise it won't match the parser's expectations.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
docs/drvlxc.html.in | 2 +-
docs/drvqemu.html.in | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in
index 94c6b82cfd..58a336ed30 100644
--- a/docs/drvlxc.html.in
+++ b/docs/drvlxc.html.in
@@ -601,7 +601,7 @@ rather than creating new network namespace for the container. In this case privn
ignored.
</p>
<pre>
-<domain type='lxc' xmlns:lxc='https://libvirt.org/schemas/domain/lxc/1.0'>
+<domain type='lxc' xmlns:lxc='http://libvirt.org/schemas/domain/lxc/1.0'>
...
<lxc:namespace>
<lxc:sharenet type='netns' value='red'/>
diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in
index e2a0797cfb..cb41b505d7 100644
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -546,7 +546,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
(<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>https://libvirt.org/schemas/domain/qemu/1.0</code>;
+ 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>
@@ -566,7 +566,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
and optional <code>value</code>.</dd>
</dl>
<p>Example:</p><pre>
-<domain type='qemu' xmlns:qemu='https://libvirt.org/schemas/domain/qemu/1.0'>
+<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>QEmu-fedora-i686</name>
<memory>219200</memory>
<os>
--
2.14.3
7 years
[libvirt] [PATCH] AppArmor: add rules needed with additional mediation features brought by Linux 4.14.
by intrigeri
---
examples/apparmor/libvirt-qemu | 2 ++
examples/apparmor/usr.sbin.libvirtd | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu
index b341e31f42..5994a35042 100644
--- a/examples/apparmor/libvirt-qemu
+++ b/examples/apparmor/libvirt-qemu
@@ -16,6 +16,8 @@
network inet stream,
network inet6 stream,
+ signal (receive) set=("term") peer=/usr/sbin/libvirtd,
+
/dev/net/tun rw,
/dev/kvm rw,
/dev/ptmx rw,
diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index 819068ffc3..17b5ee38ff 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -30,6 +30,8 @@
# Needed for vfio
capability sys_resource,
+ mount,
+
network inet stream,
network inet dgram,
network inet6 stream,
@@ -37,11 +39,18 @@
network packet dgram,
network packet raw,
+ network netlink raw,
+ network unix dgram,
+ network unix stream,
+
ptrace (trace) peer=unconfined,
ptrace (trace) peer=/usr/sbin/libvirtd,
ptrace (trace) peer=/usr/sbin/dnsmasq,
ptrace (trace) peer=libvirt-*,
+ signal (send) set=("hup") peer=/usr/sbin/dnsmasq,
+ signal (send) set=("term") peer=libvirt-*,
+
# Very lenient profile for libvirtd since we want to first focus on confining
# the guests. Guests will have a very restricted profile.
/ r,
--
2.15.0.rc2
7 years
[libvirt] [PATCH 0/2] vmcoreinfo feature
by marcandre.lureau＠redhat.com
From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Hi,
Starting with QEMU 2.11, the guest can save kernel debug details when
this feature is enabled and the kernel supports it. It is useful to
process kernel dump with KASLR enabled, and also provides various
kernel details to crash tools.
rfc->v1:
- rebased
- update commit message to give some internal fw_cfg details
- add news patch
Marc-André Lureau (2):
qemu: add vmcoreinfo support
news: add vmcoreinfo feature details
docs/formatdomain.html.in | 4 +++
docs/news.xml | 11 +++++++
docs/schemas/domaincommon.rng | 9 +++++
src/conf/domain_conf.c | 3 ++
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 26 +++++++++++++++
.../qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args | 25 ++++++++++++++
tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml | 28 ++++++++++++++++
tests/qemuxml2argvtest.c | 1 +
.../qemuxml2xmlout-vmcoreinfo.xml | 38 ++++++++++++++++++++++
tests/qemuxml2xmltest.c | 1 +
13 files changed, 150 insertions(+)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml
--
2.15.0.125.g8f49766d64
7 years
[libvirt] [PATCH] xenconfig: fix compilation error
by Jim Fehlig
Commit 03d0959a introduced a compilation error in
src/xenconfig/xen_xl.c on ARM. Found by Xen's osstest
http://logs.test-lab.xenproject.org/osstest/logs/116216/build-armhf-libvi...
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
Pushing under the build-breaker rule.
src/xenconfig/xen_xl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index 05146d7db..984024bba 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -1261,11 +1261,11 @@ xenFormatXLVnuma(virConfValuePtr list,
numaVnode->list = NULL;
/* pnode */
- virBufferAsprintf(&buf, "pnode=%ld", node);
+ virBufferAsprintf(&buf, "pnode=%zu", node);
xenFormatXLVnode(numaVnode, &buf);
/* size */
- virBufferAsprintf(&buf, "size=%ld", nodeSize);
+ virBufferAsprintf(&buf, "size=%zu", nodeSize);
xenFormatXLVnode(numaVnode, &buf);
/* vcpus */
--
2.15.0
7 years
[libvirt] [PATCH v2] docs: add a page describing support guarantees for libvirt features
by Daniel P. Berrange
While we have collective knowledge about the support status of various
parts of libvirt, this has never been formally documented, leaving our
users to guess.
Note, this document makes one change to our previous policy. It explicitly
declares the RPC protocol of libvirtd as being a supported interface. THis
accepts the reality that we can a) never change it without breaking compat
with old libvirt.so, b) there are both rust + go impls that are written
against the RPC protocol alrady.
Reviewed-by: Jim Fehlig <jfehlig(a)suse.com>
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Changed in v2:
- Spelling fixes (Jim)
- Call out new RPC policy in commit msg
docs/docs.html.in | 3 +
docs/support.html.in | 257 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 260 insertions(+)
create mode 100644 docs/support.html.in
diff --git a/docs/docs.html.in b/docs/docs.html.in
index 931da85424..a8d544f83f 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -110,6 +110,9 @@
<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>
diff --git a/docs/support.html.in b/docs/support.html.in
new file mode 100644
index 0000000000..7a377e6152
--- /dev/null
+++ b/docs/support.html.in
@@ -0,0 +1,257 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1>Support guarantees</h1>
+
+ <ul id="toc"></ul>
+
+ <p>
+ This document will outline the support status / guarantees around the
+ very interfaces that libvirt exposes to applications and/or system
+ administrators. The intent is to help users understand what features they
+ can rely upon in particular scenarios, and whether they are likely to
+ suffer disruption during upgrades
+ </p>
+
+ <h2><a id="publicAPI">Primary public API</a></h2>
+
+ <p>
+ The main public API provided by <code>libvirt.so</code> and described
+ in <code>libvirt/libvirt.h</code> exposes the primary hypervisor
+ agnostic management interface of libvirt. This API has the strongest
+ guarantee of any part of libvirt with a promise to keep backwards
+ compatibility forever. Specific details are as follows:
+ </p>
+
+ <dl>
+ <dt>Functions</dt>
+ <dd>Functions will never be removed from the public API, and will
+ never have parameters added, removed or changed in their signature.
+ IOW they will be ABI compatible forever. The semantics implied by
+ a specific set of parameters passed to the function will remain
+ unchanged. Where a parameter accepts a bitset of feature flags, or
+ an enumerated value, further flags / enum values may be supported
+ in the future. Where a parameter accepts one of a set of related
+ constants, further constants may be supported in the future.
+ </dd>
+ <dt>Struct types</dt>
+ <dd>Once defined in a release, struct definitions will never have any
+ fields add, removed or changed in any way. Their size and layout is
+ fixed forever. If a struct name starts with an underscore, it is
+ considered acceptable to rename it. Applications should thus always
+ use the corresponding typedef in preference to the struct name.
+ </dd>
+ <dt>Union types</dt>
+ <dd>Once defined in a release, union definitions will never have any
+ existing fields removed or changed. New union choices may be added,
+ provided that they don't change the size of the existing union
+ definition. If a struct name starts with an underscore, it is
+ considered acceptable to rename it. Applications should thus always
+ use the corresponding typedef in preference to the struct name.
+ </dd>
+ <dt>Type definitions</dt>
+ <dd>Most custom data types used in the APIs have corresponding typedefs
+ provided for their stable names. The typedefs should always be used
+ in preference to the underlying data type name, as the latter are not
+ guaranteed to be stable.
+ </dd>
+ <dt>Enumerations</dt>
+ <dd>Once defined in a release, existing enumeration values will never
+ be removed or renamed. New enumeration values may be introduced at
+ any time. Every enumeration will have a '_LAST' value which indicates
+ the current highest enumeration value, which may increase with new
+ releases. If an enumeration name starts with an underscore, it is
+ considered acceptable to rename it. Applications should thus always
+ use the corresponding typedef in preference to the enum name.
+ </dd>
+ <dt>Constants</dt>
+ <dd>Once defined in a release, existing constants will never be removed
+ or have their value changed. Most constants are grouped into related
+ sets, and within each set, new constants may be introduced. APIs which
+ use the constants may thus accept or return new constant values over
+ time.
+ </dd>
+ <dt>Symbol versions</dt>
+ <dd>Where the platform library format permits, APIs defined in libvirt.so
+ library will have version information associated. Each API will be
+ tagged with the version in which it was introduced, and this won't
+ be changed thereafter.
+ </dd>
+ </dl>
+
+ <h2><a id="hvAPI">Hypervisor specific APIs</a></h2>
+
+ <p>
+ A number of hypervisor drivers provide additional libraries with hypervisor
+ specific APIs, extending the core libvirt API. These add-on libraries follow
+ the same general principles described above, however, they are <strong>not</strong>
+ guaranteed to be preserved forever. The project reserves the right to remove
+ hypervisor specific APIs in any new release, or to change their semantics.
+ That said the project will endeavour to maintain API compatibility for as long
+ as is practical.
+ </p>
+
+ <p>
+ Use of some hypervisor specific APIs may result in the running guest being
+ marked as "tainted" if the API is at risk of having unexpected interactions
+ with normal libvirt operations. An application which chooses to make use of
+ hypervisor specific APIs should validate their operation with each new release
+ of libvirt and each new release of the underlying hypervisor. The semantics
+ may change in unexpected ways, or have unforeseen interactions with libvirt's
+ operation.
+ </p>
+
+ <h2><a id="apierrors">Error reporting</a></h2>
+
+ <p>
+ Most API calls are subject to failure and so will report error codes and
+ messages. Libvirt defines error codes for a wide variety of scenarios, some
+ represent very specific problems, while others are general purpose for
+ broad classes of problem. Over time the error codes reported are liable
+ to change, usually changing from a generic error to a more specific error.
+ Thus applications should be careful about checking for & taking action
+ upon specific error codes, as their behaviour may change across releases.
+ </p>
+
+ <h2><a id="xmlschema">XML schemas</a></h2>
+
+ <p>
+ The main objects exposed via the primary libvirt public API are usually
+ configured via XML documents following specific schemas. The XML schemas
+ are considered to be stable formats, whose compatibility will be maintained
+ forever. Specific details are as follows:
+ </p>
+
+ <dl>
+ <dt>Attributes</dt>
+ <dd>Attributes defined on an XML element will never be removed or
+ renamed. New attributes may be defined. If the set of valid values
+ for an attribute are determined by an enumeration, the permitted
+ values will never be removed or renamed, only new values defined.
+ None the less, specific hypervisors may reject usage of certain
+ values according to their feature set.</dd>
+ <dt>Elements</dt>
+ <dd>Elements defined will never be removed or renamed. New child
+ elements may be defined at any time. In places where only a
+ single instance of a named XML element is used, future versions
+ may be extended to permit multiple instances of the named XML
+ element to be used. An element which currently has no content
+ may later gain child elements.
+ </dd>
+ </dl>
+
+ <p>
+ Some hypervisor drivers may choose to allow use of hypervisor specific
+ extensions to the XML documents. These extensions will always be
+ contained within a hypervisor specific XML namespace. There is generally
+ no guarantee of long term support for the hypervisor specific extensions
+ across releases, though the project will endeavour to preserve them as
+ long as is possible. Applications choosing to use hypervisor specific
+ extensions should validate their operation against new libvirt or
+ hypervisor releases.
+ </p>
+
+ <h2><a id="configfiles">Configuration files</a></h2>
+
+ <p>
+ A number of programs / daemons provided libvirt rely on host filesystem
+ configuration files. These configuration files are accompanied by augeas
+ lens for easy manipulation by applications. There is in general no
+ guarantee that parameters available in the configuration file will be
+ preserved across releases, though the project will endeavour to preserve
+ them as long as is possible. If a configuration option is dropped from
+ the file, the augeas lens will retain the ability to read that configuration
+ parameter, so that it is able to read & update historically modified
+ files.
+
+ The default configuration files ship with all parameters commented out
+ such that a deployment relies on the built-in defaults of the application
+ in question. There is no guarantee that the defaults will remain the same
+ across releases. A deployment that expects a particular value for a
+ configuration parameter should consider defining it explicitly, instead
+ of relying on the defaults.
+ </p>
+
+ <h2><a id="hvdrivers">Hypervisor drivers</a></h2>
+
+ <p>
+ The libvirt project provides support for a wide variety of hypervisor
+ drivers. These drivers target certain versions of the hypervisor's
+ underlying management APIs. In general libvirt aims to work with any
+ hypervisor version that is still broadly supported by its vendor.
+ When a vendor discontinues support for a particular hypervisor
+ version it will be dropped by libvirt. Libvirt may choose to drop
+ support for a particular hypervisor version prior to the vendor
+ ending support, if it deems that the likely usage is too small to
+ justify the ongoing maintenance cost.
+ </p>
+ <p>
+ Each hypervisor release will implement a distinct subset of features
+ that can be expressed in the libvirt APIs and XML formats. While the
+ XML schema syntax will be stable across releases, libvirt is unable
+ to promise that it will always be able to support usage of the same
+ features across hypervisor releases. Where a hypervisor changes the
+ way a feature is implemented, the project will endeavour to adapt
+ to the new implementation to provide the same semantics. In cases
+ where the feature is discontinued by the hypervisor, libvirt will
+ return an error indicating it is not supported. Likewise libvirt will
+ make reasonable efforts to keep API calls working across hypervisor
+ releases even if the underlying implementation changes. In cases where
+ this is impossible, an suitable error will be reported. The list of
+ APIs which have implementations <a href="hvsupport.html">is detailed separately</a>.
+ </p>
+
+ <h2><a id="rpcproto">RPC protocol</a></h2>
+
+ <p>
+ For some hypervisor drivers, the libvirt.so library communicates with
+ separate libvirt daemons to perform work. This communication takes
+ place over a binary RPC protocol defined by libvirt. The protocol uses
+ the XDR format for data encoding, and the message packet format is
+ defined in libvirt source code.
+ </p>
+ <p>
+ Applications are encouraged to use the primary libvirt.so library which
+ transparently talks to the daemons, so that they are not exposed to the
+ hypervisor driver specific details. None the less, the RPC protocol
+ associated with the libvirtd is considered to be a long term stable ABI.
+ It will only ever have new messages added to it, existing messages will
+ not be removed, nor have their contents changed. Thus if an application
+ does wish to provide its own client side implementation of the RPC
+ protocol this is supported, with the caveat that the application will
+ loose the ability to work with certain hypervisors libvirt supports.
+ The project reserves the right to define new authentication and encryption
+ options for the protocol, and the defaults used in this area may change
+ over time. This is particularly true of the TLS ciphers permitted. Thus
+ applications choosing to implement the RPC protocol must be prepared to
+ track support for new security options. If defaults are changed, however,
+ it will generally be possible to reconfigure the daemon to use the old
+ defaults, albeit with possible implications for system security.
+ </p>
+
+ <p>
+ Other daemons besides, libvirtd, also use the same RPC protocol, but
+ with different message types defined. These RPC protocols are all
+ considered to be private implementations that are liable to change
+ at any time. Applications must not attempt to talk to these other
+ daemons directly.
+ </p>
+
+ <h2><a id="virsh">virsh client</a></h2>
+
+ <p>
+ The virsh program provides a simple client to interact with an arbitrary libvirt
+ hypevisor connection. Since it uses the primary public API of libvirt, it should
+ generally inherit the guarantees associated with that API, and with the hypervisor
+ driver. The commands that virsh exposes, and the arguments they accept are all
+ considered to be long term stable. Existing commands and arguments will not be
+ removed or renamed. New commands and arguments may be added in new releases.
+ The text output format produced by virsh commands is not generally guaranteed to
+ be stable if it contains compound data (eg formatted tables or lists). Commands
+ which output single data items (ie an object name, or an XML document), can be
+ treated as having stable format.
+ </p>
+
+ </body>
+</html>
--
2.14.3
7 years
