virCommandRun() already handles the case where the cmd argument is NULL,
so there's no need for the caller to check. Make all callers consistent
and remove unnecessary NULL checks.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Coverity complained that the 'default' case of the switch in
nodeDeviceGetMdevctlCommand() was falling through without initializing
'cmd'. Return NULL in this case even though it should never happen.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 20 Apr 2021 14:34:02 +0000 (16:34 +0200)]
qemuBlockJobRefreshJobs: Replace qemuMonitorJobCancel by qemuMonitorBlockJobCancel
We want to unify on one block job cancellation API. Use
qemuMonitorBlockJobCancel which has more features.
In case of job refresh, we are killing off any unknown jobs so we don't
care about their fate.
Another difference is that an possible error from the block job
cancellation might be reported, but we don't really care here ince
it's a very unlikely scenario and we also report a warning.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 21 Apr 2021 13:47:59 +0000 (15:47 +0200)]
qemuDomainBlockJobAbort: Don't use 'job-cancel' instead of 'block-job-cancel'
'block-job-cancel' has one very important semantic difference to
'job-cancel', docummented in qemu as:
Note that if you issue 'block-job-cancel' after 'drive-mirror' has indicated
(via the event BLOCK_JOB_READY) that the source and destination are
synchronized, then the event triggered by this command changes to
BLOCK_JOB_COMPLETED, to indicate that the mirroring has ended and the
destination now has a point-in-time copy tied to the time of the cancellation.
Since libvirt advertises the block copy job as having the synchronous
abort feature we must not use 'job-cancel' here.
Fixes: 4817b5ca1d0 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 13 Apr 2021 15:17:42 +0000 (17:17 +0200)]
qemuMigrationSrcRun: Don't attempt any storage migration if no disks will be migrated
Don't even try to setup storage migration if there are no eligible
disks.
This also fixes migration from older libvirts which didn't format an
empty <nbd/> element in the migration cookie if there weren't any disks
to migrate.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 13 Apr 2021 14:59:38 +0000 (16:59 +0200)]
qemuMigrationSrcRun: Sanitize setting of cookieFlags and migrate_flags on storage migration
Base the decision on the main API flags (VIR_MIGRATE_NON_SHARED_DISK,
QEMU_MONITOR_MIGRATE_NON_SHARED_INC) via a boolean 'storageMigration'
rather than juggling everything trhough 'migration_flags'.
After this patch 'migration_flags' is updated to contain the legacy
storage migration flags only when we'll be about to use it rather than
setting it and then resetting it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'migrate_flags' can be updated in the only caller and since
qemuMigrationSrcNBDStorageCopy already takes @flags which contains
VIR_MIGRATE_NON_SHARED_INC (used to set
QEMU_MONITOR_MIGRATE_NON_SHARED_INC) we can completely remove the
parameter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 13 Apr 2021 14:17:24 +0000 (16:17 +0200)]
qemuMigrationSrcNBDStorageCopy: Return error code on error
In case the 'nbdURI' schema is not known the code would report an error
but wouldn't return failure.
Fixes: 49186372dbe Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 13 Apr 2021 14:16:44 +0000 (16:16 +0200)]
qemuMigrationCookieNBDXMLFormat: Format empty <nbd/> element
Commit 518be41aaa3 refactored qemuMigrationCookieNBDXMLFormat to use
virXMLFormatElement which in comparison to the previous code doesn't
format the element if it's empty.
Unfortunately some crusty bits of our migration code use questionable
logic to assert use of the old-style storage migration parameters which
breaks if no disks are being migrated and the <nbd/> element is not
present.
While later patches will fix the code, re-instate formatting of empty
<nbd/> for increased compatibility.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 13 Apr 2021 14:12:17 +0000 (16:12 +0200)]
util: xml: Introduce virXMLFormatElementEmpty
Add a helper which will format an XML element with attributes and
children, but compared to virXMLFormatElement it also formats an empty
element if both buffers are empty.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
meson: don't probe for -Werror if --werror is enabled
Meson has its own mechanism to turn on -Werror with the --werror option.
If this is set, then there is no reason for libvirt to check for -Werror
itself.
We remove the summary line output because it is potentially misleading
when libvirt hasn't enabled -Werror, but meson has.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we add our extra warning flags unconditionally if the compiler
supports them, regardless of the meson warning_level setting. This has
effectively nullified the warning_level setting in meson, and also
results in meson printing these messages:
meson.build:498: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
meson.build:498: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Semantically we can think of our huge list of flags as being an "extra"
set of warnings, and thus we ought to only add them when meson would
itself use -Wextra. aka warning_level == 2 or 3.
In practice libvirt code can't be built with -Wpedantic so we can ignore
meson warning_level 3, and only add our flags when warning_level==2.
In doing this change, we no longer have to check -Wall/-Wextra ourselves
as we can assume meson already set them.
-W is an alias of -Wextra so it is removed too.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In several cases we check if a compiler flag is supported, and then add
it to the 'cc_flags' array. The entire 'cc_flags' array is then later
tested to see if each flag is supported, which duplicates the check in
some cases.
Move the check of cc_flags earlier, and for the extra flags append
directly to supported_cc_flags to avoid the duplicate check
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The split of arrays is fairly arbitrary and a hang over from the way we
had to structure lists of flags when we used GNULIB's compiler flag
checking m4 logic.
The separate lists leads to cases where we enable a flag in one list and
have contradictory setting in another list, which leads to confusion.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
meson: remove obsolete comment about stack frame size
The virStrerror function no longer exists in libvirt so is not a
constraint. At the current stack limit of 4k, and default Linux
stack size of 8 MB, we have a recursion limit of 2048 in the
absolute worst case, and much higher in common case. Even with
smaller stack sizes, we're going to be fine as we don't deeply
recurse in code.
Thus it is not worth spending effort to optimize below our current
4k worst case limit. Removing the comment will stop encouraging
people to spend time on this in future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We're not using these warning flags with libvirt, and it is not worth
keeping them just to issue a warning if someone tries to enable them.
If someone does try to enable them, either libvirt will build cleanly
or it won't.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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>