When a probe argument is declared "char *" we reference the userspace
string value using 'user_string(...)' for systemtap.
Unfortunately our code generator also matches on args declared "char **"
and generates bogus code
*cert = user_string($arg4);
which is a syntax error for systemtap.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Setup the histograms on startup and hotplug of devices via
'qemuProcessSetupDiskPropsRuntime' and facilitate update/reset/disable
of histogram collection via 'qemuDomainChangeDiskLive'.
The latter allows to use the update device API to either clear the bins
or select new bin configuration or disable the histogram altogether
without the need for a specific API.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add config and docs allowing enabling latency histogram collection for
block device operations.
This patch sets up the docs, schema and XML infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Separate the timed statistics group and link to the fields which are
returned by it.
Prepare the wording for more statistics configs in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All other paragraphs in this section use 2 spaces after hyphen, fix the
recently added section.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add QMP monitor code for setting up latency histogram configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add documentation and constants for constructing the stats field names
for latency histograms and expose them in the qemu driver:
Example:
block.1.latency_histogram.read.bin.count=9
block.1.latency_histogram.read.bin.0.start=0
block.1.latency_histogram.read.bin.0.value=0
block.1.latency_histogram.read.bin.1.start=10
block.1.latency_histogram.read.bin.1.value=0
block.1.latency_histogram.read.bin.2.start=100
block.1.latency_histogram.read.bin.2.value=0
block.1.latency_histogram.read.bin.3.start=1000
block.1.latency_histogram.read.bin.3.value=1047
block.1.latency_histogram.read.bin.4.start=10000
block.1.latency_histogram.read.bin.4.value=2131
block.1.latency_histogram.read.bin.5.start=100000
block.1.latency_histogram.read.bin.5.value=0
block.1.latency_histogram.read.bin.6.start=1000000
block.1.latency_histogram.read.bin.6.value=0
block.1.latency_histogram.read.bin.7.start=10000000
block.1.latency_histogram.read.bin.7.value=0
block.1.latency_histogram.read.bin.8.start=100000000
block.1.latency_histogram.read.bin.8.value=0
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extract the 'rd_latency_histogram', 'wr_latency_histogram',
'zone_append_latency_histogram', and 'flush_latency_histogram' stats
objects into our internal data.
Rather than storing 'boundaries' between bins we store them as start
points.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rename the runtime disk option setup function to be universal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce 'qemuProcessSetupDiskPropsRuntime' helper function which will
collect all code used for runtime setup of a disk.
This is currently old-style throttling.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since some hyperv features might be already enabled/disabled when
entering qemuProcessEnableDomainFeatures() only those which are
not set in domain XML (i.e. are VIR_TRISTATE_SWITCH_ABSENT)
should be modified. Furthermore, some features are not a simple
on/off switch, but a number or a string even. Well, that doesn't
matter really as the logic for setting them is the same: only set
their value iff they are not already set.
Resolves: https://issues.redhat.com/browse/RHEL-148219
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As it turns out, some users of the hyperv "host-model" mode might
want to override the hypervisor defaults. For instance disable a
feature that's on by default, or vice versa. Currently, this is
not possible because as soon as our XML parser sees the
"host-model" mode it exits early and skips parsing of individual
features (for "custom" mode). Well, do not return early and parse
the rest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve on arm64 does not have the bhyveload(8) tool.
That means that it cannot be used as a default if the loader is not
configured for the domain.
To prevent users from getting unusable configurations, handle loader
configuration on arm64 like that:
- if loader is specified in the domain XML, just use it
- if not specified, try to check whether the default uboot loader
is available on the system. In case it is, set is as the loader,
otherwise fail with the error.
Additionally, the loader could be configured in bhyve.conf.
By default, it uses the loader installed by the
sysutils/u-boot-bhyve-arm64 port or a corresponding package.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Before this change, buffers returned from virFDStreamRead() would
alternate in size (262120 and 24), because it only consumed the
bytes remaining from the current background thread message.
As the background thread reads 262144 bytes (256kB) of data in
each chunk, where the maximum size returned from virFDStreamRead()
to be transferred over the remote protocol is only 262120, 24 bytes
would be left in the buffer on each iteration. The next iteration
leaves 24 bytes, which used to be returned without considering
messages waiting in the queue.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Erik Huelsmann <ehuels@gmail.com>
Bhyve used the '-A' flag to enable ACPI until it was deprecated
by commit:
https://cgit.freebsd.org/src/commit/?id=6a0e7f908802b86ca5d1c0b3c404b8391d0f626e
With that, ACPI tables are always generated. As this change is
relatively new and there are likely systems that have bhyve(8) that
requires using the '-A' flag, add a capability probing for that, and
use this flag if it's supported.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The vircommand.c code will always log the argv about to
be run, so logging it again in virfirewall.c is redundant.
Removing the dupe avoids the repeated memory allocation
from the array -> string conversion.
The minor difference is the downgrade from INFO to DEBUG
level, but the use of INFO level was out of character for
libvirt to begin with.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Document the new encryption of secrets feature in secretencryption.rst.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now that we have the functionality to provide the secrets driver
with an encryption key through a configuration file or using system
credentials, and the newly introduced array to iterate over the
encryption schemes, we can use the key to save and load secrets.
Encrypt all secrets that are going to be saved on the disk if the
'secrets_encryption_key' path is set in the secret.conf file OR
if a valid systemd generated credential exists.
While loading secrets, identify the decryption method by matching the file
extension of the stored secret against the known array values.
If no matching scheme is found, the secret is skipped. If the encryption
key is changed across restarts, then also the secret driver will fail to load
the secrets from the disk that were encrypted with the former key.
Signed-off-by: Arun Menon <armenon@redhat.com>
Co-authored-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Change the attribute name of _virSecretObj because we want it to have a generic
name to indicate that secret values can be stored in it in both base64 and
encrypted formats.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A new configuration file called secret.conf is introduced to
let the user configure the path to the secrets encryption key.
This key will be used to encrypt/decrypt the secrets in libvirt.
By default the path is set to the runtime directory
/run/libvirt/secrets, and it is commented in the config file.
After parsing the file, the virtsecretd driver checks if an
encryption key is present in the path and is valid.
If no encryption key is present in the path, then
the service will by default use the encryption key stored in the
CREDENTIALS_DIRECTORY.
Add logic to parse the encryption key file and store the key.
It also checks for the encrypt_data attribute in the config file.
The encryption and decryption logic will be added in the subsequent patches.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This commit sets the foundation for encrypting the libvirt secrets by providing a
secure way to pass a secret encryption key to the virtsecretd service.
A random secret key is generated using the new virt-secret-init-encryption
service. This key can be consumed by the virtsecretd service.
By using the "Before=" directive in the new virt-secret-init-encryption
service and using "Requires=" directive in the virtsecretd service,
we make sure that the daemon is run only after we have an encrypted
secret key file generated and placed in /var/lib/libvirt/secrets.
The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY. [1]
This setup therefore provides a default key out-of-the-box for initial use.
A subsequent commit will introduce the logic for virtsecretd
to access and use this key via the $CREDENTIALS_DIRECTORY environment variable. [2]
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd-creds.html
[2] https://systemd.io/CREDENTIALS/
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Adds `virCryptoDecryptDataAESgnutls` and `virCryptoDecryptData`
as wrapper functions for GnuTLS decryption.
These functions are the inverse of the existing GnuTLS encryption wrappers.
This commit also includes a corresponding test case to validate data decryption.
Signed-off-by: Arun Menon <armenon@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The only thing that 'qemuProcessRefreshDisks' currently does is to
update tray state for disks. This makes no sense on cold boot since only
cdroms have tray and the tray is closed.
Avoid the extra call to 'query-block' on cold boot and just assume CDROM
has a closed tray.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'driver' is part of domain's private data. Use it directly and adjust
all callers recursively.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modify the monitor code to directly return values from 'virDomainDiskTray'
enum instead of two bools.
This allows simplification of the other code:
- qemuProcessRefreshDiskProps just assigns the value, thus can be deleted
- old_tray_status is no longer needed as we can directly access the
disk status instead and assign later
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only thing the call to 'qemuProcessRefreshDiskProps' would update
from data gathered from a 'query-block' QMP call would be the state of
the tray of the device. We know that only CDROM devices have a tray and
after hotplug it's closed.
Remove the unneeded code and adjust tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently the default state was VIR_DOMAIN_DISK_TRAY_CLOSED. Not all
disks have a tray so add another state as the default and adjust code
which was based on the assumption that the tray is always present.
This change also removes the need for the 'tray' field in the disk
private data which was used inconsistently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Strictly validating qemu replies and rejecting unknown values can have
bad consequences in case qemu adds a new value.
Refactor the code parsing 'io-status' field from 'query-block' to be
tolerant to new values to avoid failure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Report missing 'recipient' and 'action' together with the warning about
unknown value. Use the actual name of the event.
Additional booleans can be extracted without extra variables.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The monitor code uses 'bsearch' to look up the event handler so the
event names must be properly listed. Until now only a comment reminded
us to do it. Add a test to verify that it is actually sorted properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Report both missing 'status' and invalid value in a single error
message. Also use the proper spelling of the event name (all caps).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only real use was in 'qemuProcessRefreshDiskProps' where it guarded
assignment of 'tray' status. Since qemu doesn't actually report any tray
status for devices which don't have a tray there's no need for the extra
guard.
Remove the field completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since it's currently called above the place where it is defined we also
need to move it within qemu_process.c.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since 'qemuProcessRefreshDiskProps' doesn't remove the source since we
switched to blockdev mode, we don't need to update disk state at the
beginning of migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The value is no longer used so drop the field and also the code which
fetches it from the QMP command reply.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In blockdev mode, the guest OS can't force the drive to become empty
(opening cdrom tray doesn't remove media; floppies can't be ejected from
guest OS), so the check if a drive is empty is dead code at this point.
Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The field is only read in tests. Other code using it no longer exists.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'migration' attribute for the '<reservations>' element allows to
control the persistent reservation migration feature independently of
the machine type default.
Add the XML plumbing and qemu support.
We consider it ABI for now since it influences qemu migration protocol.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce capability for persisten migration control support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virDomainInterfaceAddresses() API accepts @source argument,
but since this is hyperv, we can't really use _SRC_LEASE (we
didn't spawn any dnsmasq there), not _SRC_ARP. The only source
that's more or less usable is _SRC_AGENT. Okay, there's no QEMU
guest agent running, but hyperv has its own guest agent. In my
testing (with Linux guest) I had to install 'hyperv' package and
then enable 'hv_kvp_daemon.service'. After that,
Msvm_GuestNetworkAdapterConfiguration struct [1] contained guest
IP addresses.
There's one caveat though: the interface name
(virDomainInterface::name). We don't fetch that one even for
hypervDomainGetXMLDesc() case. And there's no <target dev=''/>
either nor device alias (v12.0.0-43-g4009126f17). So just put
InstanceID there for now, which is this long path, with some
UUIDs, e.g.:
Microsoft:5C58E5F2-946E-490F-B81D-6E2A7328640D\C85554E0-2B3B-487C-A557-D230BFF5F9E6\
But hey, at least it's unique.
1: https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/msvm-guestnetworkadapterconfiguration
Resolves: https://issues.redhat.com/browse/RHEL-145306
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When constructing a domain definition, NICs are fetched from WMI
and their MAC addresses are then parsed. Move this code into a
separate function so that it can be reused later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pavel Hrdina
Daniel P. Berrangé
Peter Krempa
Michal Privoznik
Roman Bogorodskiy
Erik Huelsmann
Arun Menon