November 2020 - Devel - libvirt List Archives

[libvirt PATCH v4] ci: Switch to meson build system
by Erik Skultety 27 Nov '20

27 Nov '20

Add meson required bits to the ci logic in the repo to be able to run a meson build in a container. This patch also drops several environment variables we don't need with meson anymore. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- v3: https://www.redhat.com/archives/libvir-list/2020-November/msg01293.html Since v3: - further review comments - introduced CI_MESON_ARGS variable ci/Makefile | 38 +++++++------------------------------- ci/build.sh | 29 ++++++----------------------- 2 files changed, 13 insertions(+), 54 deletions(-) diff --git a/ci/Makefile b/ci/Makefile index c7c8eb9a45..d9d14f82c2 100644 --- a/ci/Makefile +++ b/ci/Makefile @@ -20,27 +20,6 @@ CI_HOST_SRCDIR = $(CI_SCRATCHDIR)/src # the $(CI_HOST_SRCDIR) directory from the host CI_CONT_SRCDIR = $(CI_USER_HOME)/libvirt -# Relative directory to perform the build in. This -# defaults to using a separate build dir, but can be -# set to empty string for an in-source tree build. -CI_VPATH = build - -# The directory holding the build output inside the -# container. -CI_CONT_BUILDDIR = $(CI_CONT_SRCDIR)/$(CI_VPATH) - -# Can be overridden with mingw{32,64}-configure if desired -CI_CONFIGURE = $(CI_CONT_SRCDIR)/configure - -# Default to using all possible CPUs -CI_SMP = $(shell getconf _NPROCESSORS_ONLN) - -# Any extra arguments to pass to make -CI_MAKE_ARGS = - -# Any extra arguments to pass to configure -CI_CONFIGURE_ARGS = - # Script containing environment preparation steps CI_PREPARE_SCRIPT = $(CI_ROOTDIR)/prepare.sh @@ -220,13 +199,10 @@ ci-run-command@%: ci-prepare-tree --login \ --user="#$(CI_UID)" \ --group="#$(CI_GID)" \ - CONFIGURE_OPTS="$$CONFIGURE_OPTS" \ + MESON_OPTS="$$MESON_OPTS" \ CI_CONT_SRCDIR="$(CI_CONT_SRCDIR)" \ - CI_CONT_BUILDDIR="$(CI_CONT_BUILDDIR)" \ - CI_SMP="$(CI_SMP)" \ - CI_CONFIGURE="$(CI_CONFIGURE)" \ - CI_CONFIGURE_ARGS="$(CI_CONFIGURE_ARGS)" \ - CI_MAKE_ARGS="$(CI_MAKE_ARGS)" \ + CI_MESON_ARGS="$(CI_MESON_ARGS)" \ + CI_NINJA_ARGS="$(CI_NINJA_ARGS)" \ $(CI_COMMAND) || exit 1' @test "$(CI_CLEAN)" = "1" && rm -rf $(CI_SCRATCHDIR) || : @@ -236,8 +212,8 @@ ci-shell@%: ci-build@%: $(MAKE) -C $(CI_ROOTDIR) ci-run-command@$* CI_COMMAND="$(CI_USER_HOME)/build" -ci-check@%: - $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="check" +ci-test@%: + $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_NINJA_ARGS+=test ci-list-images: @echo @@ -266,6 +242,6 @@ ci-help: @echo " CI_CLEAN=0 - do not delete '$(CI_SCRATCHDIR)' after completion" @echo " CI_REUSE=1 - re-use existing '$(CI_SCRATCHDIR)' content" @echo " CI_ENGINE=auto - container engine to use (podman, docker)" - @echo " CI_CONFIGURE_ARGS= - extra arguments passed to configure" - @echo " CI_MAKE_ARGS= - extra arguments passed to make, e.g. space delimited list of targets" + @echo " CI_MESON_ARGS= - extra arguments passed to meson" + @echo " CI_NINJA_ARGS= - extra arguments passed to ninja" @echo diff --git a/ci/build.sh b/ci/build.sh index 2da84c080a..740b46a935 100644 --- a/ci/build.sh +++ b/ci/build.sh @@ -7,32 +7,15 @@ # # to make. -mkdir -p "$CI_CONT_BUILDDIR" || exit 1 -cd "$CI_CONT_BUILDDIR" +cd "$CI_CONT_SRCDIR" export VIR_TEST_DEBUG=1 -NOCONFIGURE=1 "$CI_CONT_SRCDIR/autogen.sh" || exit 1 -# $CONFIGURE_OPTS is a env that can optionally be set in the container, +# $MESON_OPTS is an env that can optionally be set in the container, # populated at build time from the Dockerfile. A typical use case would -# be to pass --host/--target args to trigger cross-compilation -# -# This can be augmented by make local args in $CI_CONFIGURE_ARGS -"$CI_CONFIGURE" $CONFIGURE_OPTS $CI_CONFIGURE_ARGS -if test $? != 0; then - test -f config.log && cat config.log - exit 1 -fi -find -name test-suite.log -delete +# be to pass options to trigger cross-compilation -make -j"$CI_SMP" $CI_MAKE_ARGS +meson build --werror $MESON_OPTS $CI_MESON_ARGS || \ +(cat build/meson-logs/meson-log.txt && exit 1) -if test $? != 0; then \ - LOGS=$(find -name test-suite.log) - if test "$LOGS"; then - echo "=== LOG FILE(S) START ===" - cat $LOGS - echo "=== LOG FILE(S) END ===" - fi - exit 1 -fi +ninja -C build $CI_NINJA_ARGS -- 2.26.2

