[PATCH] rpm: Remove pointless explicit dependency on 'readline'
by Neal Gompa
The 'readline' package only contains the library, which rpm is
already generating the (stricter) correct dependency for.
Signed-off-by: Neal Gompa <ngompa13(a)gmail.com>
---
libvirt.spec.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index d124a7ce45..379cf0d9be 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -891,7 +891,6 @@ capabilities of VirtualBox
%package client
Summary: Client side utilities of the libvirt library
Requires: %{name}-libs = %{version}-%{release}
-Requires: readline
# Needed by /usr/libexec/libvirt-guests.sh script.
Requires: gettext
# Needed by virt-pki-validate script.
@@ -918,7 +917,6 @@ Shared libraries for accessing the libvirt daemon.
%package admin
Summary: Set of tools to control libvirt daemon
Requires: %{name}-libs = %{version}-%{release}
-Requires: readline
%if %{with_bash_completion}
Requires: %{name}-bash-completion = %{version}-%{release}
%endif
--
2.26.2
4 years, 2 months
[PATCH] wireshark: Prefer ws_version.h over config.h
by Michal Privoznik
A wireshark plugin must declare what major and minor version it
was built with as these are checked when wireshark loads plugins.
On the top of that, we use major + minor + micro to adapt to
changed API between releases. So far, we were getting these
version numbers from wireshark/config.h.
And while most distributions install wireshark/config.h file some
don't. On distros shipping it it's hack^Wsaved during built by
packaging system and installed later. But some distros are not
doing that. At least not for new enough wireshark because as of
wireshark's commit v2.9.0~1273 the ws_version.h is installed
which contains the version macros we need and is installed by
wireshark itself.
But of course, some distros which have new enough wireshark
packaged do not ship ws_version.h and stick to the hack. That is
why we can't simply bump the minimal version and switch to the
new header file. We need a configure check and adopt our code to
deal with both ways. At least for the time being.
Based on Andrea's original patch:
https://www.redhat.com/archives/libvir-list/2020-September/msg00156.html
Closes: https://gitlab.com/libvirt/libvirt/-/issues/74
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
meson.build | 6 ++++++
tools/wireshark/src/packet-libvirt.c | 1 -
tools/wireshark/src/plugin.c | 21 +++++++++++++++------
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/meson.build b/meson.build
index 1eadea33bf..33eaa9ff56 100644
--- a/meson.build
+++ b/meson.build
@@ -1472,6 +1472,12 @@ if wireshark_dep.found()
# Since wireshark 2.5.0 plugins can't live in top level plugindir but have
# to be under one of ["epan", "wiretap", "codecs"] subdir. The first one looks okay.
wireshark_plugindir = wireshark_plugindir / 'epan'
+
+ # Wireshark is installing ws_version.h since v2.9.0, but some distributions
+ # are not shipping it.
+ if cc.has_header('wireshark/ws_version.h')
+ conf.set('WITH_WS_VERSION', 1)
+ endif
endif
# On MinGW portablexdr provides XDR functions, on linux they are
diff --git a/tools/wireshark/src/packet-libvirt.c b/tools/wireshark/src/packet-libvirt.c
index 9f3c7f650d..965f1f5482 100644
--- a/tools/wireshark/src/packet-libvirt.c
+++ b/tools/wireshark/src/packet-libvirt.c
@@ -18,7 +18,6 @@
*/
#include <config.h>
-#include <wireshark/config.h>
#include <wireshark/epan/proto.h>
#include <wireshark/epan/packet.h>
#include <wireshark/epan/dissectors/packet-tcp.h>
diff --git a/tools/wireshark/src/plugin.c b/tools/wireshark/src/plugin.c
index 504e4383a7..13af1b6a73 100644
--- a/tools/wireshark/src/plugin.c
+++ b/tools/wireshark/src/plugin.c
@@ -14,7 +14,16 @@
#include <gmodule.h>
-#include <wireshark/config.h>
+#ifdef WITH_WS_VERSION
+# include <wireshark/ws_version.h>
+#else
+# include <wireshark/config.h>
+# define WIRESHARK_VERSION_MAJOR VERSION_MAJOR
+# define WIRESHARK_VERSION_MINOR VERSION_MINOR
+# define WIRESHARK_VERSION_MICRO VERSION_MICRO
+#endif
+
+#define HAVE_PLUGINS 1
#include <wireshark/epan/proto.h>
/* plugins are DLLs */
#define WS_BUILD_DLL
@@ -26,9 +35,9 @@
#define PLUGIN_VERSION VERSION
#define WIRESHARK_VERSION \
- ((VERSION_MAJOR * 1000 * 1000) + \
- (VERSION_MINOR * 1000) + \
- (VERSION_MICRO))
+ ((WIRESHARK_VERSION_MAJOR * 1000 * 1000) + \
+ (WIRESHARK_VERSION_MINOR * 1000) + \
+ (WIRESHARK_VERSION_MICRO))
#if WIRESHARK_VERSION < 2005000
@@ -69,8 +78,8 @@ void proto_register_libvirt(void);
void proto_reg_handoff_libvirt(void);
WS_DLL_PUBLIC_DEF const gchar plugin_version[] = PLUGIN_VERSION;
-WS_DLL_PUBLIC_DEF const int plugin_want_major = VERSION_MAJOR;
-WS_DLL_PUBLIC_DEF const int plugin_want_minor = VERSION_MINOR;
+WS_DLL_PUBLIC_DEF const int plugin_want_major = WIRESHARK_VERSION_MAJOR;
+WS_DLL_PUBLIC_DEF const int plugin_want_minor = WIRESHARK_VERSION_MINOR;
WS_DLL_PUBLIC void plugin_register(void);
--
2.26.2
4 years, 2 months
[PATCH] virnuma: Report error when NUMA -> CPUs translation fails
by Michal Privoznik
When starting a domain with <numatune/> set libvirt translates
given NUMA nodes into a set of host CPUs which is then used to
QEMU process affinity. But, if the numatune contains a
non-existent NUMA node then the translation fails with no error
reported. This is because virNumaNodesetToCPUset() calls
virNumaGetNodeCPUs() and expects it to report an error on
failure. Well, it does except for non-existent NUMA nodes. While
this behaviour might look strange it is actually desired because
of how we construct host capabilities. The virNumaGetNodeCPUs()
is called from virCapabilitiesHostNUMAInitReal() where we do not
want any error reported for non-existent NUMA nodes.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1724866
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/util/virnuma.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/util/virnuma.c b/src/util/virnuma.c
index ba1e4363d6..2872ce3c5e 100644
--- a/src/util/virnuma.c
+++ b/src/util/virnuma.c
@@ -316,12 +316,21 @@ virNumaNodesetToCPUset(virBitmapPtr nodeset,
for (i = 0; i < nodesetSize; i++) {
g_autoptr(virBitmap) nodeCPUs = NULL;
+ int rc;
if (!virBitmapIsBitSet(nodeset, i))
continue;
- if (virNumaGetNodeCPUs(i, &nodeCPUs) < 0)
+ rc = virNumaGetNodeCPUs(i, &nodeCPUs);
+ if (rc < 0) {
+ /* Error is reported for cases other than non-existent NUMA node. */
+ if (rc == -2) {
+ virReportError(VIR_ERR_OPERATION_FAILED,
+ _("NUMA node %zu is not available"),
+ i);
+ }
return -1;
+ }
if (virBitmapUnion(allNodesCPUs, nodeCPUs) < 0)
return -1;
--
2.26.2
4 years, 2 months
[RFC PATCH 0/3] qemu: Propagate cluster size to new qcow2 images
by Peter Krempa
Cluster size may have performatnce implications. Propagate the cluster
size used by the original image to any copy or overlay.
Peter Krempa (3):
qemu: monitor: Detect image cluster size from
'query-named-block-nodes'
qemu: block: Allow specifying cluster size when using
'blockdev-create'
qemuBlockStorageSourceCreateDetectSize: Propagate cluster size for
'qcow2'
src/qemu/qemu_block.c | 6 ++++++
src/qemu/qemu_monitor.h | 3 +++
src/qemu/qemu_monitor_json.c | 3 +++
src/util/virstoragefile.h | 1 +
4 files changed, 13 insertions(+)
--
2.26.2
4 years, 2 months
[PATCH] qemu_process: Separate VIR_PERF_EVENT_* setting into a function
by Michal Privoznik
When starting a domain, qemuProcessLaunch() iterates over all
VIR_PERF_EVENT_* values and (possibly) enables them. While there
is nothing wrong with the code, the for loop where its done makes
it harder to jump onto next block of code.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Is this trivial enough to be pushed as such?
src/qemu/qemu_process.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 6b1644880a..dd60fb0ddf 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -6700,6 +6700,25 @@ qemuProcessEnableDomainNamespaces(virQEMUDriverPtr driver,
}
+static int
+qemuProcessEnablePerf(virDomainObjPtr vm)
+{
+ qemuDomainObjPrivatePtr priv = vm->privateData;
+ size_t i;
+
+ if (!(priv->perf = virPerfNew()))
+ return -1;
+
+ for (i = 0; i < VIR_PERF_EVENT_LAST; i++) {
+ if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES &&
+ virPerfEventEnable(priv->perf, i, vm->pid) < 0)
+ return -1;
+ }
+
+ return 0;
+}
+
+
/**
* qemuProcessLaunch:
*
@@ -6733,7 +6752,6 @@ qemuProcessLaunch(virConnectPtr conn,
g_autoptr(virQEMUDriverConfig) cfg = NULL;
size_t nnicindexes = 0;
g_autofree int *nicindexes = NULL;
- size_t i;
VIR_DEBUG("conn=%p driver=%p vm=%p name=%s if=%d asyncJob=%d "
"incoming.launchURI=%s incoming.deferredURI=%s "
@@ -6885,15 +6903,10 @@ qemuProcessLaunch(virConnectPtr conn,
if (qemuSetupCgroup(vm, nnicindexes, nicindexes) < 0)
goto cleanup;
- if (!(priv->perf = virPerfNew()))
+ VIR_DEBUG("Setting up domain perf (if required)");
+ if (qemuProcessEnablePerf(vm) < 0)
goto cleanup;
- for (i = 0; i < VIR_PERF_EVENT_LAST; i++) {
- if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES &&
- virPerfEventEnable(priv->perf, i, vm->pid) < 0)
- goto cleanup;
- }
-
/* This must be done after cgroup placement to avoid resetting CPU
* affinity */
if (qemuProcessInitCpuAffinity(vm) < 0)
--
2.26.2
4 years, 2 months
[RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
by Alex Bennée
It's buggy and we are not sure anyone uses it.
Cc: David Gibson <david(a)gibson.dropbear.id.au>
Cc: Richard Henderson <rth(a)twiddle.net>
Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org>
---
docs/system/deprecated.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 851dbdeb8ab..11c763383d9 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -424,6 +424,15 @@ linux-user mode) is deprecated and will be removed in a future version
of QEMU. Support for this CPU was removed from the upstream Linux
kernel in 2018, and has also been dropped from glibc.
+``ppc64abi32`` CPUs (since 5.2.0)
+'''''''''''''''''''''''''''''''''
+
+The ``ppc64abi32`` architecture has a number of issues which regularly
+trip up our CI testing and is suspected to be quite broken.
+Furthermore the maintainers are unsure what the correct behaviour
+should be and strongly suspect no one actually uses it.
+
+
Related binaries
----------------
--
2.20.1
4 years, 2 months
[PATCH] news: add 1 improvement for v6.6.0
by Yanqiu Zhang
Support TLS for NBD connections for pull mode backup.
Signed-off-by: Yanqiu Zhang <yanqzhan(a)redhat.com>
---
NEWS.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e4b71e6563..d0b16e28fc 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -161,6 +161,12 @@ v6.6.0 (2020-08-02)
The secret key used for disks can now be encrypted similarly to TLS keys
used for migration, chardev and others.
+ * qemu: Support TLS for NBD connections for pull mode backup
+
+ Use the configured TLS env to setup encryption of the TLS transport. Add 'tls'
+ attribute for 'server' element to enable tls. Possible values are ``yes``
+ or ``no``.
+
* qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>``
The event can now be used also for block copy destinations by using the
--
2.25.4
4 years, 2 months
[PATCH] Revert "news: qemu: Support TLS for NBD connections for pull mode backup"
by Peter Krempa
Incremental backups are not enabled. There's no point documenting
individual patches implementing an incomplete feature.
This reverts commit e6285f84faeacccdef12b69a7bc38975230d6662.
---
NEWS.rst | 6 ------
1 file changed, 6 deletions(-)
diff --git a/NEWS.rst b/NEWS.rst
index 008a6358c6..14f098b1f6 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -167,12 +167,6 @@ v6.6.0 (2020-08-02)
The secret key used for disks can now be encrypted similarly to TLS keys
used for migration, chardev and others.
- * qemu: Support TLS for NBD connections for pull mode backup
-
- Use the configured TLS env to setup encryption of the TLS transport. Add
- 'tls' attribute for 'server' element to enable TLS. Possible values are
- ``yes`` or ``no``.
-
* qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>``
The event can now be used also for block copy destinations by using the
--
2.26.2
4 years, 2 months
[libvirt PATCH] wireshark: Don't include config.h
by Andrea Bolognani
While both Debian and Fedora include the header in their development
packages for Wireshark, that's not something that the upstream
developers intended and arguably quite wrong, as config.h is obviously
intended to only be used to drive the compilation of Wireshark itself.
The Arch Linux package behaves like the upstream Wireshark package, and
thus libvirt fails to build there.
It seems that there are multiple bugs to be addressed:
* libvirt shouldn't include config.h;
* Debian and Fedora shouldn't be shipping config.h in their Wireshark
packages;
* Wireshark should not use config.h defines such as HAVE_PLUGINS in
its public headers, and define a public variant of them instead.
This patch takes care of the first one.
https://gitlab.com/libvirt/libvirt/-/issues/74
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
tools/wireshark/src/packet-libvirt.c | 1 -
tools/wireshark/src/plugin.c | 13 +++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/wireshark/src/packet-libvirt.c b/tools/wireshark/src/packet-libvirt.c
index 9f3c7f650d..965f1f5482 100644
--- a/tools/wireshark/src/packet-libvirt.c
+++ b/tools/wireshark/src/packet-libvirt.c
@@ -18,7 +18,6 @@
*/
#include <config.h>
-#include <wireshark/config.h>
#include <wireshark/epan/proto.h>
#include <wireshark/epan/packet.h>
#include <wireshark/epan/dissectors/packet-tcp.h>
diff --git a/tools/wireshark/src/plugin.c b/tools/wireshark/src/plugin.c
index 504e4383a7..3c6fae9ef5 100644
--- a/tools/wireshark/src/plugin.c
+++ b/tools/wireshark/src/plugin.c
@@ -14,11 +14,12 @@
#include <gmodule.h>
-#include <wireshark/config.h>
+#define HAVE_PLUGINS 1
#include <wireshark/epan/proto.h>
/* plugins are DLLs */
#define WS_BUILD_DLL
#include <wireshark/ws_symbol_export.h>
+#include <wireshark/ws_version.h>
#include "packet-libvirt.h"
@@ -26,9 +27,9 @@
#define PLUGIN_VERSION VERSION
#define WIRESHARK_VERSION \
- ((VERSION_MAJOR * 1000 * 1000) + \
- (VERSION_MINOR * 1000) + \
- (VERSION_MICRO))
+ ((WIRESHARK_VERSION_MAJOR * 1000 * 1000) + \
+ (WIRESHARK_VERSION_MINOR * 1000) + \
+ (WIRESHARK_VERSION_MICRO))
#if WIRESHARK_VERSION < 2005000
@@ -69,8 +70,8 @@ void proto_register_libvirt(void);
void proto_reg_handoff_libvirt(void);
WS_DLL_PUBLIC_DEF const gchar plugin_version[] = PLUGIN_VERSION;
-WS_DLL_PUBLIC_DEF const int plugin_want_major = VERSION_MAJOR;
-WS_DLL_PUBLIC_DEF const int plugin_want_minor = VERSION_MINOR;
+WS_DLL_PUBLIC_DEF const int plugin_want_major = WIRESHARK_VERSION_MAJOR;
+WS_DLL_PUBLIC_DEF const int plugin_want_minor = WIRESHARK_VERSION_MINOR;
WS_DLL_PUBLIC void plugin_register(void);
--
2.26.2
4 years, 2 months
[libvirt PATCH 0/2] Fix IPv6 network startup after removal of "dummy" tap device
by Laine Stump
After the patch that removed the dummy tap device was added (commit
ee6c936fbb), IPv6 networks would no longer start due to a "failure to
complete DAD". Since this wait was only necessary because of the
existence of the dummy tap device (see detailed git log spelunking in
Patch 1 comment), we can just remove the wait.
Laine Stump (2):
network: don't wait for IPv6 DAD completion when starting a network
util: remove unused virNetDevIPWaitDadFinish()
src/libvirt_private.syms | 1 -
src/network/bridge_driver.c | 32 ----------
src/util/virnetdevip.c | 119 ------------------------------------
src/util/virnetdevip.h | 2 -
4 files changed, 154 deletions(-)
--
2.26.2
4 years, 2 months
