Remove the libvirt-daemon dependency from the various
libvirt-daemon-<hypervisor> subpackages, replacing it with a set of the
new sub subpackages providing similar functionality. When libvirt is build
with modular daemons, the hypervisor subpackages no longer include the
traditional, monolithic libvirt daemon.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
To avoid needlessly installing the monolithic daemon, replace the
libvirt-daemon dependency with libvirt-daemon-common in the primary
drivers.
The qemu driver also needs a dependency on libvirt-daemon-log since
the virtqemud systemd service file has a hard dependency on
virtlogd.socket.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The systemd service files of the qemu and libxl driver currently have a
'Requires' dependency on virtlockd, which is too strong since virtlockd
is not enabled by default in either driver. Change the dependency to a
'Wants' to avoid a package dependency between the driver subpackages and
the new libvirt-daemon-lock subpackage.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
To avoid needlessly installing the monolithic daemon, replace the
libvirt-daemon dependency with libvirt-daemon-common in the secondary
drivers. The common subpackage contains all the utilities and files
needed by the secondary drivers.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Both drivers use numad via virNumaGetAutoPlacementAdvice. Drop the numad
dependency from libvirt-daemon-common to avoid enforcing it all users of
the subpackage.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Only the nodedev and lxc drivers require module-init-tools. Remove the
dependency from libvirt-daemon-common and add it to the nodedev and lxc
drivers. This avoids enforcing the dependency on all users of
libvirt-daemon-common.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduce a new subpackage libvirt-daemon-common and move virt-admin,
virt-host-validate, virt-ssh-helper, libvirt-guests and miscellaneous
files/directories to it. Also move common dependencies to the new
subpackage. These files, utilities, and dependecies are used by other
core libvirt daemons
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The new name "libvirt-daemon-plugin-sanlock" provides consistency with the
newly introduced "libvirt-daemon-plugin-lockd" subpackage.
It's also a good opportunity to taking ownership of
%{_libdir}/libvirt/lock-driver/, removing the need for a dependency on the
libvirt-daemon package.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce the libvirt-daemon-plugin-lockd subpackage to provide the
client-side lockd plugin for virtlockd.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Commit 379c0ce4bf introduced a call to umount(/dev) performed
inside the namespace that we run QEMU in.
As a result of this, on machines using AppArmor, VM startup now
fails with
internal error: Process exited prior to exec: libvirt:
QEMU Driver error: failed to umount devfs on /dev: Permission denied
The corresponding denial is
AVC apparmor="DENIED" operation="umount" profile="libvirtd"
name="/dev/" pid=70036 comm="rpc-libvirtd"
Extend the AppArmor configuration for virtqemud and libvirtd so
that this operation is allowed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
The CURLOPT_PUT constant causes a deprecation warning when compiling on
Alpine Edge. The docs indicate it is deprecated since 7.2.1
https://curl.se/libcurl/c/CURLOPT_PUT.html
Since 7.87 the deprecation is now exposed at build time via a compiler
warning.
We already use CURLOPT_UPLOAD in the ESX driver, so this brings the CH
driver into line.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This fixes a bug in
commit fda53ab3a5
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Dec 22 10:29:32 2022 -0500
remote: use VIR_LOCK_GUARD in client code
Reviewed-by: Erik Skultety <eskultet@redhat>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a more concise approach and guarantees there is
no time window where the struct is uninitialized.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a more concise approach and guarantees there is
no time window where the struct is uninitialized.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a more concise approach and guarantees there is
no time window where the struct is uninitialized.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using VIR_LOCK_GUARD enables the 'done' goto label to be
eliminated.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using VIR_LOCK_GUARD enables the 'done' goto label to be
eliminated.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using VIR_LOCK_GUARD helps to simplify the control flow
logic.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Every enum/struct/union implicitly includes a typedef in the
emitted C code. Furthermore, the syntax used to declare the
redundant typedef is not compliant with the XDR spec.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The RFC spec for XDR does not allow enums to omit their
values, they must be explicitly given. Don't rely on this
rpcgen language extension.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Every member of the args variable will be initialized
explicitly. A few methods had a redundant call to memset
the args which can be removed.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The limits are different with cgroups v1 and v2 but our XML
documentation and virsh manpage mentioned only cgroups v1 limits without
explicitly saying it only applies to cgroups v1.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This check is done when VM is defined but doesn't take into account what
cgroups version is currently used on the host system so it doesn't work
correctly.
To make proper check at this point we would have to figure out cgroups
version while defining a VM but that will still not guarantee that the
VM will start correctly in the future as the host may be rebooted with
different cgroups version.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The cgroup v2 cpu.weight limits are different than cgroup v1 cpu.shares
limits.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Note that with the introduction of SPDX, Fedora no longer wants
maintainers to do effective license analysis, hence we now list
all the licenses that are applicable to the binary package
contents
https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis
Note, we can still omit licenses that are only applicable to
the build system.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
net-user-passt.args was generated early during testing of the passt
qemu commandline, when qemuxml2argvtest was using
DO_TEST("net-user-passt"). This was later changed to
DO_TEST_CAPS_LATEST(), so the file net-user-passt.x86_64-latest.args
is used instead, but the original (now unused) test file was
accidentally added to the original patch. This patch removes it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This commented-out option was pointed out by jtomko during review, but
I missed taking it out when addressing his comments.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This attribute was added to support setting the --interface option for
passt, but in a post-push/pre-9.0-release review, danpb pointed out
that it would be better to use the existing <source dev='xxx'/>
attribute to set --interface rather than creating a new attribute (in
the wrong place). So we remove backend/upstream, and change the passt
commandline creation to grab the name for --interface from source/dev.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Currently, the ThreadContext object is generated whenever we see
.host-nodes attribute for a memory-backend-* object. The idea was
that when the backend is pinned to a specific set of host NUMA
nodes, then the allocation could be happening on CPUs from those
nodes too. But this may not be always possible.
Users might configure their guests in such way that vCPUs and
corresponding guest NUMA nodes are on different host NUMA nodes
than emulator thread. In this case, ThreadContext won't work,
because ThreadContext objects live in context of the emulator
thread (vCPU threads are moved around by us later, when emulator
thread finished its setup and spawned vCPU threads - see
qemuProcessSetupVcpus()). Therefore, memory allocation is done by
emulator thread which is pinned to a subset of host NUMA nodes,
but tries to create a ThreadContext object with a disjoint subset
of host NUMA nodes, which fails.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2154750
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For SGX type of memory, QEMU needs to open and talk to
/dev/sgx_vepc and /dev/sgx_provision files. But we do not set nor
restore SELinux labels on these files when starting a guest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Because of kernel doesn't allow passing negative values to
cpu.max as quota, it's needing to convert negative values to "max" token.
Signed-off-by: Anton Fadeev <anton.fadeev@red-soft.ru>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The default expiry time is 30 days. Since the RPM artifacts coming from
the previous pipeline stages are set to expire in 1 day we can set the
failed integration job log artifacts to the same value. The sentiment
here is that if an integration job legitimately failed (i.e. not with
an infrastructure failure) unless it was fixed in the meantime it will
fail the next day with the scheduled pipeline again, meaning, that even
if the older log artifacts are removed, they'll be immediately
replaced with fresh ones.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jumping to the error label and reading the pidfile does not make sense
until we reached qemuSecurityCommandRun which creates the pidfile.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The pidfile is guaranteed to be non-NULL (thanks to glib allocation
functions) and it's dereferenced two lines above anyway.
Reported by coverity:
/src/qemu/qemu_passt.c: 278 in qemuPasstStart()
272 return 0;
273
274 error:
275 ignore_value(virPidFileReadPathIfLocked(pidfile, &pid));
276 if (pid != -1)
277 virProcessKillPainfully(pid, true);
>>> CID 404360: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "pidfile" suggests that it may be null, but it
>>> has already been dereferenced on all paths leading to the check.
278 if (pidfile)
279 unlink(pidfile);
280
281 return -1;
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
In our current code the function is not called with NULL argument, but
we should follow our common practice and make it safe anyway.
Reported by coverity:
/src/conf/domain_conf.c: 2635 in virDomainNetPortForwardFree()
2629 {
2630 size_t i;
2631
2632 if (pf)
2633 g_free(pf->dev);
2634
>>> CID 404359: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "pf".
2635 for (i = 0; i < pf->nRanges; i++)
2636 g_free(pf->ranges[i]);
2637
2638 g_free(pf->ranges);
2639 g_free(pf);
2640 }
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
