The name of the virtsecretd daemon was misspelled, resulting
in multiple errors during installation:
Running scriptlet: libvirt-daemon-driver-secret-9.5.0-6.el9.x86_64
Failed to preset unit: Unit file virsecretd.socket does not exist.
Failed to preset unit: Unit file virsecretd-ro.socket does not exist.
Failed to preset unit: Unit file virsecretd-admin.socket does not exist.
Failed to preset unit: Unit file virsecretd.service does not exist.
Spell the name correctly.
https://bugzilla.redhat.com/show_bug.cgi?id=2236057
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
virProcessActivateMaxFiles sets rlim_cur to rlim_max.
If rlim_max is RLIM_INFINITY,
2023-08-15 15:17:51.944+0000: 4456752640: debug :
virProcessActivateMaxFiles:1067 : Initial max files was 2560
2023-08-15 15:17:51.944+0000: 4456752640: debug :
virProcessActivateMaxFiles:1077 : Raised max files to
9223372036854775807
then when virCommandMassClose does `int openmax = sysconf(
_SC_OPEN_MAX)`, `openmax < 0` is true and virCommandMassClose
reports an error and bails. Setting rlim_cur instead to at most
OPEN_MAX, as macOS' documentation suggests, both avoids this problem
2023-08-18 16:01:44.366+0000: 4359562752: debug :
virProcessActivateMaxFiles:1072 : Initial max files was 256
2023-08-18 16:01:44.366+0000: 4359562752: debug :
virProcessActivateMaxFiles:1086 : Raised max files to 10240
and eliminates a case of what the documentation declares
to be invalid input to setrlimit anyway.
Signed-off-by: Laura Hild <lsh@jlab.org>
If the CPU family/model/stepping are provided on the command line, but
the firmware is being automatically extracted from the libvirt guest,
we try to build the VMSA too early. This leads to an exception trying
to parse the firmware that has not been loaded yet. We must delay
building the VMSA in that scenario.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The SEV-ES boot measurement includes the initial CPU register state
(VMSA) and one of the fields includes the CPU identification. When
building a VMSA blob we get the CPU family/model/stepping from the
host capabilities, however, the VMSA must reflect the guest CPU not
host CPU. Thus using host capabilities is only when whe the guest
has the 'host-passthrough' CPU mode active. With 'host-model' it is
cannot be assumed host and guest match, because QEMU may not (yet)
have a named CPU model for a given host CPU.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Multiple values passed to --meson-args need to be quoted so that
the shell will interpret them correctly. The option's name was
also reported incorrectly, so fix that as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 9c9848f955 merged $MESON_OPTS into $MESON_ARGS, and
while doing so changed their behavior: while until then the
contents of $MESON_ARGS had precedence over those of $MESON_OPTS,
now the opposite is true. Restore the original behavior and
document it.
The argument for merging the two variables in the first place
was that having both present on the meson command line could be
confusing; however, that should no longer be the case now that
we have reasonably extensive comments explaining the role of
each of the variables and how they interact with each other, so
return the meson command line to its original form.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
--driver can now be used to specify a specific driver to bind to the
device being detached from the host driver (e.g. vfio-pci-igbvf), not
just the *type* of driver (e.g. "vfio" or "xen", which are unnecessary
anyway, since they are implicit in which hypervisor driver is in use)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit adds building of `discard_granularity` disk option
for qemu commandline.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1849570
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This introduces the ability to set the discard granularity option
for a disk. It defines the smallest amount of data that can be
discarded in a single operation (useful for managing and
optimizing storage).
However, most hypervisors automatically set the proper discard
granularity and users usually do not need to change the default
setting.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Note the implications and caveats of <disk type='dir'>.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/519
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In one of recent commits two variable were introduced (@ctxt and
@doc) that are not used. This breaks a build with clang who's
able to identify that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This commit implements the newly defined Network Metadata Get and
Set APIs into the test driver.
It also adds a new testcase "networkmetadatatest" to test the APIs.
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
- Introduces virNetworkObjGetMetadata() and
virNetworkObjSetMetadata().
- These functions implement common behaviour that can be reused by
network drivers.
- Introduces virNetworkObjUpdateModificationImpact() among other
helper functions that resolve the live/persistent state of
the network before setting metadata.
- Eliminates redundant call of virNetworkObjSetDefTransient() in
virNetworkConfigChangeSetup() among others.
- Substituted redundant logic in networkUpdate() with a call to
virNetworkObjUpdateModificationImpact().
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Adds two new commands and a new option:
- 'net-desc' to show/modify network title and description.
- 'net-metadata' to show/modify network metadata.
- Option '--title' for 'net-list' to print corresponding
network titles in an additional column.
- Documentation for all the above.
- XML Fallback function `virshNetworkGetXMLFromNet` for title and
description for compatibility with hosts running older versions
of libvirtd.
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch introduces public Get and Set APIs for modifying <title>,
<description> and <metadata> elements of the Network object.
- Added enum virNetworkMetadataType to select one of the above
elements to operate on.
- Added error code and messages for missing metadata.
- Added public API implementation.
- Added driver support.
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch adds new elements <title> and <description> to the Network XML.
- The <title> attribute holds a short title defined by the user and
cannot contain newlines.
- The <description> attribute holds any documentation that the user
wants to store.
- Schema definitions of <title> and <description> have been moved from
domaincommon.rng to basictypes.rng for use by network and future objects.
- Added Network XML parser logic for the above.
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now all tests invoke a real-capability version. Remove DO_TEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real capabilities for these last few tests that were not modernized
due to use of 'WHEN_INACTIVE'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than having a separate argument to DO_TEST pass the state via
newly added flags 'FLAG_SKIP_CONFIG_ACTIVE'. The '_INACTIVE' equivalent
was not added as there's no test which'd use it.
Remove the old 'WHEN_' flags and move the decision logic out of the
DO_TEST macro as any addition to the logic makes the compiler take much
longer to compile qemuxml2xmltest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pass the state-based suffix directly as string.
Document the logic how the filename is chosen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test files for the 'ch' driver were not validated against the schema
and thus also didn't conform to the schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our XML schema requires absolute paths for the <kernel> and disk source
values. Fix the 'ch' test to have absolute paths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Normally I wouldn't bother with a change like this, but I was touching
the function anyway, and wanted to leave it looking nice and tidy.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the past, the only allowable values for the "driver" field of
virNodeDeviceDetachFlags() were "kvm" or "vfio" for the QEMU driver,
and "xen" for the libxl driver. Then "kvm" was deprecated and removed,
so the driver name became essentially irrelevant (because it is always
called via a particular hypervisor driver, and so the "xen" or "vfio"
can be (and almost always is) implied.
With the advent of VFIO variant drivers, the ability to explicitly
specify a driver name once again becomes useful - it can be used to
name the exact VFIO driver that we want bound to the device in place
of vfio-pci, so this patch allows those other names to be passed down
the call chain, where the code in virpci.c can make use of them.
The names "vfio", "kvm", and "xen" retain their special meaning, though:
1) because there may be some application or configuration that still
calls virNodeDeviceDetachFlags() with driverName="vfio", this
single value is substituted with the synonym of NULL, which means
"bind the default driver for this device and hypervisor". This
will currently result in the vfio-pci driver being bound to the
device.
2) in the case of the libxl driver, "xen" means to use the standard
driver used in the case of Xen ("pciback").
3) "kvm" as a driver name always results in an error, as legacy KVM
device assignment was removed from the kernel around 10 years ago.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virPCIProbeStubDriver() and virPCIDeviceBindToStub() both have
very similar code that locally sets a driver name (based on
stubDriverType). These two functions are each also called in just one
place (virPCIDeviceDetach()), with just a small bit of validation code
in between.
To eliminate the "duplicated" code (which is going to be expanded
slightly in upcoming patches to support manually or automatically
picking a VFIO variant driver), this patch modifies
virPCIProbeStubDriver() to take the driver name as an argument
(rather than the virPCIDevice object), and calls it from within
virPCIDeviceBindToStub() (rather than from that function's caller),
using the driverName it has just figured out with the
now-not-duplicated code.
(NB: Since it could be used to probe *any* driver module, the name is
changed to virPCIProbeDriver()).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Before a PCI device can be assigned to a guest with VFIO, that device
must be bound to the vfio-pci driver rather than to the device's
normal host driver. The vfio-pci driver provides APIs that permit QEMU
to perform all the necessary operations to make the device accessible
to the guest.
In the past vfio-pci was the only driver that supplied these APIs, but
there are now vendor/device-specific "VFIO variant" drivers that
provide the basic vfio-pci driver functionality/API while adding
support for device-specific operations (for example these
device-specific drivers may support live migration of certain
devices). All that is needed to make this functionality available is
to bind the vendor-specific "VFIO variant" driver to the device
(rather than the generic vfio-pci driver, which will continue to work,
just without the extra functionality).
But until now libvirt has required that all PCI devices being assigned
to a guest with VFIO specifically have the "vfio-pci" driver bound to
the device. So even if the user manually binds a shiny new
vendor-specific VFIO variant driver to the device (and puts
"managed='no'" in the config to prevent libvirt from changing the
binding), libvirt will just fail during startup of the guest (or
during hotplug) because the driver bound to the device isn't exactly
"vfio-pci".
Beginning with kernel 6.1, it's possible to determine from the sysfs
directory for a device whether the currently-bound driver is the
vfio-pci driver or a VFIO variant - the device directory will have a
subdirectory called "vfio-dev". We can use that to appropriately widen
the list of drivers that libvirt will allow for VFIO device
assignment.
This patch doesn't remove the explicit check for the exact "vfio-pci"
driver (since that would cause systems with pre-6.1 kernels to behave
incorrectly), but adds an additional check for the vfio-dev directory,
so that any VFIO variant driver is acceptable for libvirt to continue
setting up for VFIO device assignment.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead, call it virPCIDeviceGetCurrentDriverPathAndName() to avoid
confusion with the device name that is stored in the virPCIDevice
object - that one is not necessarily the name of the current driver
for the device, but could instead be the driver that we want to be
bound to the device in the future.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There can be many different drivers that are of the type "VFIO", so
add the driver name to the object and allow getting/setting it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the past we just kept track of the type of the "stub driver" (the
driver that is bound to a device in order to assign it to a
guest). The next commit will add a stubDriverName to go along with
type, so lets use stubDriverType for the existing enum to make it
easier to keep track of whether we're talking about the name or the
type.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that deleting and reverting external snapshots is implemented we can
report that in capabilities so management applications can use that
information and start using external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Libvirt supports creating snapshots for a long time but the wording of
the feature may imply that libvirt supports external snapshots in
general but that is not true as users were not able to use APIs to
delete or revert external snapshots.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since commit baca59a538 the NUMA definition is automatically fixed if
the vCPU count mismatches the NUMA cpu count so that this warning will
never be triggered.
Additionally VIR_WARN of a misconfiguration of a VM would not really
be seen in most cases as it's only simply logged.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add missing ABI stability check for blockio properties for disk
devices.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Previous commits were all about empty strings and empty JSON
arrays. Introduce a test case for "[]" to make sure we pare it
correctly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
After 'mdevctl' was ran, its stdout is captured in @output which
is then compared against NULL and if it is NULL a negative value
is returned (to indicate error to the caller). But this is
effectively a dead code, because virCommand (specifically
virCommandProcessIO()) makes sure both stdout and stderr buffers
are properly '\0' terminated. Therefore, this can never evaluate
to true. Also, if there really is no output from 'mdevctl' (which
was handled in one of earlier commits, but let just assume it
wasn't), then we should not error out and treat such scenario as
'no mdevs defined/active'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
We have virMdevctlListDefined() to list defined mdevs, and
virMdevctlListActive() to list active mdevs. Both have the same
body except for one boolean argument passed to
nodeDeviceGetMdevctlListCommand(). Join the two functions under
virMdevctlList() name and introduce @defined argument that is
then just passed to the cmd line builder function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
As explained earlier, 'mdevctl' can output nothing. Add a test
case to nodedevmdevctltest which covers this situation.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
It is possible for 'mdevctl' to output nothing, an empty string
(e.g. when no mediated devices are defined on the host). What is
weird is that when passing '--defined' then 'mdevctl' outputs an
empty JSON array instead. Nevertheless, we should accept both and
treat them the same, i.e. as no mediated devices.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/523
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
The mdevctl-list-empty test case is there to test whether an
empty JSON array "[]" is handled correctly by mdevctl handling
code. Well, mdevctl can output both, an empty JSON array or no
output at all.
Therefore, rename "mdevctl-list-empty" test case to
"mdevctl-list-empty-array" which is more descriptive and also
frees up slot for actual empty output (handled in next commits).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
The whole purpose of virCloseRangeInit() is to be called
somewhere during initialization (ideally before first virExec()
or virCommandRun()), so that the rest of the code already knows
kernel capabilities. While I can put the call somewhere into
remote_daemon.c (when a daemon initializes), we might call
virCommand*() even from client library (i.e. no daemon).
Therefore, put it into virGlobalInit() with the rest of
initialization code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
