Tim Wiederhake [Fri, 23 Apr 2021 10:37:32 +0000 (12:37 +0200)]
virXMLPropEnum: Fix return value
Function incorrectly returns 0 when property was successfully read.
Fixes: ab5d2776c925ec45eb54ec5432f5645cebb80c85 Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 23 Apr 2021 08:05:50 +0000 (10:05 +0200)]
qemu: Don't double free @node_cpus in qemuProcessSetupPid()
When placing vCPUs into CGroups the qemuProcessSetupPid() is
called which then enters a for() loop (around its middle) where
it calls virDomainNumaGetNodeCpumask() for each guest NUMA node.
But the latter returns only a pointer not new reference/copy and
thus the caller must not free it. But the variable is decorated
with g_autoptr() which leads to a double free.
Fixes: 2d37d8dbc987d1998b4ad8029ba324b6bfe49799 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 20 Apr 2021 08:33:03 +0000 (10:33 +0200)]
lxc: Let the driver detect CGroups earlier
This is the bug I'm facing. I deliberately configured a container
so that the source of a <filesystem/> to passthrough doesn't
exist. The start fails with:
lxcContainerPivotRoot:669 : Failed to create /non-existent/path/.oldroot: Permission denied
which is expected. But what is NOT expected is that CGroup
hierarchy is left behind. This is because the controller sets up
the CGroup hierarchy, user namespace, moves interfaces, etc. and
finally checks whether container setup (done in a separate
process) succeeded. Only after all this the error is propagated
to the LXC driver. The driver aborts the startup and tries to
perform the cleanup, but this is missing CGroups because those
weren't detected yet.
Ideally, whenever a function fails, it tries to unroll back so
that is has no artifacts left behind (look at all those frees/FD
closes/etc. at end of functions). But with CGroups it is
different - the controller process can't clean up after itself,
because it is still running inside that CGroup.
Therefore, what we have to do is to let the driver detect CGroups
as soon as they are created, and proceed with controller
execution only after that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik [Tue, 20 Apr 2021 11:28:20 +0000 (13:28 +0200)]
lxc: Pass another pipe to lxc_controller
Currently, there is only a single pipe passed to lxc_controller
and it is used by lxc_controller to signal to the LXC driver that
the container is set up and ready to run. However, in the next
commit we will need to signal that the LXC driver has done its
part of startup process and thus the controller can proceed.
Unfortunately, virCommand handshake can't be used for this,
because it's already used to read controller's PID.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik [Tue, 20 Apr 2021 11:34:55 +0000 (13:34 +0200)]
lxc_controller: Move closing of handshakeFd out of virLXCControllerDaemonHandshake()
Future commits will want to reuse the handshakeFd and thus it
mustn't be closed in virLXCControllerDaemonHandshake(). Do the
closing explicitly afterwards.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The lxc_controller has a structure that's keeping its internal
state, including so called handshakeFd which is the write end of
a pipe that's used to signal to the LXC driver that the container
is set up and ready to run. However, the struct member is not
initialized to -1, so if anything fails before it is set then the
virLXCControllerFree() function tries to close FD 0 (stdin).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Lin Ma [Thu, 22 Apr 2021 10:38:19 +0000 (18:38 +0800)]
virsh: Fix completion logic to guestvcpus command
In case of non-continuous vCPU topology, We can't infer the bitmap size
from the combination of onlineVcpuStr and nvcpus.
We should use virBitmapParseUnlimited here instead of virBitmapParse due
to the bitmap size is unknown.
The current setup uses a single script that is symlinked twice
and that tries to configure bash completion for both virsh and
virt-admin, even if only one of them is installed. This also
forces us to have a -bash-completion RPM package that only
contains the tiny shared file.
Rework bash completion support so that two scripts are
generated, each one tailored to a specific command.
Since the shared script no longer exists after this change,
the corresponding RPM package becomes empty.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 19 Apr 2021 16:31:10 +0000 (18:31 +0200)]
spec: Move systemtap probes from -client to -libs
Any application that uses the libraries can take advantage of
the systemtap probes, so they should be shipped in the -libs
package rather than in -client.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 19 Apr 2021 16:29:25 +0000 (18:29 +0200)]
spec: Move some files from -client to -daemon
The -client package's purpose is enabling remote machines to
connect to a virtualization host, but the virt-host-validate
and libvirt-guests tools are designed to be run directly on
the virtualization host and as such are a better fit for the
-daemon package.
With this change, installing and removing the -client package
no longer needs to touch the systemd configuration.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Andrea Bolognani [Mon, 19 Apr 2021 16:23:12 +0000 (18:23 +0200)]
spec: Merge -admin package into -daemon
It's useful to have virt-admin around when debugging issues
with libvirtd, and since it's a tiny binary we can simply
include it in the -daemon package to ensure it's always going
to be available when needed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Tue, 20 Apr 2021 13:03:16 +0000 (15:03 +0200)]
bash-completion: Fix argument passing to $1
Our vsh bash completion string is merely just a wrapper over
virsh/virt-admin complete (cmdComplete) - a hidden command that
uses internal readline completion to generate list of candidates.
But this means that we have to pass some additional arguments to
the helper process: e.g. connection URI and R/O flag.
Candidates are printed on a separate line each (and can contain
space), which means that when bash is reading the helper's output
into an array, it needs to split items on '\n' char - hence the
IFS=$'\n' prefix on the line executing the helper. This was
introduced in b889594a70.
But this introduced a regression - those extra arguments we might
pass are stored in a string and previously were split on a space
character (because $IFS was kept untouched and by default
contains space). But now, after the fix that's no longer the case
and thus virsh/virt-admin sees ' -r -c URI' as one argument.
The solution is to take $IFS out of the picture by storing the
extra arguments in an array instead of string.
Fixes: b889594a7092440dc916e3f43eeeaca2684571ee Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Tim Wiederhake [Wed, 21 Apr 2021 12:08:08 +0000 (14:08 +0200)]
virInterfaceLinkParseXML: Use virXMLProp*
This strictens the parser to disallow negative values (interpreted as
`UINT_MAX + value + 1`) for attribute `speed`, which does not make sense for
a value measured in Mbits per second.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Tue, 20 Apr 2021 10:58:28 +0000 (12:58 +0200)]
qemu: blockjob: Transition into 'ready' state only from expected states
In certain rare occasions qemu can transition a block job which was
already 'ready' into 'standby' and then back. If this happens in the
following order libvirt will get confused about the actual job state:
1) the block copy job is 'ready' (job->state == QEMU_BLOCKJOB_STATE_READY)
2) user calls qemuDomainBlockJobAbort with VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT
flag but without VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC
3) the block job is switched to synchronous event handling
4) the block job blips to 'standby' and back to 'ready', the event is
not processed since the blockjob is in sync mode for now
5) qemuDomainBlockJobPivot is called:
5.1) 'job-complete' QMP command is issued
5.2) job->state is set to QEMU_BLOCKJOB_STATE_PIVOTING
6) code for synchronous-wait for the job completion in qemuDomainBlockJobAbort
is invoked
7) the waiting loop calls qemuBlockJobUpdate:
7.1) job->newstate is QEMU_BLOCKJOB_STATE_READY due to 4)
7.2) qemuBlockJobEventProcess is called
7.3) the handler for QEMU_BLOCKJOB_STATE_READY overwrites
job->state from QEMU_BLOCKJOB_STATE_PIVOTING to QEMU_BLOCKJOB_STATE_READY
8) qemuDomainBlockJobAbort is looking for a finished job, so waits again
9) qemu finishes the blockjob and transitions it into 'concluded' state
10) qemuBlockJobUpdate is triggered again, this time finalizing the job.
10.1) job->newstate is = QEMU_BLOCKJOB_STATE_CONCLUDED
job->state is = QEMU_BLOCKJOB_STATE_READY
10.2) qemuBlockJobEventProcessConcluded is called, the function
checks whether there was an error with the blockjob. Since
there was no error job->newstate becomes
QEMU_BLOCKJOB_STATE_COMPLETED.
10.3) qemuBlockJobEventProcessConcludedTransition selects the action
for the appropriate block job type where we have:
case QEMU_BLOCKJOB_TYPE_COPY:
if (job->state == QEMU_BLOCKJOB_STATE_PIVOTING && success)
qemuBlockJobProcessEventConcludedCopyPivot(driver, vm, job, asyncJob);
else
qemuBlockJobProcessEventConcludedCopyAbort(driver, vm, job, asyncJob);
break;
Since job->state is QEMU_BLOCKJOB_STATE_READY,
qemuBlockJobProcessEventConcludedCopyAbort is called.
This patch forbids transitions to QEMU_BLOCKJOB_STATE_READY if the
previous job state isn't QEMU_BLOCKJOB_STATE_RUNNING or
QEMU_BLOCKJOB_STATE_NEW.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1951507 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pavel Hrdina [Fri, 16 Apr 2021 18:32:34 +0000 (20:32 +0200)]
bhyvexml2argvtest: use virCommandToStringFull to strip command path
Currently the tests would fail if the bhyve commands are installed in
different path then /usr/bin. Strip the command path to not depend on
the host environment.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Pavel Hrdina [Thu, 15 Apr 2021 12:36:32 +0000 (14:36 +0200)]
meson: don't check collie as program for sheepdog
Upstream sheepdog changed collie to dog back in 2013 in version 0.7.0.
Looking into repology that version is no longer used by any distribution
supported by libvirt.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Pavel Hrdina [Wed, 14 Apr 2021 21:57:50 +0000 (23:57 +0200)]
tests: use virfirewallmock instead of hasNetfilterTools
Instead of checking for specific error that the binaries are not
available mock the virFindFileInPath function. This way we don't have
to skip these tests on host where the binaries are missing.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Wed, 21 Apr 2021 06:49:51 +0000 (08:49 +0200)]
util: xml: Fix confusing semantics of VIR_XML_PROP_OPTIONAL flag
The new enum helpers use a set of flags to modify their behaviour, but
the declared set of flags is semantically confusing:
typedef enum {
VIR_XML_PROP_OPTIONAL = 0, /* Attribute may be absent */
VIR_XML_PROP_REQUIRED = 1 << 0, /* Attribute may not be absent */
Since VIR_XML_PROP_OPTIONAL is declared as 0 any other flag shadows it
and makes it impossible to detect. The functions are not able to detect
a semantic nonsense of VIR_XML_PROP_OPTIONAL | VIR_XML_PROP_REQUIRED and
it's a perfectly valid statement for the compilers.
In general having two flags to do the same boolean don't make sense and
the implementation doesn't fix any shortcomings either.
To prevent mistakes, rename VIR_XML_PROP_OPTIONAL to VIR_XML_PROP_NONE,
so that there's always an enum value used with the calls but it doesn't
imply that the flag makes the property optional when the actual value is
0.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Tim Wiederhake [Tue, 20 Apr 2021 11:27:52 +0000 (13:27 +0200)]
testUpdateQEMUCaps: Fix memory leak
testUpdateQEMUCaps is called multiple times. Use virQEMUCapsUpdateHostCPUModel
instead of virQEMUCapsInitHostCPUModel to not overwrite (and leak) the
pointers in qemuCaps->kvm.hostCPU and qemuCaps->tcg.hostCPU.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Fixes: 4eb7c621985dad4de911ec394ac628bd1a5b29ab Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We can figure out the appropriate value for 'create' from the command
type, so push that into the test function rather than specifying it in
the test macro.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Jonathon Jongsma [Wed, 31 Mar 2021 22:03:08 +0000 (17:03 -0500)]
nodedev: Remove GetMdevctl*Command() wrappers
These per-command generator functions were only exposed in the header to
allow the commandline generation to be tested. Now that we have a
generic mdevctl command generator, we can get rid of the per-command
wrappers and reduce the noise in the header.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Erik Skultety [Wed, 31 Mar 2021 13:24:47 +0000 (15:24 +0200)]
nodedev: driver: Create a generic mdevctl command translator
Currently there are dedicated wrappers to construct mdevctl command.
These are mostly fine except for the one that translates both "start"
and "define" commands, only because mdevctl takes the same set of
arguments. Instead, keep the wrappers, but let them call a single
global translator that handles all the mdevctl command differences and
commonalities.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
This is not a 1:1 mapping to mdevctl commands because mdevctl doesn't
support a separate 'create' command. mdevctl uses 'start' for both
starting a pre-defined device as well as for creating and starting a new
transient device. The libvirt code will be more readable if we treat
these as separate commands. When we need to actually execute mdevctl,
the 'create' command will be translated into the appropriate 'mdevctl
start' command.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
projects / libvirt.git / log