In the virStorageSourceChainHasManagedPR() function we iterate
over whole backing chain trying to determine if one of the layers
has managed PR configured. But due to a typo we in fact check the
top layer only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The files for libvirt-net-rpc-server.la refernce the sasl/sasl.h
system header but never used the $(SASL_CFLAGS) variable. This
was never noticed previously because the $(AVAHI_CLFAGS) were
set and these typically pulled in the same include directory.
When mDNS/Avahi support was removed this exposed the bug which
caused FreeBSD builds to break as /usr/local/include was no
longer searched for headers.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Filter out the given capabilities and set domain taint if we've done so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when e.g. a new feature breaks upstream behaviour it's useful
to allow users to disable the new feature to verify the regression and
possibly use it as a workaround until a fix is available.
The new qemu.conf option named "capability_filters" allows to remove
qemu capabilities from the detected bitmap.
This patch introduces the configuration infrastructure to parse the
option and pass it around.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Show that the capability tweaking stuff works by enabling blockdev in
the 'qemu-ns' test even in versions where it's not yet fully supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the DO_TEST_CAPS_LATEST/VER infrastructure to run a more modern
version of this and also fork it to a pre-blockdev version so that we
can check the qemu namespace capability tweaking.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For testing purposes it's sometimes desired to be able to control the
presence of capabilities of qemu. This adds the possibility to do this
via the qemu namespace.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly how we allow adding arbitrary command line arguments and
environment variables this patch introduces the ability to control
libvirt's perception of the qemu process by tweaking the capability bits
for testing purposes.
The idea is to allow developers and users either test a new feature by
enabling it early or disabling it to see whether it introduced
regressions.
This feature is not meant for production use though, so users should
handle it with care.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will allow enabling/disabling custom hypervisor
features for debugging/testing purposes via the qemu namespace.
Add a taint flag where we will flag such a domain so it's obvious what's
happening.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Simplify the main function by splitting out how we parse the extra
passthrough environment variables.
Note that the validation function checks that the first letter must be a
character or underscore which makes the check whether the name is
redundant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Simplify the main function by splitting out how we parse the extra
passthrough commandline arguments.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_conf.c deals with the configuration file. Better fit for the
structure and freeing function will be qemu_domain.c where the rest of
the namespace parsing/formatting stuff resides.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The data injected via the namespace may contain also other things than
commandline passthrough definitions. Rename it to make it more
universal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In kernel 4.12 there was introduced new BFQ scheduler and in kernel
5.0 the old CFQ scheduler was removed. This has an implication on
the cgroups file names.
If the CFQ controller is enabled we use one file:
io.weight
The new BFQ controller expose one file with different name:
io.bfq.weight
Except for different name they have different syntax.
io.weight:
default $val
major:minor $val
io.bfq.weight:
$val
The difference is that BFQ doesn't support per-device weight.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In kernel 4.12 there was introduced new BFQ scheduler and in kernel
5.0 the old CFQ scheduler was removed. This has an implication on
the cgroups file names.
If the CFQ controller is enabled we use these two files:
blkio.weight
blkio.weight_device
The new BFQ controller expose only one file with different name:
blkio.bfq.weight
The reason is that BFQ controller doesn't support per-device weight.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we need to get a path of specific file and we need to check its
existence before we use it then we can reuse that path to get value
for specific device. This way we will not build the path again in
virCgroupGetValueForBlkDev.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we need to get a path of specific file and we need to check its
existence before we use it then we can reuse that path to get/set
values instead of calling the existing get/set value functions which
would be building the path again.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The header for the news entry blends together with the text and other
entries. This patch tries to space them out somewhat for better visual
separation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We currently refuse to connect to remote libvirtd over SSH if we see the
path ends in /session. Earlier on though we checked for /session and set
the VIR_DRV_OPEN_REMOTE_USER flag. There is one subtle distinction
though with the test driver. All test URIs are marked with this flag,
regardless of whether the URI indicates a local or remote connection.
Previously a local connection to the test driver would have used the
unprivileged libvirtd while a remote connection would have tried the
privileged libvirtd. With this we are consistent and use the
unprivileged for both local & remote, if the current user is non-root.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the VIR_DRV_OPEN_REMOTE_USER flag is only set when we identify
that we're connecting to a local libvirtd daemon. We would like to be
able to set that even if connecting to a remote libvirtd daemon. This
entails refactoring the conditional check.
One subtle change is that the VIR_DRV_OPEN_REMOTE_USER is now set when
the test+XXX:// URI is used, even if a servername is present. This has
no effect in this patch, but will later.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirtd has long had integration with avahi for advertising libvirtd
using mDNS when TCP/TLS listening is enabled. For a long time the
virt-manager application had support for auto-detecting libvirtds
on the local network using mDNS, but this was removed last year
commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
Author: Cole Robinson <crobinso@redhat.com>
Date: Sat Oct 6 20:55:31 2018 -0400
connect: Drop avahi support
Libvirtd can advertise itself over avahi. The feature is disabled by
default though and in practice I hear of no one actually using it
and frankly I don't think it's all that useful
The 'Open Connection' wizard has a disproportionate amount of code
devoted to this feature, but I don't think it's useful or worth
maintaining, so let's drop it
I've never heard of any other applications having support for using
mDNS to detect libvirtd instances. Though it is theoretically possible
something exists out there, it is clearly going to be a niche use case
in the virt ecosystem as a whole.
By removing avahi integration we can cut down the dependency chain for
the basic libvirtd install and reduce our code maint burden.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The unprivileged libvirtd daemon switched to use the XDG dir layout in
the 0.9.13 release, and included code for moving config files from the
old location. The chances of someone upgrading libvirt from <= 0.9.12
directly to libvirt >= 5.5.0 is close enough to zero that we can
reasonably drop the back compat code.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In libssh 0.9.0 functions ssh_is_server_known and ssh_write_knownhost
are marked as deprecated.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1722735
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Jano probably based his branch on top of mine and didn't notice
when I moved the section up slightly and thus git applied it again.
Keep only the instance followin the new features section.
This reverts commit 9c68bb4a5c.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
testDomainInterfaceAddresses always returns the same hard-coded
addresses. Change the behavior such as if there is a DHCP range defined,
addresses are returned from that pool.
The specific address returned depends on both the domain id and the
specific guest interface in an attempt to return unique addresses *most
of the time*.
Additionally, properly handle IPv6 networks which were previously
ignored completely.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When connecting to virtlogd fails e.g. due to wrong libvirtd selinux
process label we'd report an utterly useless error message:
$ virsh start upstream
error: Failed to start domain upstream
error: Cannot recv data: Connection reset by peer
Use virLastErrorPrefixMessage in the correct place to give a better
sense of what's going on:
$ virsh start upstream
error: Failed to start domain upstream
error: can't connect to virtlogd: Cannot recv data: Connection reset by peer
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
In some cases we report a low level error message which does not have
enough information to see what the problem is. To allow improving on
this add an API which will prefix the error message with another error
message string which can be used to describe where the error comes from.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we added the seclabels to the schema we can test that they are
parsed and formatted correctly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Allow using seclabels the same way as disk images allow it. Currently
the snapshot code copies the seclabels from the original image if no
seclabel is provided. Also there's no code change required as the
snapshot XML parser actually uses parts of the disk parser thus
seclabels are already parsed and formatted and even applied thus this is
just a formalization of our support for this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Change the example and add a recommendation to use disk target rather
than path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
When testing stuff you might want to print the XML. Interlocking it with
no metadata adds exactly 0 value to the user.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit f34397e51c introduced a crash-inducing problem when collecting
disk snapshot data, where the array would be filled starting from the
second element.
The code then dereferenced the first one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The "cpu-add" command is supported in all supported qemu versions and
cpu unplug did not work at all until the new cpu unplug approach (using
device_add/del) was implemented.
Remove the support for falling back to the text monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The docstring of virNetworkGetDHCPLeases is not correctly formatted and
as a result the example code snippet appears as normal text under the
"Returns:" section. This patch fixes the problem.
Signed-off-by: Ilias Stamatis <stamatis.iliass@gmail.com>
It will not be executed when the page is loaded locally. It needs
planet.virt-tools.org to supply the right headers (which it does now).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Don't use the global namespace, unify quotes and semicolons at the end of lines
and "use strict".
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.
Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Without "unavailable-features" CPU property we cannot properly detect
whether a specific MSR feature we asked for (either explicitly or
implicitly via a CPU model) was disabled by QEMU for some reason.
Because this could break migration, snapshots, and save/restore
operaions, it's better to just forbid any use of MSR features with QEMU
which lacks "unavailable-features" CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is used by the host capabilities code to construct host CPU
definition.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
