The daemons are not supported on Win32 and therefore were not compiled
in that platform. However, with the daemon code sharing, all the code in
utils *is* compiled and it failed because `waitpid`, `fork`, and
`setsid` are not available. So, as before, let's not build them on
Win32 and make the code more portable by using existing vir* wrappers.
Not compiling virDaemonForkIntoBackground on Win32 is good, but the
second part of the original patch incorrectly replaced waitpid and fork
with our virProcessWait and virFork APIs. These APIs are more than just
simple wrappers and we don't want any of the extra functionality.
Especially virFork would reset any setup made before
virDaemonForkIntoBackground is called, such as logging, signal handling,
etc.
As a result of the change the additional fix in v6.2.0-67-ga87e4788d2
(util: virdaemon: fix waiting for child processes) is no longer
needed and it is effectively reverted by this commit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We previously added a hack to symlink CSS files from the source dir into
the build dir, to allow the website to be browsed locally. We should
have also done this for any images.
This change merges several variables into one "$(assets)" so that we
treat all static files in the root dir the same way.
Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Thu, 16 Apr 2020 12:18:28 +0000 (14:18 +0200)]
qemuDomainDefPostParse: Fail if unable to fill machine type
Previously, we used virCapabilitiesDomainDataLookup() to fill
machine type in post parse callback if none was provided in the
domain XML. If machine type couldn't be filled in an error was
reported. After 4a4132b4625 we've changed it to
virQEMUCapsGetPreferredMachine() which returns NULL, but we no
longer report an error and proceed with the post parse callbacks
processing. This may lead to a crash because the code later on
assumes def->os.machine is not NULL.
Fixes: 4a4132b4625 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Mores <pmores@redhat.com>
Michal Privoznik [Tue, 14 Apr 2020 09:18:02 +0000 (11:18 +0200)]
qemu: Revoke access to mirror on failed blockcopy
When preparing to do a blockcopy, the mirror image is modified so
that QEMU can access it. For instance, the mirror has seclabels
set, if it is a NVMe disk it is detached from the host and so on.
And usually, the restore is done upon successful finish of the
blockcopy operation. But, if something fails then we need to
explicitly revoke the access to the mirror image (and thus
reattach NVMe disk back to the host).
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1822538 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Mores <pmores@redhat.com>
Andrea Bolognani [Wed, 15 Apr 2020 17:12:46 +0000 (19:12 +0200)]
docs: Remove one example from pci-addresses.rst
The idea behind this document is to show, with actual examples,
that users should not expect PCI addresses in the domain XML and
in the guest OS to match.
The first zPCI example already serves this purpose perfectly, so
in the interest of keeping the page as brief and easy to digest
as possible the second one is removed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Andrea Bolognani [Wed, 15 Apr 2020 17:11:01 +0000 (19:11 +0200)]
docs: Move sections around in pci-addresses.rst
The section about VFIO devices is kept separate from the rest
because it's less about domain XML and guest OS disagreeing on the
PCI address of a device, and more about which of the two PCI
addresses in the domain XML is even relevant to the guest OS.
The section on zPCI addresses, on the other hand, falls squarely
in the "more complex cases" category, so it should live in the
corresponding section.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Lin Ma [Thu, 16 Apr 2020 04:44:51 +0000 (12:44 +0800)]
qemu: fix hang in p2p + xbzrle compression + parallel migration
When we do parallel migration, The multifd-channels migration parameter
needs to be set on the destination side as well before incoming migration
URI, unless we accept the default number of connections(2).
Usually, This can be correctly handled by libvirtd. But in this case if
we use p2p + xbzrle compression without parameter '--comp-xbzrle-cache',
qemuMigrationParamsDump returns too early, The corresponding migration
parameter will not be set on the destination side, It results QEMU hangs.
Andrea Bolognani [Mon, 30 Mar 2020 16:29:06 +0000 (18:29 +0200)]
gitlab: Enable improved ccache usage
Setting CC="ccache cc" works in most cases, but sometimes it will
break the build: in particular, we have experienced issues in the
past with that approach when using cgo to build our Go bindings.
A more robust approach is to have a directory containing symlinks
from the compiler name to the ccache binary: in that case, ccache
itself will invoke the compiler, and the build system will be none
the wiser.
Since libvirt-ci commit 2563aebb6c5c, container images contain a
suitable symlink directory, so all that's needed to enable the new
approach is to add this directory to $PATH.
Since we're touching this anyway, we make a few more changes:
$CCACHE_DIR is no longer created manually, because ccache will
take care of creating it for us if it doesn't already exist; the
ccache setup is moved out of the job template and into
script_variables, removing unnecessary duplication; a limit is
set on the size of the cache (500 MB, which is twice the amount
used by a fresh build on my Fedora 31 machine).
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Mon, 30 Mar 2020 16:26:16 +0000 (18:26 +0200)]
gitlab: Don't define $MAKE
Since libvirt-ci commit 27cfddee8835, paths to build tools such as
ninja and make are exported in the container's environment and can
be used directly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
With libpmem support compiled into qemu it will trigger the following
denials on every startup.
apparmor="DENIED" operation="open" name="/"
apparmor="DENIED" operation="open" name="/sys/bus/nd/devices/"
This is due to [1] that tries to auto-detect if the platform supports
auto flush for all region.
Once we know all the paths that are potentially needed if this feature
is really used we can add them conditionally in virt-aa-helper and labelling
calls in case </pmem> is enabled.
But until then the change here silences the denial warnings seen above.
Andrea Bolognani [Tue, 14 Apr 2020 17:37:09 +0000 (19:37 +0200)]
docs: Add pci-addresses.rst
This document describes the relationship between PCI addresses as
seen in the domain XML and by the guest OS, which is a topic that
people get confused by time and time again.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Peter Krempa [Thu, 9 Apr 2020 13:50:40 +0000 (15:50 +0200)]
backup: Allow 'encryption' of backups and scratch images
Add the appropriate entries into the schema to allow encryption of the
backup or scratch image. Since we use blockdev internals for everything
no changes to the code are actually necessary.
Peter Krempa [Thu, 9 Apr 2020 13:25:35 +0000 (15:25 +0200)]
virsh: cmdUndefine: Properly extract delete-storage-volume-snapshots flag
Commit 86608f787ee added the above flag as an alias for ambiguous
'delete-snapshots' flag, but forgot to actually change the code that
extracts it, thus the new version actually doesn't work.
Peter Krempa [Tue, 31 Mar 2020 13:43:46 +0000 (15:43 +0200)]
qemu: backup: Fix handling of backing store for backup target images
We always tried to install backing store for the image even if it didn't
make sense, e.g. for a full backup into a raw image. Additionally we
didn't record the backing file into the qcow2 metadata so the image
itself contained the diff of data but reading from it would be
incomplete as it depends on the backing image.
This patch fixes both issues by carefully installing the correct backing
file when appropriate and also recording it into the metadata when
creating the image.
Andrea Bolognani [Tue, 14 Apr 2020 10:59:04 +0000 (12:59 +0200)]
Convert all remaining Markdown files to reStructuredText
We've adopted reStructuredText as the primary markup language for
our documentation and, given that both GitLab and GitHub can render
documents in this format just fine, it makes sense to get rid of
the few last remaining bits of Markdown and standardize on
reStructuredText across the board.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
CONTRIBUTING: Add entry point for new contributors
It's generally expected that a git repository will contain this file,
which serves as an entry point for people interested in contributing
to the project.
In our case, we have extensive documentation available on the
website which we don't want to duplicate, so let's just point people
there.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Mon, 6 Apr 2020 03:44:16 +0000 (23:44 -0400)]
conf: during PCI hotplug, require that the controller support hotplug
Before this patch we would simply rely on QEMU failing to attach the
device. Since we have a flag in the address set telling us which
controllers support hotplug, we can fail the operation sooner.
This also assures that when hotplugging with no provided PCI address,
that we skip any controllers with hotplug='off', and attempt to assign
the device to a controller that not only supports hotplug, but also
has it enabled.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Mon, 6 Apr 2020 02:57:43 +0000 (22:57 -0400)]
conf: check HOTPLUGGABLE connect flag when validating a PCI address
The HOTPLUGGABLE flag is set for appropriates buses in a PCI address
set, and thnis patch updates virDomainPCIAddressFlagsCompatible() to
check the HOTPLUGGABLE flag when searching for a suitable bus/slot for
a device. No devices request HOTPLUGGABLE though (yet), so there is no
observable effect.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Mon, 6 Apr 2020 02:40:37 +0000 (22:40 -0400)]
qemu/conf: set HOTPLUGGABLE connect flag during PCI address set init
virDomainPCIAddressBusSetModel() is called for each PCI controller
when building an address set prior to assiging PCI addresses to
devices.
This patch adds a new argument, allowHotplug, to that function that
can be set to false if we know for certain that a particular
controller won't support hotplug
The most interesting case is in qemuDomainPCIAddressSetCreate(), where
the config of each existing controller is available while building the
address set, so we can appropriately set allowHotplug = false when the
user has "hotplug='off'" in the config of a controller that normally
would support hotplug. In all other cases, it is set to true or false
in accordance with the capability of the controller model.
So far we aren't doing anything with this bus flag in the address set.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Sun, 5 Apr 2020 22:01:43 +0000 (18:01 -0400)]
conf: simplify logic when checking for AUTOASSIGN PCI addresses
Old behavior: If the address was manually provided by config, copy
device AUTOASSIGN flag into the bus flag, and then later on in the
function *always* check for a match of the flags (which will always
match if the address came from config, since we just copied it).
New behavior: Don't mess with the bus flags - just directly check if
the AUTOASSIGN flag matches in bus and dev, but only make the check if
the address didn't come from config (i.e. it was auto-assigned by
libvirt).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the HOTPLUGGABLE flag was originally added, it was set for all
the PCI controllers that accepted hotplugged devices, and requested
for all devices that were auto-assigned to a controller. While we're
still autoassigning to the same list of controllers, those controllers
may or may not support hotplug, so let's use the flag that fits what
we're actually doing.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Mon, 23 Mar 2020 02:32:49 +0000 (22:32 -0400)]
conf: add new PCI_CONNECT flag AUTOASSIGN
This new flag will be set for any controller that we decide can have
devices assigned to it automatically during PCI device assignment. In
the past PCI_CONNECT_TYPE_HOTPLUGGABLE was used for this purpose, but
that is overloading that flag, and no longer technically correct; what
we *really* want is to auto-assign devices to any pcie-root-port or
pcie-switch-downstream-port regardless of whether or not that
controller happens to have hotplug enabled.
This patch just adds the flag, but doesn't use it at all. Note that
the numbering of all the other flags was changed in order to insert
the new flag near the beginning of the list; that doesn't cause any
problem because the connect flags aren't stored anywhere between runs
of libvirtd.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Wed, 4 Mar 2020 03:22:14 +0000 (22:22 -0500)]
qemu: hook up pcie-root-port hotplug='off' option
If a pcie-root-port or pcie-downstream-port has hotplug='off' in its
<target> subelement, and if the qemu binary supports the hotplug=false
option, then it will be added to the commandline for the pcie
controller. This controller will then not allow any hotplug/unplug of
devices while the guest is running (and the hotplug capability won't
be advertised to the guest OS, so the guest OS also won't present
unplugging of PCI devices as an option).
For any PCI controllers other than pcie-downstream-port and
pcie-root-port, of for qemu binaries that don't support the hotplug
commandline option, an error will be logged during validation.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Tue, 3 Mar 2020 17:23:52 +0000 (12:23 -0500)]
conf: new attribute "hotplug" for pci controllers
a <controller type='pci'...> element can now have a "hotplug"
attribute in the <target> subelement. This is intended to control
whether or not the slot(s) of the controller support
hotplugging/unplugging a device:
Since support for configuring such an option is hypervisor-dependent
(and will vary among different types of PCI controllers even on a
single hypervisor), no validation is done in this patch - that
validation will be done in the patch that wires support for the
setting into the hypervisor.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Thu, 27 Feb 2020 20:22:59 +0000 (15:22 -0500)]
qemu: new capabilities flag pcie-root-port.hotplug
This caps flag is set when the qemu binary supports the option
"hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and
xio3130-downstream (Intel pcie-downstream-port). If it's available,
it's possible to disable hotplugging/unplugging devices on a
particular port by adding ",hotplug=off" to the qemu device
commandline. This option first appears in qemu-5.0.0.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In a guest with only one vcpu, when pinning the emulator in say CPU184
and the vcpu0 in CPU0 of the host, the user might expect that only
CPU0 and CPU184 of the host will be used by the guest.
The reality is that Libvirt takes some time to honor the emulator
and vcpu pinning, taking care of NUMA constraints first. This will
result in other CPUs of the host being potentially used by the
QEMU thread until the emulator/vcpu pinning is done. The user
then might be confused by the output of 'virsh cpu-stats' in this
scenario, showing around 200 microseconds of cycles being spent
in other CPUs.
Let's document this behavior, which is explained in detail in
Libvirt commit v5.0.0-199-gf136b83139, in the cputune section
of formatdomain.html.in.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Jim Fehlig [Tue, 7 Apr 2020 23:33:26 +0000 (17:33 -0600)]
xenconfig: Add support for max_event_channels
Add support in the domXML<->native config converter for max_event_channels.
The parser and formater functions for max_grant_frames were reworked to
also parse max_event_channels. In doing so the xenbus controller is added
earlier in the config parsing, requiring a small adjustment to one of the
existing tests. Include a new test for the event channel conversion.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jim Fehlig [Tue, 7 Apr 2020 23:15:04 +0000 (17:15 -0600)]
libxl: Add support for max_event_channels
Add support for setting event_channels in libxl domain config object and
include a test to check that it is properly converted from XML to libxl
domain config.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jim Fehlig [Tue, 7 Apr 2020 22:37:09 +0000 (16:37 -0600)]
conf: Add a new xenbus controller option for event channels
Event channels are like PV interrupts and in conjuction with grant frames
form a data transfer mechanism for PV drivers. They are also used for
inter-processor interrupts. Guests with a large number of vcpus and/or
many PV devices many need to increase the maximum default value of 1023.
For this reason the native Xen config format supports the
'max_event_channels' setting. See xl.cfg(5) man page for more details.
Similar to the existing maxGrantFrames option, add a new xenbus controller
option 'maxEventChannels', allowing to adjust the maximum value via libvirt.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we use the "Virtualization Tools" product in Red Hat Bugzilla
for issue tracking upstream. This changes to point people to GitLab for
issue tracking.
Note that Bugzilla still has plenty of bugs present against libvirt.
Triaging these to determine what is still valid will be a separate
exercise. Bugzilla will be locked to prevent creation of new issues
meanwhile.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
docs: list settings required in creating a new git repo
The libvirt project has alot of git repositories, and they must all be
configured in the same way, more or less. This page documents the
settings changes that I have made in GitLab and GitHub when configuring
projects, both as a reminder for myself, and to help anyone else doing
the same in future. Also included is info about the repo mirroring on
the libvirt.org server.
Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
docs: add 'edit this page' link to footer of every page
To encourage contributors to make changes to the main website, add a
footer link to every page which links to the corresponding source file
in git. With gitlab, they are able to edit content directly in the web
browser and then submit a merge request. This gives a way to contribute
content that is arguably easier than our wiki which requires manual
account creation, while this will also benefit from maintainer review.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Jiri Denemark [Thu, 26 Mar 2020 20:55:14 +0000 (21:55 +0100)]
cpu_map: Distinguish Cascadelake-Server from Skylake-Server
The signatures of these two CPU model differ only in stepping as both
report family 6 and model 85. Skylake-Server uses stepping 4 or less and
Cascadelake-Server uses stepping 5..7.
Jiri Denemark [Thu, 26 Mar 2020 19:34:56 +0000 (20:34 +0100)]
cpu_x86: Add support for stepping part of CPU signature
CPU models defined in the cpu_map can use signature/@stepping attribute
to match a limited set of stepping numbers. The value is a bitmap for
bits 0..15 each corresponding to a single stepping value. For example,
stepping='4-6,9' will match 4, 5, 6, and 9. Omitting the attribute is
equivalent to stepping='0-15'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 26 Mar 2020 15:16:00 +0000 (16:16 +0100)]
cpu_x86: Replace 32b signatures in virCPUx86Model with a struct
The CPU models in our cpu_map define their signatures using separate
family and model numbers. Let's store the signatures in the same way in
our runtime representation of the cpu_map.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 26 Mar 2020 14:14:41 +0000 (15:14 +0100)]
cpu_x86: Move and rename x86FormatSignatures
Later in this series the function will work on a newly introduced
virCPUx86Signatures structure. Let's move it to the place where all
related functions will be added and rename the function as
virCPUx86SignaturesFormat for easier review of the virCPUx86Signatures
patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 26 Mar 2020 14:12:26 +0000 (15:12 +0100)]
cpu_x86: Move and rename x86ModelHasSignature
Later in this series the function will work on a newly introduced
virCPUx86Signatures structure. Let's move it to the place were all
related functions will be added and rename the function as
virCPUx86SignaturesMatch for easier review of the virCPUx86Signatures
patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 26 Mar 2020 14:07:42 +0000 (15:07 +0100)]
cpu_x86: Move and rename x86ModelCopySignatures
Later in this series the function will work on a newly introduced
virCPUx86Signatures structure. Let's move it to the place were all
related functions will be added and rename the function as
virCPUx86SignaturesCopy for easier review of the virCPUx86Signatures
patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Tue, 24 Mar 2020 22:35:44 +0000 (23:35 +0100)]
cpu_x86: Drop noTSX hint for incompatible CPUs
The hint was introduced a long time ago when broken TSX implementation
was found in Haswell and Broadwell CPUs. Since then many more CPUs with
TSX were introduced and and disabled due to TAA vulnerability.
Thus the hint is not very useful and I think removing it is a better
choice then updating it to cover all current noTSX models.
Bjoern Walk [Mon, 6 Apr 2020 13:13:27 +0000 (15:13 +0200)]
docs: documentation for virtio packed option
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Bjoern Walk [Mon, 6 Apr 2020 13:13:26 +0000 (15:13 +0200)]
qemu: command: support for virtio packed option
Pass the packed option on the QEMU command line of the capability for
packed virtqueues is detected and the parameter is set explicitly.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
projects / thirdparty / libvirt.git / log
