Peter Krempa [Thu, 7 May 2020 12:00:28 +0000 (14:00 +0200)]
conf: Sanitize handling of <auth> and <encryption> placement for disks
Modern way to store <auth> and <encryption> of a <disk> is under
<source>. This was added to mirror how <backingStore> handles these and
in fact they are relevant to the source rather than to any other part of
the disk. Historically we allowed them to be directly under <disk> and
we need to keep compatibility.
This wasn't a problem until introduction of -blockdev in qemu using of
<auth> or <encryption> plainly wouldn't work with backing chains.
Now that it works in backing chains and can be moved back and forth
using snapshots/block-commit we need to ensure that the original
placement is properly kept even if the source changes.
To achieve the above semantics we need to store the preferred placement
with the disk definition rather than the storage source definitions and
also ensure that the modern way is chosen when the VM started with
<source/encryption> only in the backing store.
Peter Krempa [Thu, 7 May 2020 08:55:37 +0000 (10:55 +0200)]
qemu: domain: Forbid slice/encryption/copy_on_read with disk type='lun'
Any non-raw block layer feature will not work with raw SCSI command
passthrough via 'scsi-block'. Explicitly refuse use of luks encryption,
storage slices and copy on read.
Peter Krempa [Thu, 7 May 2020 08:53:51 +0000 (10:53 +0200)]
qemu: Forbid non-raw images for disk type='lun' with vitio-blk frontend
Historically the virtio-blk frontend by default enabled SCSI emulation
and tried to do SCSI command passthrough. As this was enabled by default
there's a fallback mechanism in place in cases when the backend doesn't
support SCSI for any reason.
This is not the case when disk type=lun is used with 'scsi-block' via
'virtio-scsi'.
We did not restrict configurations when the user picks 'qcow2' or any
other format as format of the disk, in which case the emulation is
disabled as such configuration doesn't make sense.
This patch unifies the approach so that 'raw' is required both when used
via 'virtio-blk' and 'virtio-scsi' so that the user is presented with
the expected configuration. Note that use of <disk type='lun'> is
already very restrictive as it requires a block device or iSCSI storage.
Additionally the scsi emulation is now deprecated by qemu with
virtio-blk as it conflicts with virtio-1 and the alternative is to use
'virtio-scsi' which performs better and is along for a very long time.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Historically the 'scsi' passthrough feature of virtio-blk-pci
was enabled by default. Libvirt was disabling it due to security
implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was
not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the
default value was changed to disabled in preparation for virtio-1.
Starting from QEMU-5.0 the 'scsi' property was also deprecated. There
replacement for the functionality is to use 'virtio-scsi' for the
purpose. This isn't a direct replacement though.
Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which
allows us to stop formatting the 'scsi=' property if it's disabled by
default and not requested so that we don't use deprecated features.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU-5.0 added 'default-value' field for any applicable property
returned by 'device-list-properties'. Add an optional callback for any
device property definition which will allow detection of features and
default values based on this new data.
This unfortunately means that the description of properties had to move
from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new
type (virQEMUCapsDevicePropsFlags) which also has the callback property
and the corresponding change in the initializers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 6 May 2020 17:53:43 +0000 (19:53 +0200)]
qemuMonitorGetDeviceProps: Return data in a hash table
Create a hash table of device property names which also stores the
corresponding JSON object so that the detection code can look at the
recently added 'default-value' field and possibly others.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 6 May 2020 14:53:31 +0000 (16:53 +0200)]
virQEMUCapsProbeQMPDevices: Split up into logical chunks
The function was parsing 'qom-list-types' and then also calling function
which parses 'device-list-properties' and also 'qom-list-properties'.
Split it up into individual functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 6 May 2020 11:50:03 +0000 (13:50 +0200)]
qemu: process: Don't clear QEMU_CAPS_BLOCKDEV when SD card is present
Help QEMU in deprecation of -drive if=none without the need to refactor
all old boards. Stop masking out -blockdev support when -drive if=sd
needs to be used. We achieve this by forbidding blockjobs and
special-casing all other code paths. Blockjobs are sacrificed in this
case as SD cards are a corner case for some ARM boards and are thus not
used commonly.
Peter Krempa [Fri, 17 Apr 2020 10:36:07 +0000 (12:36 +0200)]
qemu: Handle cases when 'qomName' isn't present
Use the drive alias for all cases when we can't generate qomName. This
is meant to handle disks on 'sd' bus which are instantiated via -drive
if=sd as there isn't any specific QOM name for them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 17 Apr 2020 09:09:58 +0000 (11:09 +0200)]
qemu: Refuse blockjobs on disk bus='sd' with -blockdev
We still have to use -drive to instantiate sd disks. Combining that with
the new logic for blockjobs would be very complicated and not worth it
given that 'sd' cards work only on few rarely used machine types of
non-common architectures and libvirt didn't implement support for 'sd'
bus controllers. This will allow us to use -blockdev for other kinds on
such machines while sacrificing block jobs.
Note: this is currently no-op as we mask-out the QEMU_CAPS_BLOCKDEV
capability if any of the disks has bus='sd'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 6 May 2020 09:40:18 +0000 (11:40 +0200)]
tests: Add tests for a virtio and sd disk in a single machine
The 'vexpress-a9' ARM board supports the native 'sd' bus as well as
virtio. Add a test case for proving that upcoming changes to handling of
'sd' work. This config was also tested with real qemu and the qemu
process starts correctly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 5 May 2020 15:00:41 +0000 (17:00 +0200)]
qemuDomainValidateStorageSource: Allow masking out blockdev support
In case of 'sd' cards we'll use pre-blockdev code also if qemu supports
blockdev. In that specific case we'll need to mask out blockdev support
for 'sd' disks. Plumb in a boolean to allow it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 4 May 2020 17:32:37 +0000 (19:32 +0200)]
qemuBuildDriveStr: Refactor formatting of command line for 'sd' cards
Remove all the universal code since the 'else' part formats commandline
only for the SD card based disk. Note that we can use virDiskNameToIndex
without the check as we already validate that 'disk->dst' contains a
properly formatted string in the validation code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 4 May 2020 13:44:43 +0000 (15:44 +0200)]
qemu: Rename qemuDiskBusNeedsDriveArg to qemuDiskBusIsSD
The function effectively boils down to whether the disk is 'SD'. Since
we'll need to make more decisions based on the fact whether the disk is
on the SD bus, rename the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 4 May 2020 16:53:01 +0000 (18:53 +0200)]
qemu: Move disk config validation to qemuValidateDomainDeviceDefDiskFrontend
Previously we've validated it in qemuCheckDiskConfig which was directly
called from the command line generator. Move the checks to the validator
where they belong.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move the tests to DO_TEST_CAPS_LATEST. Since switch to blockdev stopped
us formatting the tunning parameters on the command line let's also add
version cases for qemu-4.1 data which doesn't enable blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Fri, 8 May 2020 01:54:39 +0000 (21:54 -0400)]
network: force re-creation of iptables private chains on firewalld restart
When firewalld is stopped, it removes *all* iptables rules and chains,
including those added by libvirt. Since restarting firewalld means
stopping and then starting it, any time it is restarted, libvirt needs
to recreate all the private iptables chains it uses, along with all
the rules it adds.
We already have code in place to call networkReloadFirewallRules() any
time we're notified of a firewalld start, and
networkReloadFirewallRules() will call
networkPreReloadFirewallRules(), which calls
networkSetupPrivateChains(); unfortunately that last call is called
using virOnce(), meaning that it will only be called the first time
through networkPreReloadFirewallRules() after libvirtd starts - so of
course when firewalld is later restarted, the call to
networkSetupPrivateChains() is skipped.
The neat and tidy way to fix this would be if there was a standard way
to reset a pthread_once_t object so that the next time virOnce was
called, it would think the function hadn't been called, and call it
again. Unfortunately, there isn't any official way of doing that (we
*could* just fill it with 0 and hope for the best, but that doesn't
seem very safe.
So instead, this patch just adds a static variable called
chainInitDone, which is set to true after networkSetupPrivateChains()
is called for the first time, and then during calls to
networkPreReloadFirewallRules(), if chainInitDone is set, we call
networkSetupPrivateChains() directly instead of via virOnce().
It may seem unsafe to directly call a function that is meant to be
called only once, but I think in this case we're safe - there's
nothing in the function that is inherently "once only" - it doesn't
initialize anything that can't safely be re-initialized (as long as
two threads don't try to do it at the same time), and it only happens
when responding to a dbus message that firewalld has been started (and
I don't think it's possible for us to be processing two of those at
once), and even then only if the initial call to the function has
already been completed (so we're safe if we receive a firewalld
restart call at a time when we haven't yet called it, or even if
another thread is already in the process of executing it. The only
problematic bit I can think of is if another thread is in the process
of adding an iptable rule at the time we're executing this function,
but 1) none of those threads will be trying to add chains, and 2) if
there was a concurrency problem with other threads adding iptables
rules while firewalld was being restarted, it would still be a problem
even without this change.
This is yet another patch that fixes an occurrence of this error:
COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: No chain/target/match by that name.
In particular, this resolves: https://bugzilla.redhat.com/1813830
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Laine Stump [Fri, 8 May 2020 02:32:59 +0000 (22:32 -0400)]
network: make it safe to call networkSetupPrivateChains() multiple times
networkSetupPrivateChains() is currently called only once per run of
libvirtd, so it can assume that errInitV4 and errInitV6 are empty/null
when it is called. In preparation for potentially calling this
function multiple times during one run, this patch moves the reset of
errInitV[46] to the top of the function, to assure no memory is
leaked.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Fri, 24 Apr 2020 11:17:51 +0000 (13:17 +0200)]
virDevMapperGetTargetsImpl: quit early if device is not a devmapper target
As suggested in the linked bug, libvirt should firstly check
whether the major number of the device is device mapper major.
Because if it isn't subsequent DM_DEVICE_DEPS task may not only
fail, but also yield different results. In the bugzilla this is
demonstrated by creating a devmapper target named 'loop0' and
then creating loop target /dev/loop0. When the latter is then
passed to a domain, our virDevMapperGetTargetsImpl() function
blindly asks devmapper to provide target dependencies for
/dev/loop0 and because of the way devmapper APIs work, it will
'sanitize' the input by using the last component only which is
'loop0' and thus return different results than expected.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1823976 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's been more than six months since we adopted GLib and we've
been pretty aggressive at replacing our homegrown APIs with more
standard ones, so by now most of the symbols mentioned in this
document haven't been around for quite a long time already.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
docs: introduce a page showing a overall CI dashboard
With the move to GitLab CI one of the things we miss from Jenkins is a
single page dashboard showing CI status across all projects. This is a
very simple replacement that uses badges for CI pipeline status.
A CSS tweak is needed because RST->HTML adds redundant <p> tags inside
table cells which causes excessive vertical whitespace to appear.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qemuDomainCleanupRun: Actually run cleanup callbacks in reverse order
We have a framework to register cleanup callbacks that are run
when a domain is shut down. The idea is to run callbacks in
reverse order than they were registered. However, looking at the
code this is not the case. Fortunately, this framework is used to
register a single callback and a single callback only -
qemuMigrationDstPrepareCleanup() - therefore there was no problem
just yet.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jim Fehlig [Thu, 7 May 2020 23:38:41 +0000 (17:38 -0600)]
tests: Fix the libxl xml2domconfig test
Commit a13b2905f7 missed an adjustment to a test that is only run when
building against xen <= 4.9, where LIBXL_HAVE_BUILDINFO_NESTED_HVM is
not defined. Adjust fullvirt-cpuid-legacy-nest test similar to the others.
Revert "tests: Use qemu:///embed to simplify fakerootdir management"
Turns out that it's not enough to pass the qemu:///embed root to
virQEMUDriverConfigNew(), you also have to make sure the same
string is copied into the virQEMUDriver structure yourself, and
not doing so in our case resulted in the cleanup never happening
and in distcheck failing because of that.
On the other hand, actually setting config->embeddedRoot would
result in different paths being generated for each test run, which
would obviously break qemuxml2argvtest, so that's not an option
either.
tests: Use qemu:///embed to simplify fakerootdir management
Now that the QEMU driver natively supports storing all its runtime
data inside an arbitrary directory, we can avoid having multiple
copies of the same logic in the test suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
tests: poison $HOME and $XDG_RUNTIME_DIR env variables
To attempt to catch unit tests which accidentally create files in $HOME,
or $XDG_RUNTIME_DIR, poison these env vars by pointing them to
directories which don't exist. This should give easier to debug test
failures. For example:
$ VIR_TEST_DEBUG=1 ./qemuhotplugtest
Could not initialize HostdevManager - operation failed: Failed to create state dir '/bad-test-used-env-xdg-runtime-dir/libvirt/hostdevmgr'
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We need this for all tests that use virHostdevManager, because
during creation of this object for unprivileged connections
like those used in the test suite we would end up writing inside
the user's home directory.
That's bad manners in general, but when running the test suite
inside a purposefully constrained environment such as the one
exposed by pbuilder, it turns into an outright test failure:
Could not initialize HostdevManager - operation failed: Failed
to create state dir '/nonexistent/.cache/libvirt/hostdevmgr'
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
tests: Update capabilities for QEMU 5.0.0 on ppc64
The churn in the output files is caused primarily by the fact that
replies were generated on a POWER9 machine, which is good because
we didn't have coverage of that before.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
tests: Enable directory override for qemucapsprobe
Currently, qemucapsprobe fails when libvirt is not already installed
on the system:
$ ./tests/qemucapsprobe /path/to/qemu-system-ppc64 >/dev/null
I/O warning : failed to load external entity "/usr/share/libvirt/cpu_map/index.xml"
2020-05-06 09:49:59.136+0000: 269822: info : libvirt version: 6.4.0
2020-05-06 09:49:59.136+0000: 269822: info : hostname: [...]
2020-05-06 09:49:59.136+0000: 269822: warning : virQEMUCapsLogProbeFailure:5127 :
Failed to probe capabilities for /path/to/qemu-system-ppc64: XML error: failed to
parse xml document '/usr/share/libvirt/cpu_map/index.xml'
It would be great if the tool could work entirely out of the build
directory, and this patch achieves just that.
Suggested-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jiri Denemark [Tue, 5 May 2020 16:35:26 +0000 (18:35 +0200)]
qemu: Don't use CPU from host capabilities as host-model on ARM
We never supported host-model CPUs on ARM and we don't want to support
them even once patches for direct detection of host CPU are merged. And
since using host CPU definition for host-model CPUs exists only for
backward compatibility, we should not use it for any host-model support
added in the future. Such enhancement should exclusively use the result
of query-cpu-model-expansion. Until proper host-model support is
implemented for ARM (if ever), we need to make sure the detected host
CPU is not accidentally used for host-model CPUs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Laine Stump [Fri, 1 May 2020 04:05:50 +0000 (00:05 -0400)]
systemd: start libvirtd after firewalld/iptables services
When a system has enabled the iptables/ip6tables services rather than
firewalld, there is no explicit ordering of the start of those
services vs. libvirtd. This creates a problem when libvirtd.service is
started before ip[6]tables, as the latter, when it finally is started,
will remove all of the iptables rules that had previously been added
by libvirt, including the custom chains where libvirt's rules are
kept. This results in an error message similar to the following when a
user subsequently tries to start a new libvirt network:
"Error while activating network: Call to virNetworkCreate failed:
internal error: Failed to apply firewall rules
/usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \
--in-interface virbr2 --jump REJECT:
ip6tables: No chain/target/match by that name."
(Prior to logging this error, it also would have caused failure to
forward (or block) traffic in some cases, e.g. for guests on a NATed
network, since libvirt's rules to forward/block had all been deleted
and libvirt didn't know about it, so it couldn't fix the problem)
When this happens, the problem can be remedied by simply restarting
libvirtd.service (which has the side-effect of reloading all
libvirt-generated firewall rules)
Instead, we can just explicitly stating in the libvirtd.service file
that libvirtd.service should start after ip6tables.service and
ip6tables.service, eliminating the race condition that leads to the
error.
There is also nothing (that I can see) in the systemd .service files
to guarantee that firewalld.service will be started (if enabled) prior
to libvirtd.service. The same error scenario given above would occur
if libvirtd.service started before firewalld.service. Even before
that, though libvirtd would have detected that firewalld.service was
disabled, and then turn off all firewalld support. So, for example,
firewalld's libvirt zone wouldn't be used, and most likely traffic
from guests would therefore be blocked (all with no external
indication of the source of the problem other than a debug-level log
when libvirtd was started saying that firewalld wasn't in use); also
libvirtd wouldn't notice when firewalld reloaded its rules (which also
simultaneously deletes all of libvirt's rules).
I'm not aware of any reports that have been traced back to
libvirtd.service starting before firewalld.service, but have seen that
error reported multiple times, and also don't see an existing
dependency that would guarantee firewalld.service starts before
libvirtd.service, so it's possible it's been happening and we just
haven't gotten to the bottom of it.
This patch adds an After= line to the libvirtd.service file for each
of iptables.service, ip6tables.service, and firewalld.servicee, which
should guarantee that libvirtd.service isn't started until systemd has
started whichever of the others is enabled.
This race was diagnosed, and patch proposed, by Jason Montleon in
https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb
agreed with him that this change to libvirtd.service was a reasonable
thing to do, but I guess everyone thought someone else was going to
post a patch, so in the end nobody did.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jim Fehlig [Mon, 4 May 2020 21:52:34 +0000 (15:52 -0600)]
docs: Xen improvements
In formatdomain, using 'libxl' and 'xen' is redundant since they now
both refer to the same driver. 'xen' predates 'libxl' and unambiguously
identifies the Xen hypervisor, so drop the use of 'libxl'.
In aclpolkit, the connection URI was erroneously identified as 'libxl'
and the name 'xenlight'. Change the URI to 'xen' and driver name to 'Xen'.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jim Fehlig [Mon, 4 May 2020 21:20:37 +0000 (15:20 -0600)]
libxl: Clarify that 'xenlight' should only be used internally
The libxl driver has suffered an identity crisis since its introduction.
It took on the name 'libxl' since at the time libvirt already contained
a 'xen' driver for the old Xen toolstack implementation. 'libxl' is short
for libxenlight, which is often called xenlight. Unfortunately all forms
of the name are used in the libxl driver.
The only remaining use of the 'xenlight' form is when interacting with
the host device manager, which is difficult to change since it would
cause problems when upgrading the driver.
Rename the #define to make it clear the 'xenlight' form is internal and
add a comment describing why the name exists and that its use should be
discouraged.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jim Fehlig [Mon, 4 May 2020 20:51:32 +0000 (14:51 -0600)]
libxl: Use the name 'Xen' in driver tables
The libxl driver declares its name as 'Xen' through the public
virConnectGetType() API. In the virHypervisorDriver table the name is
set to 'xenlight'. To add more confusion, the name is set to 'LIBXL'
in the virStateDriver. For consistency, use the same name in the driver
tables as reported in the public virConnectGetType() API.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In the referenced commit I removed @ret from
virHostValidateBhyve() thinking it wasn't used when in fact it is
- it's usage is hidden under MODULE_STATUS_WARN(). Reintroduce
the variable back.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are few places where a return variable is introduced (ret
or retval), but then is never changed and is then passed to
return. Well, we can return the value that the variable is
initialized to directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
virnetserver: Check for virNetServerClientInitKeepAlive() retval
Since it's introduction in v0.9.7-147-gf4324e3292 the
virNetServerClientInitKeepAlive() function returned nothing than
a negative one. Fortunately, this did not pose any problem
because we ignored the retval happily. Well, it's time to check
for the retval because the function might fail regularly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 27 Apr 2020 10:48:51 +0000 (12:48 +0200)]
CONTRIBUTING: Include note about build system tools
Debian always runs autoreconf at package build time, which means
that apt-get build-dep will bring in everything that's needed to
build libvirt from a git clone; Fedora and RHEL, however, skip
this step, so we have to install some extra packages manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Xu Yandong [Mon, 4 May 2020 08:36:19 +0000 (16:36 +0800)]
virsh: Fix return code for dump
After the commit dc0771c, ret variable no longer
represents the status of the return code, use
data->ret replace it.
Signed-off-by: Xu Yandong <xuyandong2@huawei.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the past we added 1024 bytes of padding to saved state images so that
users can run "virsh managedsave-edit $GUEST" and make XML changes which
increase the size of the XML document. This padding was accidentally
lost a while back
qemu: Remove unnecessary calculations in qemuDomainSaveMemory
The original 1024 bytes was unreasonably stingy when we consider that
the QEMU state is typically going to be many 100's of MB in size. Thus
this adds 64 KB of padding after the XML which should cope with any
plausible modifications a user will want to make.
Bjoern Walk [Thu, 23 Apr 2020 13:15:09 +0000 (15:15 +0200)]
qemu: command: make qemuBuildVirtioOptionsStr void
Now that qemuBuildVirtioOptionsStr can not fail anymore, remove its
return value and make it void.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Bjoern Walk [Thu, 23 Apr 2020 13:15:08 +0000 (15:15 +0200)]
qemu: move virtio capability validation
Move capability validation of virtio options from command line
generation to post-parse device validation where it belongs.
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Bjoern Walk [Thu, 23 Apr 2020 13:15:07 +0000 (15:15 +0200)]
tests: more fine-granular tests for virtio-options
Add separate tests for individual options and devices for virtio-options
to have the ability to do more fine-granular testing of various
combinations.
Also, add negative tests for unavailable capabilities.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Bjoern Walk [Thu, 23 Apr 2020 13:15:06 +0000 (15:15 +0200)]
tests: use latest caps for virtio-options test
Convert the virtio-options test in qemuxml2argv and qemuxml2xml to use
the latest available QEMU capabilities.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This patch adds the implementation of the IBS pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_IBS capability added
in the previous patch.
IBS can have the following values: "broken", "workaround",
"fixed-ibs", "fixed-ccd" and "fixed-na".
This is the XML format for the cap:
<features>
<ibs value='fixed-ibs'/>
</features>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
IBS (Indirect Branch Speculation) is the last capability added
in QEMU 2.12 related to Spectre mitigation for Power. It was
added in commit 4be8d4e7d935.
This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_IBS.
Like CFPC and SBBC, users might want to tune in IBS based on
their HW and guest OS requirements, and it's better to do it
so in a proper Libvirt feature than to put QEMU arguments
in the middle of the domain XML.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch adds the implementation of the SBBC pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC capability added
in the previous patch.
Like the previously added CFPC feature, SBBC can have the values
"broken", "workaround" or "fixed". Extra code is required to handle
it since it's not a regular tristate capability.
This is the XML format for the cap:
<features>
<sbbc value='workaround'/>
</features>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SBBC (Speculation Barrier Bounds Checking) is another capability
related to Spectre mitigation efforts in Power processors. It
was implemented in QEMU 2.12 by commit 09114fd81799.
This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC to
be implemented in the next patch. Like the case with the now
implemented CFPC, exposing this feature in the XML allows for
a cleaner way for users to tune the SBBC accordingly, given
that not all hypervisor and guest setups supports this
Spectre mitigation.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch adds the implementation of the CFPC pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_CFPC capability added
in the previous patch.
CPFC can have the values "broken", "workaround" or "fixed". Extra
code is required to handle it since it's not a regular tristate
capability.
This is the XML format for the cap:
<features>
<cfpc value='workaround'/>
</features>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
CFPC (Cache Flush on Privilege Change) is one of the capabilities
added to QEMU to mitigate Spectre vulnerabilities in Power chips.
It was implemented in QEMU 2.12 by commit 6898aed77f46.
This capability is still used today due to differences in how
the host setup (hardware and firmware/kernel) can handle this
mitigation. Its default value also varies with the pseries machine
version of the time. There's also certain OSes, like AIX, that
might not support the default value of the pseries machine the
guest uses.
Exposing this in the Libvirt XML as a feature will allow users to tune
CFPC values in a cleaner way, instead of hacking parameters in
<qemu:commandline> elements.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Julio Faracco [Sat, 25 Apr 2020 16:35:37 +0000 (13:35 -0300)]
network: Remove memory leak caused by wrong initialization
This commit fix a wrong variable initialization. There is a variable
called `new_lease` which is being initialized with the content of
parameter `lease`. To avoid memory leak, the proper way is initialize
with NULL first. This wrong statement was added by commit 97a0aa24.
There are some other improvements also.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 23 Apr 2020 14:57:31 +0000 (16:57 +0200)]
qemumonitortestutils: Enforce consumption of all items in test monitor
To prevent unexpected situations where a change in code would stop
looking at some of the tested commands go unnoticed add a mechanism to
force consumption of all test items.
Since there are a few tests which would be hard to fix add also a
mechanism to opt-out of the check.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 23 Apr 2020 14:52:12 +0000 (16:52 +0200)]
qemumonitortestutils: Store a string identifying test monitor entry
For each test monitor entry store an optional string which will allow to
identify it. This will be used later when checking that all registered
monitor commands were used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / thirdparty / libvirt.git / log