2 4

[PATCH] NEWS: add note about virt-ssh-helper perf improvements
by Daniel P. Berrangé 27 Nov '20

27 Nov '20

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- NEWS.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index aa8a217eb6..8245e34efa 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -44,6 +44,13 @@ v6.10.0 (unreleased) * **Bug fixes** + * remote: fixed performance regression in SSH tunnelling + + The virt-ssh-helper binary introduced in 6.9.0 had very + poor scalability which impacted libvirt tunnelled migration + and storage volume upload/download in particular. It has been + updated and now has performance on a par with netcat. + * **Removed features** * hyperv: removed support for the Hyper-V V1 WMI API -- 2.28.0

2 1

[libvirt][RFC PATCH] add a new 'default' option for attribute mode in numatune
by Luyao Zhong 27 Nov '20

27 Nov '20

Hi Libvirt experts, I would like enhence the numatune snippet configuration. Given a example snippet: <domain> ... <numatune> <memory mode="strict" nodeset="1-4,^3"/> <memnode cellid="0" mode="strict" nodeset="1"/> <memnode cellid="2" mode="preferred" nodeset="2"/> </numatune> ... </domain> Currently, attribute mode is either 'interleave', 'strict', or 'preferred', I propose to add a new 'default' option. I give the reason as following. Presume we are using cgroups v1, Libvirt sets cpuset.mems for all vcpu threads according to 'nodeset' in memory element. And translate the memnode element to qemu config options (--object memory-backend-ram) for per numa cell, which invoking mbind() system call at the end.[1] But what if we want using default memory policy and request each guest numa cell pinned to different host memory nodes? We can't use mbind via qemu config options, because (I quoto here) "For MPOL_DEFAULT, the nodemask and maxnode arguments must be specify the empty set of nodes." [2] So my solution is introducing a new 'default' option for attribute mode. e.g. <domain> ... <numatune> <memory mode="default" nodeset="1-2"/> <memnode cellid="0" mode="default" nodeset="1"/> <memnode cellid="1" mode="default" nodeset="2"/> </numatune> ... </domain> If the mode is 'default', libvirt should avoid generating qemu command line '--object memory-backend-ram', and invokes cgroups to set cpuset.mems for per guest numa combining with numa topology config. Presume the numa topology is : <cpu> ... <numa> <cell id='0' cpus='0-3' memory='512000' unit='KiB' /> <cell id='1' cpus='4-7' memory='512000' unit='KiB' /> </numa> ... </cpu> Then libvirt should set cpuset.mems to '1' for vcpus 0-3, and '2' for vcpus 4-7. Is this reasonable and feasible? Welcome any comments. Regards, Luyao [1]https://github.com/qemu/qemu/blob/f2a1cf9180f63e88bb38ff21c169da97c3f2bad… [2]https://man7.org/linux/man-pages/man2/mbind.2.html -- 2.25.1

