[libvirt][RFC PATCH] add a new 'default' option for attribute mode in numatune
by Luyao Zhong
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/f2a1cf9180f63e88bb38ff21c169da97c3f2b...
[2]https://man7.org/linux/man-pages/man2/mbind.2.html
--
2.25.1
4 years, 5 months
[libvirt][PATCH v1 0/3] introduce 'restrictive' mode in numatune
by Luyao Zhong
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
4 years, 5 months
[PATCH v2] gitlab-ci: publish test report as an artifact
by Paolo Bonzini
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
4 years, 5 months
[PATCH] NEWS: Mention network disk support in 'virsh attach-disk'
by Peter Krempa
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
4 years, 5 months
[PATCH] gitlab-ci: publish test report as an artifact
by Paolo Bonzini
"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
4 years, 5 months
[libvirt PATCH 0/2] fix regression in SSH tunnelling performance
by Daniel P. Berrangé
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 years, 5 months
Migration with "--p2p --tunnelled" hanging in v6.9.0
by Christian Ehrhardt
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/5...
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
4 years, 5 months
[libvirt PATCH 0/4] cgroup cpu period and quota fixes
by Pavel Hrdina
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
4 years, 5 months
[PATCH] qemu: Tweak debug message for qemuMigrationSrcPerformPeer2Peer3
by Martin Kletzander
Commit 49186372dbe8 forgot to add the new parameter.
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
---
Pushed as 'trivial'.
src/qemu/qemu_migration.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 4be8f3c64c94..fcb33d0364a1 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -4356,12 +4356,12 @@ qemuMigrationSrcPerformPeer2Peer3(virQEMUDriverPtr driver,
VIR_DEBUG("driver=%p, sconn=%p, dconn=%p, dconnuri=%s, vm=%p, xmlin=%s, "
"dname=%s, uri=%s, graphicsuri=%s, listenAddress=%s, "
- "nmigrate_disks=%zu, migrate_disks=%p, nbdPort=%d, "
+ "nmigrate_disks=%zu, migrate_disks=%p, nbdPort=%d, nbdURI=%s, "
"bandwidth=%llu, useParams=%d, flags=0x%lx",
driver, sconn, dconn, NULLSTR(dconnuri), vm, NULLSTR(xmlin),
NULLSTR(dname), NULLSTR(uri), NULLSTR(graphicsuri),
NULLSTR(listenAddress), nmigrate_disks, migrate_disks, nbdPort,
- bandwidth, useParams, flags);
+ NULLSTR(nbdURI), bandwidth, useParams, flags);
/* Unlike the virDomainMigrateVersion3 counterpart, we don't need
* to worry about auto-setting the VIR_MIGRATE_CHANGE_PROTECTION
--
2.29.2
4 years, 5 months
[libvirt PATCH 0/2] Add more documentation for migrations over UNIX sockets
by Martin Kletzander
Few words about SELinux that might not be very clear to some.
Martin Kletzander (2):
qemu: Disable NBD TLS migration over UNIX socket
docs: Document SELinux caveats when migrating over UNIX sockets
docs/manpages/virsh.rst | 9 ++++++++-
docs/migration.html.in | 9 +++++++++
src/qemu/qemu_migration.c | 10 ++++++++--
3 files changed, 25 insertions(+), 3 deletions(-)
--
2.29.2
4 years, 5 months
