There is plenty of distributions that haven't switched to
systemd nor they force their users to (Gentoo, Alpine Linux to
name a few). With the daemon split merged their only option is to
still use the monolithic daemon which will go away eventually.
Provide init scripts for these distros too.
For now, I'm not introducing config files which would correspond
to the init files except for libvirtd and virtproxyd init scripts
where it might be desirable to tweak the command line of
corresponding daemons.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
To free the structs and save the error, it is not necessary to hold @priv->lock,
therefore move these parts after the mutex unlock.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
This patch introduces virNetServerGetProgramLocked. It's a function to
determine which program has to be used for a given @msg. This function
will be reused in the next patch.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
As a result, you can later determine during the callback which program
was used. This makes it easier to refactor the code in the future and
is less prone to error.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Use the return value of virObjectRef directly. This way, it's easier
for another reader to identify the reason why the additional reference
is required.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Following domain configuration changes create two memory bandwidth
monitors: one is monitoring the bandwidth consumed by vCPU 0,
another is for vCPU 5.
```
<cputune>
<memorytune vcpus='0-4'>
<node id='0' bandwidth='20'/>
<node id='1' bandwidth='30'/>
+ <monitor vcpus='0'/>
</memorytune>
+ <memorytune vcpus='5'>
+ <monitor vcpus='5'/>
+ </memorytune>
</cputune>
```
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Huaqiang <huaqiang.wang@intel.com>
We learned that the hardware features of CAT, CMT, MBA and MBM
are orthogonal ones, if CAT or MBA is not supported in system,
but CMT or MBM are supported, then the cache monitor or
memoryBW monitor features may not be correctly displayed in
host capabilities through command 'virsh capabilites'.
Showing the cache/memoryBW monitor capabilities even there is
no support of cache allocation or memoryBW allocation features.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Huaqiang <huaqiang.wang@intel.com>
As of commit 2a00ef6e71 which
was released in v5.2.0, we require YAJL to build the QEMU driver.
Remove the checks from code that requires the QEMU driver
or checks that also check for WITH_QEMU.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add Hygon Dhyana CPU model to the processor model.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Yingle Hou <houyingle@hygon.cn>
The x86ModelParseSignatures function makes an assumption that CPU signature
model equals 0 as an invalid case. While in Hygon processor definition, A1
version (model 0, stepping 1) is mass production version, to support Hygon
Dhyana A1 version, we have removed CPU signature model zero checking condition.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Yingle Hou <houyingle@hygon.cn>
CVE-2019-11135
When TSX_CTRL bit of IA32_ARCH_CAPABILITIES MSR is set to 1, the CPU
supports IA32_TSX_CTRL MSR which can be used to disable and/or mask TSX.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
CVE-2019-11135
CPUs with TAA_NO bit of IA32_ARCH_CAPABILITIES MSR set to 1 are not
vulnerable to TSX Asynchronous Abort and passing this bit to a guest
may avoid unnecessary mitigations.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow backups work across external snapshots we need to improve the
algorithm which calculates which bitmaps to merge.
The algorithm must look for appropriately named bitmaps in the image and
possibly descend into a backing image if the current image does not have
the bitmap.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
This function looks up a named bitmap for a virStorageSource in the data
returned from query-named-block-nodes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The function will require the bitmap topology for the full
implementation. To facilitate testing, add the propagation of the
necessary data beforehand so that the test code can stay unchanged
during the changes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Separate the for now incomplete code that collects the bitmaps to be
merged for an incremental backup into a separate function. This will
allow adding testing prior to the improvement of the algorithm to
include snapshots.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The object itself has no extra value and it would make testing the code
harder. Refactor it to remove just the definition pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Re-create any active persistent bitmap in the snapshot overlay image so
that tracking for a checkpoint is persisted. While this basically
duplicates data in the allocation map it's currently the only possible
way as qemu can't mirror the allocation map into a dirty bitmap if we'd
ever want to do a backup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
qemuDomainSnapshotDiskPrepareOne is already called for each disk which
is member of the snapshot so we don't need to iterate through the
snapshot list again to generate members of the 'transaction' command for
each snapshot.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
For testing purposes it will be beneficial to be able to parse the data
from JSON directly rather than trying to simulate the monitor. Extract
the worker bits and export them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
We will need to inspect the presence and attributes for dirty bitmaps.
Extract them when processing reply of query-named-block-nodes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The use of the parseOpaque parameter was mistakenly removed in
commit 4a4132b462
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Tue Dec 3 10:49:49 2019 +0000
conf: don't use passed in caps in post parse method
causing the method to re-fetch qemuCaps that were already just
fetched and put into parseOpaque.
This is inefficient when parsing incoming XML, but for live
XML this is more serious as it means we use the capabilities
for the current QEMU binary on disk, rather than the running
QEMU.
That commit, however, did have a useful side effect of fixing
a crasher bug in the qemu post parse callback introduced by
commit 5e939cea89
Author: Jiri Denemark <jdenemar@redhat.com>
Date: Thu Sep 26 18:42:02 2019 +0200
qemu: Store default CPU in domain XML
The qemuDomainDefSetDefaultCPU() method in that patch did not
allow for the possibility that qemuCaps would be NULL and thus
resulted in a SEGV.
This shows a risk in letting each check in the post parse
callback look for qemuCaps == NULL. The safer option is to
check once upfront and immediately stop (postpone) further
validation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Don't check os type / virt type / arch in the post-parse callback
because we can't assume qemuCaps is non-NULL at this point. It
also conceptually belongs to the validation callback.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This function will be removed in a future commit because it allows the
caller to acquire both monitor and agent jobs at the same time. Holding
both job types creates a vulnerability to denial of service from a
malicious guest agent.
qemuDomainSetVcpusFlags() always passes NONE for either the monitor job
or the agent job (and thus is not vulnerable to the DoS), so we can
simply replace this function with the functions for acquiring the
appropriate type of job.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS.
Split the function so that the portion issuing the agent command only
holds an agent job and the portion issuing the monitor command holds
only a monitor job.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding a
monitor job while we're querying the agent, we open ourselves up to a
DoS.
So split the function up a bit to only hold the monitor job while
querying qemu for whether the domain supports suspend. Then acquire only
an agent job while issuing the agent suspend command.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS.
Split the function so that we only hold the appropriate type of job
while rebooting.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS. So split the function into separate parts: one that does the agent
shutdown and one that does the monitor shutdown. Each part holds only a
job of the appropriate type.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Replace all the uses passing a single parameter as the length.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Remove the usage where sanity of the length argument is verified
by other conditions not matching the previous patches.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
My hesitation to remove VIR_STRDUP without VIR_STRNDUP resulted
in these being able to sneak in.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit 7be5fe66cd.
This commit broke resctrl, because it missed the fact that the
virResctrlInfoGetCache() has side-effects causing it to actually
change the virResctrlInfo parameter, not merely get data from
it.
This code will need some refactoring before we can try separating
it from virCapabilities again.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This commit aims to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1610207
The cause was apparently incorrect handling of jobs in snapshot
revert code which allowed a thread executing snapshot delete to
begin job while snapshot revert was still running on another
thread. The snapshot delete thread then waited on a condition
variable in qemuMonitorSend() while the revert thread finished,
changing (and effectively corrupting) the qemuMonitor structure
under the delete thread which led to its crash.
The incorrect handling of jobs in revert code was due to the fact
that although qemuDomainRevertToSnapshot() correctly begins a job
at the start, the job was implicitly ended when qemuProcessStop()
was called because the job lives in the QEMU driver's private
data (qemuDomainObjPrivate) that was purged during
qemuProcessStop().
This fix prevents qemuProcessStop() from clearing jobs as the
idea of qemuProcessStop() clearing jobs seems wrong in the first
place. It was (inadvertently) introduced in commit
888aa4b6b9, which is effectively reverted by
the second hunk of this commit. To preserve the desired effects
of the faulty commit, the first hunk is included as suggested by
Michal.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When QEMU uid/gid is set to non-root this is pointless as if we just
used a regular setuid/setgid call, the process will have all its
capabilities cleared anyway by the kernel.
When QEMU uid/gid is set to root, this is almost (always?) never
what people actually want. People make QEMU run as root in order
to access some privileged resource that libvirt doesn't support
yet and this often requires capabilities. As a result they have
to go find the qemu.conf param to turn this off. This is not
viable for libguestfs - they want to control everything via the
XML security label to request running as root regardless of the
qemu.conf settings for user/group.
Clearing capabilities was implemented originally because there
was a proposal in Fedora to change permissions such that root,
with no capabilities would not be able to compromise the system.
ie a locked down root account. This never went anywhere though,
and as a result clearing capabilities when running as root does
not really get us any security benefit AFAICT. The root user
can easily do something like create a cronjob, which will then
faithfully be run with full capabilities, trivially bypassing
the restriction we place.
IOW, our clearing of capabilities is both useless from a security
POV, and breaks valid use cases when people need to run as root.
This removes the clear_emulator_capabilities configuration
option from qemu.conf, and always runs QEMU with capabilities
when root. The behaviour when non-root is unchanged.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The keycodemap tool is told to generate docs in rst format now
instead of pod.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This was a semi-automated conversion. First it was run through pod2rst,
and then it was manually editted to use a rst structure that matches
expectations of rst2man.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This was a semi-automated conversion. First it was run through pod2rst,
and then it was manually editted to use a rst structure that matches
expectations of rst2man.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This was a semi-automated conversion. First it was run through pod2rst,
and then it was manually editted to use a rst structure that matches
expectations of rst2man.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Pull in changes which support use of RST for docs output format
instead of POD.
The generator tool has changed its command line arg handling
so all args must be after the command name. The docs title and
subtitle must be specified separately too.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With all plumbing in place, we can now enable the new functionality.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since blockcommit is asynchronous, libvirtd can be restarted while the
operation runs. To ensure the information necessary to finish up the job
is not lost, serialisation to and deserialisation from the status XML is
added.
To unittest this, the new element was only added to the active commit test,
the non-active commit test doesn't have the new element so as to test its
absence.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When blockcommit finishes successfully, one of the
qemuBlockJobProcessEventCompletedCommit() and
qemuBlockJobProcessEventCompletedActiveCommit() event handlers is called.
This is where the delete flag (stored in qemuBlockJobCommitData since the
previous commit) can actually be used to delete the committed snapshot
images if requested.
We use virFileRemove() instead of a simple unlink() to cover the case where
the image to be removed is on an NFS volume.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Propagate the delete flag from qemuDomainBlockCommit() (which was just
ignoring it until now) to qemuBlockJobDiskNewCommit() where it can be
stored in the qemuBlockJobCommitData structure which holds information
necessary to finish the job asynchronously.
In the actual qemuBlockJobDiskNewCommit() in this commit, we temporarily
pass a literal 'false' to preserve the current behaviour until the whole
implementation of the feature is in place.
Signed-off-by: Pavel Mores <pmores@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Teach virt-aa-helper how to label a qcow2 data_file, tracked internally
as externalDataStore. It should be treated the same as its sibling
disk image
Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