4 25

[libvirt][PATCH v1 0/3] introduce 'restrictive' mode in numatune
by Luyao Zhong 27 Nov '20

27 Nov '20

Before this patch set, numatune only has three memory modes: static, interleave and prefered. These memory policies are ultimately set by mbind() system call. Memory policy could be 'hard coded' into the kernel, but none of above policies fit our requirment under this case. mbind() support default memory policy, but it requires a NULL nodemask. So obviously setting allowed memory nodes is cgroups' mission under this case. So we introduce a new option for mode in numatune named 'restrictive'. <numatune> <memory mode="restrictive" nodeset="1-4,^3"/> <memnode cellid="0" mode="restrictive" nodeset="1"/> <memnode cellid="2" mode="restrictive" nodeset="2"/> </numatune> The config above means we only use cgroups to restrict the allowed memory nodes and not setting any specific memory policies explicitly. RFC discussion: https://www.redhat.com/archives/libvir-list/2020-November/msg01256.html Regards, Luyao Luyao Zhong (3): docs: add docs for 'restrictive' option for mode in numatune schema: add 'restrictive' config option for mode in numatune qemu: add parser and formatter for 'restrictive' mode in numatune docs/formatdomain.rst | 7 +++- docs/schemas/domaincommon.rng | 2 + include/libvirt/libvirt-domain.h | 1 + src/conf/numa_conf.c | 9 +++++ src/qemu/qemu_command.c | 6 ++- src/qemu/qemu_process.c | 27 +++++++++++++ src/util/virnuma.c | 3 ++ .../numatune-memnode-invalid-mode.err | 1 + .../numatune-memnode-invalid-mode.xml | 33 +++++++++++++++ ...emnode-restrictive-mode.x86_64-latest.args | 40 +++++++++++++++++++ .../numatune-memnode-restrictive-mode.xml | 33 +++++++++++++++ tests/qemuxml2argvtest.c | 2 + ...memnode-restrictive-mode.x86_64-latest.xml | 40 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 14 files changed, 202 insertions(+), 3 deletions(-) create mode 100644 tests/qemuxml2argvdata/numatune-memnode-invalid-mode.err create mode 100644 tests/qemuxml2argvdata/numatune-memnode-invalid-mode.xml create mode 100644 tests/qemuxml2argvdata/numatune-memnode-restrictive-mode.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/numatune-memnode-restrictive-mode.xml create mode 100644 tests/qemuxml2xmloutdata/numatune-memnode-restrictive-mode.x86_64-latest.xml -- 2.25.4

1 3

[PATCH v2] gitlab-ci: publish test report as an artifact
by Paolo Bonzini 26 Nov '20

26 Nov '20

Since version 0.55, "meson test" produces JUnit XML in the meson-logs directory. The XML can be parsed by GitLab and showed as part of the CI report. However, if the build and tests are performed by "meson dist", the tests are performed in "meson dist"'s own build directory and the logs are not accessible. So switch from "ninja dist" to "meson dist --no-tests" after a separate build step that is shared by the normal and the DIST=skip cases. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- v1->v2: only do it for new-enough distros For an example see https://gitlab.com/bonzini/libvirt/-/pipelines/221545357/test_report. Test durations however are not yet available in upstream Meson. --- .gitlab-ci.yml | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6792accf8f..c4b54201f8 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -40,6 +40,36 @@ stages: <<: *container_job_definition allow_failure: true +# For new enough distros that have Meson 0.55, include the JUnit XML +# report in the artifacts. In order to preserve it, we cannot use +# "meson dist" and need to do the compilation test manually. +# Fortunately, "meson dist --no-tests" was also added in Meson 0.55. +.native_meson055_build_job_template: &native_meson055_build_job_definition + stage: builds + image: $CI_REGISTRY_IMAGE/ci-$NAME:latest + cache: + paths: + - ccache/ + key: "$CI_JOB_NAME" + before_script: + - *script_variables + script: + - meson build --werror || (cat build/meson-logs/meson-log.txt && exit 1) + - ninja -C build + - ninja -C build test + - DESTDIR=$PWD/install/ ninja -C build install + - meson dist -C build --no-tests + - if test -x /usr/bin/rpmbuild && test "$RPM" != "skip"; + then + rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz; + fi + artifacts: + when: always + paths: + - build/meson-logs/ + reports: + junit: build/meson-logs/testlog.junit.xml + .native_build_job_template: &native_build_job_definition stage: builds image: $CI_REGISTRY_IMAGE/ci-$NAME:latest @@ -292,7 +322,7 @@ x64-debian-10-clang: CC: clang x64-debian-sid: - <<: *native_build_job_definition + <<: *native_meson055_build_job_definition needs: - x64-debian-sid-container variables: @@ -343,21 +373,21 @@ x64-fedora-31: RPM: skip x64-fedora-32: - <<: *native_build_job_definition + <<: *native_meson055_build_job_definition needs: - x64-fedora-32-container variables: NAME: fedora-32 x64-fedora-rawhide: - <<: *native_build_job_definition + <<: *native_meson055_build_job_definition needs: - x64-fedora-rawhide-container variables: NAME: fedora-rawhide x64-fedora-rawhide-clang: - <<: *native_build_job_definition + <<: *native_meson055_build_job_definition needs: - x64-fedora-rawhide-container variables: -- 2.28.0

1 0

[PATCH] NEWS: Mention network disk support in 'virsh attach-disk'
by Peter Krempa 26 Nov '20

26 Nov '20

Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index aa8a217eb6..8c2b5def0f 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -42,6 +42,14 @@ v6.10.0 (unreleased) * **Improvements** + * virsh: Support network disks in ``virsh attach-disk`` + + The ``virsh attach-disk`` helper command which simplifies attaching of disks + without the need for the user to formulate the disk XML manually now + supports network-backed images. Users can specify the protocol and host + specification with new command line arguments. Please refer to the man + page of virsh for further information. + * **Bug fixes** * **Removed features** -- 2.28.0

2 1

[PATCH] gitlab-ci: publish test report as an artifact
by Paolo Bonzini 26 Nov '20

26 Nov '20

"meson test" produces JUnit XML in the meson-logs directory. The XML can be parsed by GitLab and showed as part of the CI report. However, if the build and tests are performed by "meson dist", the tests are performed in "meson dist"'s own build directory and the logs are not accessible. So switch from "ninja dist" to "meson dist --no-tests" after a separate build step that is shared by the normal and the DIST=skip cases. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- For an example see https://gitlab.com/bonzini/libvirt/-/pipelines/221545357/test_report. Test durations however are not yet available in upstream Meson. --- .gitlab-ci.yml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6792accf8f..ce7b60dc6b 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -51,17 +51,23 @@ stages: - *script_variables script: - meson build --werror || (cat build/meson-logs/meson-log.txt && exit 1) + - ninja -C build + - ninja -C build test + - DESTDIR=$PWD/install/ ninja -C build install - if test "$DIST" != "skip"; then - ninja -C build dist; - else - ninja -C build; - ninja -C build test; + meson dist -C build --no-tests; fi - if test -x /usr/bin/rpmbuild && test "$RPM" != "skip"; then rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz; fi + artifacts: + when: always + paths: + - build/meson-logs/ + reports: + junit: build/meson-logs/testlog.junit.xml # Jobs that we delegate to Cirrus CI because they require an operating # system other than Linux. These jobs will only run if the required -- 2.28.0

1 0

[libvirt PATCH 0/2] fix regression in SSH tunnelling performance
by Daniel P. Berrangé 26 Nov '20

26 Nov '20

In testing the "vol-download" command in virsh, downloading a 1G file takes a ridiculous amount of time (minutes) with the new SSH helper. After the first patch is applied the time gets down to a much more reasonable 5.5 seconds on my test machine. By comparison netcat achieved 4 seconds. After applying the second patch, the time is reduced to 3.5 seconds, so we actually end up beating netcat, as long as we have glib >= 2.64.0 available. Daniel P. Berrangé (2): remote: make ssh-helper massively faster util: avoid glib event loop workaround where possible src/remote/remote_ssh_helper.c | 113 ++++++++++++++++++++------------- src/util/vireventglib.c | 29 ++++++--- 2 files changed, 89 insertions(+), 53 deletions(-) -- 2.25.4

4 8

Migration with "--p2p --tunnelled" hanging in v6.9.0
by Christian Ehrhardt 26 Nov '20

26 Nov '20

Hi, I'm wondering about the best next steps to debug a migration issue. What I found is that with libvirt v6.9.0 a migration hangs if used like: $ virsh migrate --unsafe --live --p2p --tunnelled h-migr-test \ qemu+ssh://testkvm-hirsute-to/system Just "--live --p2p" works fine. Also a bunch of other migration option combinations work with the same build/setup, just p2p+tunnelled fails. Also if either source or target are not on 6.9 the migration works (former version used is v6.6 for me). I looked at alternating qemu versions (5.0 / 5.1), but it had no impact. It only depends on libvirt to be on the new version on source&target to trigger the issue. Unfortunately there is no crash or error to debug into, it just gets stuck with the "virsh migrate" hanging on the source and never leaving the "paused" state on the target. I have compared setups with the least amount of "change": good: Qemu 5.1 + Libvirt 6.9 -> Qemu 5.1 / Libvirt 6.6 bad: Qemu 5.1 + Libvirt 6.9 -> Qemu 5.1 / Libvirt 6.9 [1] has the debug logs of those, beginning with a libvirtd restart that one can likely skip and then into the migration that hangs in the bad case. But I failed to see an obvious reason in the log. In git/news I only found these changes which sounded to be relevant: f51cbe92c0 qemu: Allow migration over UNIX socket c69915ccaf peer2peer migration: allow connecting to local sockets But I'm not using unix: and in the logs the only unix: mentions are for the qemu monitor and qemu-guest-agent. I wanted to ask: - if something related was recently changed that comes to mind? - if someone else sees anything in the linked logs that I missed? - if someone else has seen/reproduced the same? - for best practise to debug a hanging migration Thanks in advance! [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1904584/+attachment/543… -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd

3 12

[libvirt PATCH 0/4] cgroup cpu period and quota fixes
by Pavel Hrdina 25 Nov '20

25 Nov '20

Pavel Hrdina (4): qemu: move cgroup cpu period and quota defines to vircgroup.h vircgroupv1: use defines for cpu period and quota limits vircgroupv2: use defines for cpu period and quota limits vircgroup: fix cpu quota maximum limit src/qemu/qemu_driver.c | 21 ++++++++------------- src/util/vircgroup.h | 7 +++++++ src/util/vircgroupv1.c | 23 ++++++++++++----------- src/util/vircgroupv2.c | 25 +++++++++++++------------ 4 files changed, 40 insertions(+), 36 deletions(-) -- 2.26.2

2 5