IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The condition
WITH_LINUX_KVM_H && (defined(__linux__) || defined(__FreeBSD__))
is redundant. If the meson check for linux/kvm.h succeeded, we
must be on a Linux host and cannot be on a FreeBSD host. Remove
these redundant OS conditions from the MSR code to stop misleading
readers.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the upcoming qemu-10.2 release the 'virt-4.2' machine type will be
removed.
To preserve the spirit of the test pin the existing test to qemu-10.0
and add a new version using 'virt-10.0' machine type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In the upcoming qemu-10.2 release the 'virt-4.0' machine type will be
removed. Update all existing tests which use it to 'virt-10.0' which is
currently present in our caps dump.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Notable changes:
- New 'postcopy-device' migration state
- New 'exit-with-parent' option
- Features 'guest_tunnel_csum', 'host_tunnel', 'host_tunnel_csum',
'guest_tunnel' of 'virtio-net-pci' are now enabled by default
- 'extended-tseg-mbytes' is now 64 for 'mch' device
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Document the new VNC's 'wait' attribute in formatdomain.rst and
drvbhyve.rst.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit
bd30147e74 added an 'Obsoletes' directive so that the storage driver
core package will update properly but hardcoded the obsoleted version
as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd
packages and disabled the build.
Now it is still possible to obtain ZFS support from other means and it
may be useful for users to have libvirt's ZFS backend. This patch thus:
- re-enables build of 'libvirt-daemon-driver-storage-zfs' on Fedora
- removes 'libvirt-daemon-driver-storage-zfs' as 'Requires dependency
from 'daemon-driver-storage' meta-package on Fedora 43 and newer
- removes dependancy on '/sbin/zpool' and '/sbin/zfs' on Fedora 43
and newer
With this the package still is built and installable but will require
users to get their ZFS support installed somehow.
Fixes: bd30147e74
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add the 'dpofua' setting in the XML and for the qemu driver.
DPO - Disable Page Out and FUA - Force Unit Access are two features
implemented by SCSI disks (either both together or neither of them)
which influence how caching is handled. QEMU provides a good default
but in certain specific occasions changing the default may have
performance benefits.
Add support for setting them via the XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Allow other sub-projects using the XSL template without modification.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While our main page uses same argument for both to ensure that the
linking works also when browsed locally sub-projects such as
libvirt-wiki and libvirt-security-notice will want to pull 'site.xsl' as
is into their build assets. Pass both arguments via the build system so
that we don't have to carry distinct instances.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our other sub-projects such as the libvirt-wiki and soon also the
libvirt-security-notices will use the same CSS via asset import script.
Move any specifics into 'local.css' which will be defined by the
sub-projects so that 'main.css' can be imported directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our main page mentions security notices which we host at
https://security.libvirt.org but links to them only from the security
process page. Since we already have the wording there, turn it directly
into a link.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement the support for VIR_DOMAIN_BACKUP_BEGIN_PRESERVE_SHUTDOWN_DOMAIN
which will keep the qemu process around while the backup is still
running.
The above is achieved by avoiding killing the qemu process in the
shutdown qemu monitor event handlers. Instead 'system_reset' QMP command
is issued and the domain object is transitioned into _PAUSED state in
sync with what qemu does.
Now once the backup job finishes (or is cancelled e.g. for pull mode
backups) the backup job termination code re-asseses if the qemu process
needs to be killed or the VM was re-started by un-pausing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This flag will instruct the hypervisor driver to keep the VM around
while the backup is running if the guest OS decides to shut down, so
that the backup can be finished.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will introduce the possibility for the domain to be
kept paused after the guest OS shuts itself down. It'll allow jobs
such as backup to finish as e.g. in the qemu driver it requires the qemu
process.
Add an the appropriate reason for the VIR_DOMAIN_EVENT_SUSPENDED
lifecycle event.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the notification to the backup job after finishing the cleanup of
the current block job the backup operation consists of.
Currently the termination of the blockjob would e.g. delete the scratch
files before they are detached from qemu.
In later patches the termination of the backup job may cause the qemu
process to be killed (if the guest OS shut down but the qemu process
was being kept alive to finish the backup) which would cause errors in
the monitor commands for dismissing the block job.
Since the NBD server still needs to be terminated first as otherwise
the scratch files can't be unplugged from qemu we need to split the
operation into two. First the NBD server is terminated, then the
current block job is finalized and then the backup job is notified.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When notifying the backup code about termination of the block job which
is part of a backup operation the code attempts to terminate the NBD
server. This is done for every blockjob so could cause us to attempt to
terminate the NBD server multiple times which doesn't cause problems but
generates spurious errors.
Add a flag that the NBD server was stopped and do it just once. Don't
bother storing the flag in the status XML as it's just for the shutdown
phase.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemuProcessShutdownOrReboot' may or may not kill the VM. In
'qemuProcessReconnect' if we decided that the VM was in a state
requiring 'qemuProcessShutdownOrReboot' to be called we'd stop the
reconnection unconditionally.
Now if the VM ought to undergo a fake reboot we really need to reconnect
to the process because the process will be kept around for much longer.
Make qemuProcessShutdownOrReboot return whether it killed the VM and
continue the reconnection if it didn't.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The VIR_JOB_MODIFY_MIGRATION_SAFE is supposed to be a subset of _MODIFY
jobs which are allowed during migration.
Now with async jobs which allow VIR_JOB_MODIFY (namely the backup job)
it shouldn't be required to explicitly mention
VIR_JOB_MODIFY_MIGRATION_SAFE since we already allow everything.
Adjust the logic in virDomainNestedJobAllowed to accept
VIR_JOB_MODIFY_MIGRATION_SAFE if VIR_JOB_MODIFY is allowed so that other
places can simply allow the latter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our preference is to unconditionally report all features known
to libvirt code, rather than pre-filter them by architecture.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently domain capabilities will only ever report
<tdx supported='yes'/>
so it is not possible to determine whether libvirt itself is
new enough to have TDX support or not, vs the host OS lacking
it.
For SEV and s390 prot-virt, the capability is always reported
whether supported or not, so do likewise for TDX, so other
x86 hosts get:
<tdx supported='no'/>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Querying existence of the 'tdx-guest' type merely tells us whether
QEMU has been compiled with TDX support, not whether it is usable
on the host. Thus QEMU was incorrectly reporting
<tdx supported='yes'/>
...
<launchSecurity supported='yes'>
<enum name='sectype'>
<value>tdx</value>
</enum>
</launchSecurity>
on every platform with new enough QEMU.
Unfortunately an earlier patch for a 'query-tdx-capabilities' QMP
command in QEMU was dropped, so there is no way to ask QEMU whether
it can launch a TDX guest. Libvirt must directly query the KVM
device and ask for supported VM types.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This describes the new index based certificate naming scheme, and
how to create & deploy certificates for post-quantum cryptography.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In addition to servercert.pem / serverkey.pem, we now also support
loading servercert{N}.pem / serverkey{N}.pem, for values of {N}
between 0 and 3 inclusive.
If servercert0.pem is provided, then using servercert.pem becomes
optional. The first missing index terminates the loading process.
eg if servercert1.pem is NOT present, then it will NOT attempt to
look for servercert2.pem / servercert3.pem.
This also applies to clientcert.pem / clientkey.pem.
This facilitates the transition to post-quantum cryptography by
allowing loading of certificates with different algorithms,
eg traditional RSA based cert, and optional ECC based cert or
MLDSA based cert for PQC.
The use of CA cert files is unchanged with only a single cacert.pem
loaded. WHen multiple CAs are needed they must be concatenated in
the single cacert.pem file.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The three different APIs for locating credentials differ only in
what directories they search and their policy for missing files.
Their code can be collapsed onto a single helper method. This
will greatly facilitate the subsequent patch that expands the
logic to locate many certificate files.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A future patch will require fule access checks to be done
as part of locating the certificate files, as we will have
the ability to load many more files, most of which will be
optional.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetTLSConfigCustomCreds will always set the cert paths
to non-NULL strings. This in turn means that the later call to
virNetTLSConfigSystemCreds will be a no-op aside from duplicating
log information. Refactor the conditions so that the call to
find system credentials is skipped when using custom credentials.
While this patch could have just done an early "return 0" after
the virNetTLSConfigCustomCreds call, an "} else {" branch is
instead added, since this will facilitate a later patch in this
series which prefers a common return path.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'cert_file' and 'key_file' parameters in libvirtd.conf only
permit a single cert/key. To support hybrid deployments for PQC,
we need to be able to request multiple certs/keys. This involves
new 'cert_files' and 'key_files' config parameters that accept a
list of filenames. The new parameters are mutually exclusive with
the old parameters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the transition to Post-Quantum Cryptography, it will often be
desirable to load multiple sets of certificates, some with RSA/ECC
and some with MLDSA. This extends the TLS context code to support
the loading of many certs, passed as a NULL terminated array.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Future patches will make it possible to load multiple certificate
files. This prepares the sanity checking code to support that by
taking a NUL terminated array of cert filenames.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The callers are all passing in a 'bool' value, and this type
should be maintained rather than cast to 'int' and then
inpreted as a bool again later.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Rename variable "allowZero" to "allowPortZero" for clarity and update the virtconsole port reservation comment,
as port 0 is reserved for the first virtconsole unless specified.
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This change fixes an issue with virtio console port assignment on virtio-serial buses.
Currently, when trying to autoassign a virtio console device, the device cannot be
assigned to a port greater than 0 on virtio-serial buses.
You will receive the following error:
`virtio-serial-bus: A port already exists at id 0`
Therefore, the data needs to be passed back into info when allowZero is true.
We should also preserve the controller data when allowZero is true, and
propagate allowZero into virDomainVirtioSerialAddrNextFromController
to get an appropriate startPort.
Fixes: 16db8d2e ("Add functions to track virtio-serial addresses")
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add test coverage for multiple virtio consoles on a virtio-serial controller.
This test makes sure that multiple virtconsoles get auto-assigned appropriate
port numbers on a virtio-serial-bus.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Aaron M. Brown <aaronmbr@linux.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The main stream I/O functions have a design flaw in that they accept
'size_t' as the input data length, while intending to return the
amount actually processed in an 'int'.
Fortunately all functions explicitly document that less data may be
processed than requested, and with the remote driver data cap we will
never get anywhere near exceeding an 'int' even on 32-bit.
For sanity, however, lets explicitly cap the data size in the public
API to fix the design flaw.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The recent commit:
commit 166be0d48c
Author: Peter Krempa <pkrempa@redhat.com>
AuthorDate: Fri Sep 12 13:32:36 2025 +0200
Commit: Peter Krempa <pkrempa@redhat.com>
CommitDate: Wed Nov 5 14:27:57 2025 +0100
Expose qemu timed block statistics via bulk stats API
had a bit of delay between authoring and merging, such that the
merged version number was outdated.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Create a common `virttype` definition in basictypes.rng and reuse it
to enumerate all virt types. This change eliminates the need to duplicate
virttypes in multiple locations.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Conditionally add /dev/mshv device to acl while launching
hyperv domains.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Qemu with mshv capabilities can launch VIR_DOMAIN_VIRT_HYPERV domains.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This capability indicates if qemu supports mshv as an accelerator. Qemu
with mshv capabilities can launch domains of type VIR_DOMAIN_VIRT_HYPERV.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When updating the guest CPU model and the deprecated_features attribute
is set to on, only enable the features the model can actually enable.
While host-model would normally just enable these features without
intervention (and without the presence of the deprecated_features
attribute), custom models would see no changes to their feature set
without these changes.
This is useful for e.g. testing CPU models.
Fixes: f279ea36 (qemu: process: refactor deprecated features code)
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When performing a static CPU model expansion, the reported list of
deprecated features will reflect the features which are currently
enabled on the CPU model.
Retrieve this subset and store them as static deprecated properties for
the model info, and as host deprecated features in the cache.
Note that this list may exclude items that are shown in the
<deprecatedFeatures> list, as some feature support has been dropped by
hardware (e.g. csske).
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The current query of deprecated properties is the result of a full model
expansion. Rename the field to reflect this.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When reworking the vmx2xmltest to call esxParseVMXFileName() from
the ESX driver I also made the test link with the driver
statically. But the function then calls some other functions
which are mocked in vmx2xmlmock. Now, on many systems this works
just fine as the dynamic linker finds the mocked functions first.
But on Fedora 41 and Fedora 42 the dynamic linker resolves the
symbols to those from statically linked library rendering our
mock ineffective.
Just don't link in the esx_lib.
Fixes: f82d30307d
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add Apache CloudStack to the docs/apps.rst file, IaaS section.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Nux <nux@li.nux.ro>
It's already defined by default in systemd:
https://github.com/systemd/systemd/blob/v257.6/sysusers.d/basic.conf.in#L32
Adding it again here in libvirt-qemu.sysusers.conf causes the following
warning by validating it with sd-sysuers:
/usr/lib/sysusers.d/libvirt-qemu.conf:1: Conflict with earlier configuration for group 'kvm' in /usr/lib/sysusers.d/basic.conf:32, ignoring line.
On Fedora/RHEL systemd is built with -Dkvm-gid=36 so there is no change
in the allocated GID on these platforms. Other platforms have the same
facility available to them if they wish to retain a fixed GID.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Achill Gilgenast <achill@achill.org>
Commit 034f02d25c added new test for the
Intel(R) Xeon(R) 6788P cpu model. The test depends on QEMU driver. If
the driver is not available, then skip it. Similarly as in commit
c22b734117.
Signed-off-by: Jaroslav Suchanek <jsuchane@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since the recent change:
commit f82d30307d
Author: Michal Prívozník <mprivozn@redhat.com>
Date: Fri Nov 14 10:35:14 2025 +0100
vmx2xmltest: Drop custom file name parse function
The VMX parsing uses the esxParseVMXFileName() function in
the ESX library. This is unavailable when the ESX driver is
disabled, so the tests must be skipped too.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since e2bc742fcc we do not
install it on RHEL nor Fedora.
OpenSUSE is also new enough that it disables the installation.
On Debian, sysctl files are only installed as an example.
Remove the option and delete the file.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Provide sample XML and CLI args for the device-pluggable smmuv3
XML schema for virt machine type.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce support for "pciBus" driver attribute for
"smmuv3" IOMMU model. The "pciBus" attribute indicates
the index of the controller that a smmuv3 IOMMU device
is attached to, and differentiates the device-pluggable
arm-smmuv3 model from the virt-machine-associated smmuv3
model.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for parsing multiple IOMMU devices from
the VM definition when "smmuv3" is the IOMMU model.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Format qemu arguments for IOMMU devices after
controllers as the multi-SMMUv3 model associates
SMMUv3 devices with hostdevs by plugging them
into the same controller upstream.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Operate on a virPCIDeviceAddress, not virDomainDeviceInfo
so that this can be reused to look for buses that are not
stored in the device info.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports the 'wait' option for the VNC device configuration.
When enabled, VM boots only upon a VNC connection.
Sample device configuration looks like this:
-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Introduce an optional 'wait' attribute for 'VNC'.
When set to 'yes', VM should only boot upon the initiation of a VNC
connection.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
On x86 we can indicate VMX or SVM, while s390x would be SIE, and
PowerPC would be LCPR (Logical Partitioning Control Register).
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If we fail to find either SEV or TDX on x86, we can explicitly
say there is no secure guest support on the platform.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
For AMD, the virt-host-validate 'secure guest' check reports
support for SEV, and there are then further check results
printed for SEV-ES/SEV-SNP which are overly verbose and the
long lines break output alignment.
This uses the new ability to report details with PASS results
to concisely tell the user which out of SEV/SEV-ES/SEV-SNP
are found. Only a single answer is neede, as SEV-SNP implies
SEV & SEV-ES, and SEV-ES implies SEV.
The TDX s390x PROT-VIRT checks also identify themselves.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In a number of virt-host-validte tests we are testing for
at least one out of multiple acceptable features. For
example the 'secure guest' test can be satisfied by
s390x protvirt, or x86 TDX, SEV, SEV-ES, SEV-SNP.
It would be useful to inform the user which one we detected
when the test passes. This introduces virValidatePassDetails
to enable that.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This test case demonstrates correctness of the previous fix.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The esxParseVMXFileName() function parses path to a disk image
trying to replace some "known" patterns (e.g. datastore paths).
A simple filename is treated as a path relative to .vmx file. But
disk images (and thus filenames) can be in a subdirectory,
relative to the .vmx file. For instance:
subfolder/disk.vmdk
Adapt our parser to this fact.
Resolves: https://issues.redhat.com/browse/RHEL-122751
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Having a custom file name parsing function in vmx2xml that's
different to the one used in production (esxParseVMXFileName())
might have served us well, but it also defeats the point of
having a unit test. More specifically, if there's a bug in
esxParseVMXFileName() then our unit test would not catch it.
But now that we have vmx2xmlmock the custom parsing function can
be dropped and the test can use the real one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If we want vmx2xmltest to use actual file name parser that's used
in production (esxParseVMXFileName()) we need a mock to stop it
from doing any HTTP requests and also to return predictable data.
So far, the function can call three functions that do HTTP
requests: esxVI_LookupDatastoreList(),
esxVI_LookupDatastoreHostMount() and
esxVI_LookupDatastoreByName().
Mock all three of them. And since their implementation uses some
other symbols (like allocators or _AppendToList() helpers) we
need to expose these symbols too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This function is going to be mocked soon. Annotate and export it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
So far, our vmx2xmltest uses a custom .parseFileName callback.
And it kind of makes sense because the one that's used in
production (esxParseVMXFileName()) does some HTTP requests which
we don't want to do in our test suite. But this creates other
sorts of problems and the idea is to have the test ditch custom
parse callback and stick with the production one. But for now,
just expose it. With it, the esxVMX_Data struct is exposed too as
it is passed into the function (via 'opaque' argument).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The esxVI_DateTime_ConvertToCalendarTime() symbol is declared in
esx_vi_types.h header file. Reflect this in the corresponding
.syms file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since v0.8.0 a watchdog notification is available under event ID
VIR_DOMAIN_EVENT_ID_WATCHDOG, update the documentation to remove the
previous limitation.
Signed-off-by: Massimiliano Minella <massimiliano.minella@se.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
While it may seem that zero detection is pointless for backing chain
layers other than the top one, which is usually the only one gettin
written to, with block operations such as active-layer commit the
non-top layer may become active, in which case the VM wouldn't be
configured in accordance to the XML any more.
Similarly with snapshots a new image is introduced which would not get
zero detection enabled, but next start of the VM would enable it.
Fix this by propagating the zero detection setting for all layers.
This problem partially addresses one of the issues reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120389
Fixes: 8a78f88a1a and a522c3044b (effectively reverts them)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add test cases for all three options 'off'/'on'/'unmap' as well as add
backing store for each image to show how the configuration behaves.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This marks kernel, initrd, dtb, and similar elements with is_shared,
meaning we skip label restore if xattr label remembering is not
enabled or supported (like on qemu:///session).
non-xattr based label restore is subject to race conditions if
multiple VMs are starting and stopping using shared media:
https://issues.redhat.com/browse/RHEL-126945
This converts every case that is using content_context (virt_content_t)
as SetFileLabel time, which is how we are marking content as
readonly. All the shareable cases (marked with file_context) are
already skipping remembering/label restore entirely.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If set, we will skip fallback label restore attempts, if label
remembering fails or isn't supported.
This is a no-op, as every caller passes in `false` which matches
existing behavior. Next patch will make use of it
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
For shareable/readonly devices, label restore is skipped entirely in
virSecuritySELinuxRestoreSCSILabel. So requesting remember=true here
doesn't accomplish anything
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
virSecuritySELinuxSetSavedStateLabel uses remember=false, but
virSecuritySELinuxRestoreSavedStateLabel uses recall=true.
This doesn't cause problems in practice, just some redundant xattr
calls. But Set and Restore calls should be matched here.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
External inactive snapshots are created by invoking 'qemu-img' which
creates the file. Currently qemu-img creates image with mode 644 based
on default umask as libvirt doesn't set any.
Having a world-readable image is obviously wrong so set the umask to
077 to have the file readable only by the owner.
Resolves: https://bugs.debian.org/1120119
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Utilise the new virDomainDefIDsParseString() for that.
This is one of the more complex ones since there is also a function that
reads relevant metadata from a save image XML. In order _not_ to extract
the parsing out of the function (and make the function basically trivial
and all callers more complex) add a callback to the function which will
be used to check the ACLs.
Fixes: CVE-2025-12748
Reported-by: Святослав Терешин <s.tereshin@fobos-nt.ru>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Utilise the new virDomainDefIDsParseString() for that.
This is one of the more complex ones since there is also a function that
reads relevant metadata from a save image XML. In order not to extract
the parsing out of the function (and make the function basically trivial
and all callers more complex) add a callback to the function which will
be used to check the ACLs. And since this function is called in APIs
that perform ACL checks both with and without flags, add two of them for
good measure.
Fixes: CVE-2025-12748
Reported-by: Святослав Терешин <s.tereshin@fobos-nt.ru>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function performs only parsing with the underlying
virDomainDefParseIDs() function to get needed metadata for any ACL
checks, but nothing else to avoid extraneous allocations and any
parser-induced DoS over ACL-forbidden connections.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'libxml2' deprecated the 'xmlIndentTreeOutput' thread-local variable as
well as the 'xmlThrDefIndentTreeOutput' function for setting the global
default, which we use in our code for formatting the metadata sub-XML.
'libxml2' also for now doesn't provide a way to set target indentation
level in 'xmlSaveCtxt' which would allow us to use the modern output
APIs, we can't replace our use of 'xmlDumpNode'. (See
https://gitlab.gnome.org/GNOME/libxml2/-/issues/989 )
Since the indentation is enabled by default in libxml2 and our most
commonly used code which calls xmlDumpNode lives in a standalone
process, where we don't override the setting, just removing the override
will result in identical behaviour.
For the use cases which do live in a process we don't fully control and
thus the default could have been overriden, the result would be that the
<metadata> element would be un-indented, but that is still valid XML.
Thus to fix the deprecated use just stop setting 'xmlIndentTreeOutput'.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/816
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
'xmlIndentTreeOutput' is now deprecated by libxml2.
The default value set by libxml2 is '1', and the vbox driver resides
only inside the standalone daemon where the value will not be changed by
us thus there's no observable change in behaviour.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Do not allow to configure queues and queue size for non-NVMe disks.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor bhyveDomainDeviceDefValidate() to use switch/case instead of
series of ifs which makes it easier to follow.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
bhyve supports queue configuration for the NVMe disks:
maxq Max number of queues.
qsz Max elements in each queue.
Map that to the disk driver's "queues" and "queue_size" attributes
respectfully, so:
<driver name='file' type='raw' queues='2' queue_size='256'/>
results in:
-s N:0,nvme,/tmp/disk.img,maxq=2,qsz=256
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, virDomainDiskDefValidate() allows to configure disks' number
of queues and queue size for virtio disks only. However, the bhyve
driver allows to configure these for the NVMe disks, so make this
check driver-specific.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a section with guest-specific notes. Start with LPC slot address
information for the Windows guests.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When linking to the bhyve(8) manual page, do not set manpath
to a specific FreeBSD version so the latest actual version
is displayed.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In RHEL and Fedora, the built-in GNUTLS default priority is changed
from "NORMAL" to "@SYSTEM", but because libvirt sets an explicit
policy with gnutls we don't honour that. Instead we force "NORMAL"
unless the 'tls_priority' meson option is changed.
In RPM builds, meanwhile, we ask for "@LIBVIRT,SYSTEM" to make it
look for a libvirt specific profile first, falling back to "@SYSTEM"
This changes the meson option to default to "@LIBVIRT,SYSTEM" if the
crypto-policies config is present on the local machine and the meson
option -Dsystem=true is given.
This gives developers more appropriate default behaviour, matching
that seen in package builds.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, there's no need to list header files in
ch_driver_sources (we don't do that anywhere else, and meson is
smart enough to figure them out). And secondly, the list of
source file is not sorted which means new source files are added
in random order.
Thus, drop header files from the list and sort it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Assigning device should happen from ch_hotplug.c (just like it's
done for disks currently) not in ch_process.c. Move alias
assignment out of chProcessAddNetworkDevice(). And while at it,
mimic what's done with disks and have net hotplug handling done
from a function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Libvirt's philosophy is that for a running domain there are two
(in general distinct) definitions: live definition (reflects the
running state) and inactive definition (used to seed the live
definition when domain is being created). That's why we have
VIR_DOMAIN_AFFECT_LIVE and VIR_DOMAIN_AFFECT_CONFIG flags to APIs
that modify domain definitions.
Well, the CH driver doesn't do this distinction. Fix this by
making the domain definition transient when it's being created.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The chDomainGetXMLDesc() function claims to support
VIR_DOMAIN_XML_INACTIVE to obtain the persistent definition of a
running domain (in its call to virCheckFlags()) but in fact, it's
always passing vm->def to virDomainDefFormat().
So far, there's no harm done because CH driver never sets domain
def as transient. But that'll change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The 'payload' variable inside of chProcessAddNetworkDevice() is
reused and thus the memory it points to just before its
repurpose is not freed. Avoid reusing g_autofree variables.
128 bytes in 1 blocks are definitely lost in loss record 1,828 of 2,026
at 0x491A120: realloc (vg_replace_malloc.c:1801)
by 0x4FEC251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x500BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x500BBF0: g_string_sized_new (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x4A114C0: virBufferInitialize (virbuffer.c:121)
by 0x4A11890: virBufferAdd (virbuffer.c:160)
by 0x4A67344: virJSONValueToBuffer (virjson.c:1562)
by 0x4A673DB: virJSONValueToString (virjson.c:1599)
by 0xBC878AB: virCHMonitorBuildNetJson (ch_monitor.c:466)
by 0xBC8D4A9: chProcessAddNetworkDevice (ch_process.c:688)
by 0xBC8FCE2: chDomainAttachDeviceLive (ch_hotplug.c:78)
by 0xBC900CA: chDomainAttachDeviceLiveAndUpdateConfig (ch_hotplug.c:174)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Domain capabilities XML is formatted (mostly) using
FORMAT_PROLOGUE and FORMAT_EPILOGUE macros. These format opening
and closing stanzas for given element. The FORMAT_PROLOGUE macro
even tries to be clever and format element onto one line (if the
element isn't supported), but that's not enough. Fortunately, we
have virXMLFormatElement() which formats elements properly, so
let's switch macros into using that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the virDomainCaps struct there are some pointers that might be
NULL (for instance 'sev', 'sgx', 'hyperv'). Teach FORMAT_PROLOGUE
macro to check for NULL argument so that format functions (like
virDomainCapsFeatureHypervFormat()) don't need to.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the virDomainCapsCPUFormat() function use
virXMLFormatElement() family of functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the virDomainCapsCPUCustomFormat() function use
virXMLFormatElement() family of functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The aim of virDomainCapsCPUCustomFormat() is to format CPU models
into given buffer. But it starts by adjusting indentation. Move
this one level up into the caller so that another buffer can be
used. This also makes the pattern match in the caller
(virDomainCapsCPUFormat()) with the rest of CPU related domcaps
formatting.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports PCI device passthrough using the following syntax:
bhyve ... -s 4:0,passthru,5/2/0 ...
Where 5/2/0 is PCI address of the device in the host, and "4:0" is the
address in the guest.
Currently, user is responsible for reserving the device for passthrough,
i.e. by configuring pptdevs in loader.conf(5), or using devctl(8) to
detach the device.
Co-authored-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Signed-off-by: Alexander Shursha <kekek2@ya.ru>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After executing the bhyve binary, it might happen that it fails very
early due to configuration issues (missing/inaccessible files, incorrect
custom args), bugs, etc. In this case it'll look like the domain has
started normally, but quickly turned off.
Improve that by waiting for the domain's vmm entity to appear in
/dev/vmm.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Zhaoxin uses two distinct vendor IDs. This patch is adding one of them
used by Zhaoxin YongFeng Processor.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The features defined in our CPU map use quite a bit more than just the
two MSRs the script is currently trying to read. Let's read all of them
to get complete host CPU data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current code made sense when we were reading only one MSR, but since
we started reading more MSRs, the host CPU would have to support all of
them otherwise the function would just return an empty dict.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When adding a new CPU vendor, we create a new empty group in
src/cpu_map/index.xml and want to use the sync_qemu_models_i386.py
script to add models there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The GraniteRapids-v2 uses quite a few CPU features unknown to this
script.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This way one can just grep for all warnings in the script output and
still be able to see for which CPU model is defined using features the
script doesn't know about.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A previous commit removed the 'ret' variable when
switching to subprocess.run, but did not adjust
the exit code.
Fixes: 15c9ca383c
Signed-off-by: Ján Tomko <jtomko@redhat.com>
We've already checked the upper bound of the array, but we should
none the less sanity check that the requested array element is
not NULL before dereferencing it.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All methods must use virCheckStreamReturn to validate their
'stream' parameter.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The subprocess.run command avoids using the shell and so is robust
should sys.argv contain any whitespace or unexpected shell meta
characters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the `query-accelerators` command to generically query the enabled
acclerator. Below is an example invocation in Qemu:
{ "execute": "query-accelerators"}
"return": {"enabled": "kvm", "present": ["kvm", "mshv", "qtest", "tcg", "xen"]}}
"enabled" here indicates "kvm" is the enabled accelertor.
If query-accelerators command is not available, fallback to existing
mechnisms for querying kvm and hvf capabilities.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce query-accelerators capability which is a generic way to query
the accelerators supported by qemu.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virEventAddHandle/Timeout APIs are unusual in that they do not
report errors on failure, because they call through to function
callbacks which might be provided externally to libvirt and thus
won't be using libvirt's error reporting APIs.
This is a rather unfortunate design characteristic as we can see
most callers forgot about this special behaviour and so we are
lacking error reporting in many cases.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In commit 19fc614d53 I've added an option to configure statistics but
forgot to free it once the disk definition struct is freed.
Fixes: 19fc614d53
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add validation that qemu supports the collection of statistics and
enable it on the block device commandline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU supports collection of disk statistics in configurable time
windows. Add support for enabling this feature to the conf parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability tracks support for 'stats-intervals' property of disk
frontends which enables statistics collection on the devices.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The statistics show various disk access timing parameters collected in
configurable interval which can be useful for performance
investigations.
Note that the statistic collection needs to be enabled explicitly for
the statistics to be collected and displayed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'timed_stats' block is a set of statistics gathered in configurable
time intervals. The stats include latency timings of reads/writes as
well as the depth of the request queues.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Management applications can use the detected limits to cross reference
with configuration within the VM to ensure optimal performance.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'limits' field reports various maximum request sizes and
alignments for a qemu blockdev protocol node.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In commit e4d058866e I've converted the code to use the modern
'reconnect-ms' parameter instead of 'reconnect' but messed up the logic
for the time when 'reconnect' will be removed.
We need to check QEMU_CAPS_NETDEV_STREAM_RECONNECT_MILISECONDS
individually and not based on QEMU_CAPS_NETDEV_STREAM_RECONNECT.
Fix the logic as upstream qemu now removed 'reconnect'.
Fixes: e4d058866e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a note that the filename should match the final version number and
that it's expected to do an update after the given qemu version gets
released.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The only change here is that fuse3 is installed instead of fuse.
This is needed by v11.9.0-9-gb100dabd6d which made the change in
spec file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The meson.build already supports both fuse2 and fuse3, and fuse3
is in all Fedora versions we need, so switch to the newer version
unconditionally.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Not only was ARM 7 dropped from Fedora 37, KVM support has also been
dropped in upstream Linux.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The feature does not do anything, QEMU will always set it according to
the CPU topology completely ignoring what we asked for. Unfortunately,
the way the state of "ht" is reported changed in QEMU 10.0.0 (commit
c6bd2dd634208).
QEMU older than 10.0.0 would just report whatever was specified on the
command line totally ignoring the actual state of the feature visible to
a guest. But after the change QEMU reports ht=on in case it enabled "ht"
based on the CPU topology. In all other cases QEMU still reports the
state requested on the command line.
As a result of this change a domain with multiple CPU threads started on
QEMU < 10.0.0 could not be migrated to QEMU >= 10.0.0 unless "ht" was
explicitly enabled in the domain XML because libvirt would see "ht"
enabled on the destination, but disabled on the source (the guest would
see "ht" enabled in both cases anyway). Outgoing migration of domains
started on QEMU >= 10.0.0 is not affected.
To fix this issue we can completely ignore "ht" both in the domain XML
and in the CPU properties reported by QEMU. With this fix incoming
migration to QEMU >= 10.0.0 works again.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/821
Fixes: https://issues.redhat.com/browse/RHEL-104216
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some features may be on our ignore list because they do nothing even
though QEMU still supports them and reports their state. But as the
features do nothing, the state reported by QEMU may not correspond to
what the guest sees. To avoid possible confusion we may just pretend
QEMU did not report any of the features on our ignore list.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We fix CPUs (i.e., remove ignored CPU features) only when libvirt/QEMU
combo used to start the domain is very old and doesn't support
query-cpu-model-expansion, in which case the CPU definition may contain
features that are unknown to QEMU. But even if both libvirt and QEMU are
new enough, we still want to remove features that do nothing to minimize
confusion or to avoid false migration issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function was apparently created when the list of ignored CPU
features contained just cmt and related features. The list grew quite a
bit since then and this function stopped making sense as it would remove
all ignored features from CPU definitions but only if cmt was present.
The issue with cmt is long gone and this function was not really doing
anything. Surprisingly this didn't cause any real issues as we don't
update CPU definitions with features unknown to QEMU. But we may still
want to remove ignored features even though QEMU knows about them for
compatibility reasons.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since virCPUDefFilterFeatures never fails, we can use it for in-place
modifications instead of modifying a temporary virCPUDef copy.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The only thing that can fail inside virCPUDefFilterFeatures is
VIR_DELETE_ELEMENT_INPLACE macro. The macro just calls
virDeleteElementsN, which reports a warning when all elements to be
removed are not within the array bounds and returns -1. The function
succeeds otherwise. But since VIR_DELETE_ELEMENT_INPLACE sets the number
of elements to be removed to 1 and we call it with i < cpu->nfeatures,
the safety check in virDeleteElementsN will never fail. And even if we
theoretically called it with wrong arguments, it just wouldn't do
anything.
Thus we can safely assume VIR_DELETE_ELEMENT_INPLACE always succeeds in
virCPUDefFilterFeatures and avoid reporting any errors to simplify
callers.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Config files for system instances of our drivers (e.g.
"ch:///system", "qemu:///system", etc.) live under /etc/libvirt.
But for some reason, the CH driver was trying to load the config
file from /var/lib/libvirt/ch/ even though the file is installed
under /etc/libvirt per the following line from src/meson.build:
install_data(virt_conf_files, install_dir: confdir)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In our drvch.rst there's a section with example XML. Demote it to
a subsection ('-') since the whole document starts with section
('=') and this paragraph is really just a child of the root.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Our docs suggest that only session mode is supported for CH
drvier. Well, that's clearly not case. Document the system URI
and refer to other (remote) supported transport modes (yeah, that
works too).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In my one of my recent commits I've introduced new member to
virDomainMemoryDef struct. While allocated in
virDomainMemoryDefParseXML() its counterpart for freeing is
missing in virDomainMemoryDefFree(). Add it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Thanks to previous refactors (namely v11.1.0-rc1~142) this is
trivial. There's all the infrastructure needed to generate virtio
options onto cmd line, all that's left to do is set a pointer to
appropriate struct member.
Resolves: https://issues.redhat.com/browse/RHEL-7493
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Both virtio-mem and virtio-pmem memory models are virtio devices
and as such support setting various virtio knobs (iommu, ats,
packed, page_per_vq) common to other virtio devices.
Introduce <driver/> element as a child to <memory/> element, just
like we do for other virtio devices, where aforementioned knobs
live.
NB, this is without docs changes, since we do not document which
virtio devices support these knobs and each one is already
documented.
Also, the virtio-options.xml test needed some additional
adjustment (apart from adding virtio-mem device) to enable memory
hotplug.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Instead of having these big switch()-es that enumerate all memory
models (but act only on virtio models), let's use
virDomainMemoryIsVirtioModel() helper instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The aim is to return true for memory models that are virtio
devices (virtio-mem and virtio-pmem) and false for everything
else.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The only thing that's possibly making virDomainMemoryDefFormat()
fail is call to virDomainMemorySourceDefFormat() but that always
returns zero. Make both functions return void so callers are not
confused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Bhyve supports specifying disk rotation rate using the nmrr attribute,
e.g.:
-s 3:0,ahci,hd:/data/img/freebsd.img,nmrr=1
Where 1 means the SSD, 0 (default) means do not report, and other values
specify the actual RPM.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For domains using NVMe disks make sure that the bhyve binary supports
that by checking capabilities.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As bhyve does not have explicit notion of controllers, and for NVMe
devices it allows to specify one a single source for for a given PCI
address, it effectively means that there could be only one device per
controller.
Update validation code to check this case.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
NVMe devices in bhyve are modeled this way:
-s $pciaddr,nvme,devpath[,opts]
devpath can be a path to the image or the block device. It also can be
"ram=size_in_MiB", but this is not covered by this series.
There could be only a single device per PCI address.
Optional configuration options (such as max number of queues, concurrent
I/O requests, etc) are also not covered by this series.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 58aa005f3e which refactored how block stats are stored
intended to change the code path where stats for all devices are totaled
together by allocating new stats object and using that but the commit
forgot to actually change the pointers inside the loop.
Unfortunately this was not caught by the compiler as there were
pre-existing pointers of the same type with the same name, which
resulted into a NULL dereference.
Fixes: 58aa005f3e
Closes: https://gitlab.com/libvirt/libvirt/-/issues/827
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Trying to disable <seclabel> for the whole <domain> and _also_
disable <seclabel> at the <disk> level will fail with:
error: unsupported configuration: label overrides require relabeling to be enabled at the domain level
which seems wrong. Instead skip the validation when disk seclabel
has relabel='no', that config should always be valid.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
AMD-SEV virtual machines interact with the underlying
AMD-SEV technology through the character device /dev/sev.
Currently, the AppArmor profile does not include the rule
required to allow this access.
There are two main approaches to address this limitation:
1) Add the required rule to the libvirt-qemu abstraction.
2) Dynamically add the rule only when the VM is an AMD-SEV
guest.
Since AMD-SEV guests represent a niche use case, it is more
appropriate to apply the rule dynamically rather than granting
access to all VMs through a global abstraction change.
This commit implements option (2) by modifying the virt-aa-helper
binary to insert the necessary rule into the AppArmor dynamic
profile when the VM is identified as an AMD-SEV guest.
The added entry in the generated libvirt-<uuid>.files file
will look like:
...
"/dev/sev" rw,
...
Signed-off-by: Hector Cao <hector.cao@canonical.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A domain that runs with TCG emulation does not need kvm device, so drop
it from default device ACL.
Dynamically grant access to /dev/kvm based on domain type.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update default to 0xFFFFFFFF ("never notify" in qemu) and make retries
attribute optional.
Signed-off-by: Friedrich Oslage <friedrich@oslage.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use unsigned int for sprintf and update tests to ensure it can hold INT_MAX+1.
Signed-off-by: Friedrich Oslage <friedrich@oslage.de>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the patch converting block stats to objects in 58aa005f3e I forgot
to change the allocation of the hash table in qemumonitorjsontest which
doesn't use the wrapper. This problem didn't manifest itself with newer
glib versions.
Use 'g_object_unref' instead of 'g_free'.
Fixes: 58aa005f3e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Remove the function and address the ripple effect the removal has.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently the data which was probed for statistics from
'query-named-block-nodes' was updated in a separate call in
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev.
This patch moves and adapts the code so that everything is probed in
qemuMonitorJSONGetAllBlockStatsInfo.
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev is now an empty function
and will be removed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It's called just from
qemuMonitorJSONBlockStatsUpdateCapacityBlockdevWorker. Merging it in
makes the code much simpler especially when combined with a change to
APIs that can't fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'qemuMonitorBlockStatsUpdateCapacityBlockdev' uses the same command
internally.
Upcoming patches will want to merge qemuMonitorBlockStatsUpdateCapacityBlockdev
into qemuMonitorGetAllBlockStatsInfo and qemuMigrationCookieAddNBD is
the only place that doesn't call qemuMonitorGetAllBlockStatsInfo.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Create the g_object boilerplate and store references in the hash table
instead of copies.
This will simplify upcoming code which will add allocated fields into
qemuBlockStats.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Convert the rest of the header file to the new prevailing coding style.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Convert the rest of the code to the new prevailing coding style. Commit
6e6a11bc0a did the same for the header file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clearing the data on failure is pointless as it's still cleared when
other parts of the parser fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The test suite validates only the error with the "sgio='unfiltered'"
setting which isn't supported by the qemu driver. Validate also the
'filtered' used explicitly (the default behaviour if unspecified is the
same as 'filtered').
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using a blockjob will reactivate the block nodes in qemu and thus e.g.
qcow2 metadata such as bitmaps may become marked as dirty. Users of
'manual' snapshots ought to avoid those.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'manual' snapshot mode is meant for disks where the users wants to
take a snapshot via means outside of libvirt, e.g. on a SAN network.
Allow creating a snapshot which consists entirely of 'manual' disks. For
now this effectively means that the VM will be paused but in the future
more logic can be added to ensure consistency.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the user wants to manually preserve state of the disk we need, apart
from pausing the machine to quiesce all writes, also deactivate the
block nodes of the device. This ensures that qemu writes out metadata
(e.g. block dirty bitmaps) which are normally stored only in memory,
thus allowing a consistent snapshot including the metadata.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The other code paths which do want to issue block jobs can reactivate
the nodes when necessary so we don't need to do that unconditionally
after failed/cancelled migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will modify how we treat inactive block nodes so that
we can properly deactivate nodes for 'manual' disk snapshot mode.
Re-activate the nodes before operations requiring them. This includes
also query operations where we e.g. probe bitmaps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming changes to snapshot code will break the assumption that block
nodes are always active (if the function is able to acquire a modify
job).
Introduce qemuBlockNodesEnsureActive that checks if the block graph in
qemu contains any inactive nodes and if yes reactivates everything.
The function will be used on code paths such as blockjobs which require
the nodes to be active.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
New qemus report if given block node is active. We'll be using this data
to decide if we need to reactivate them prior to blockjobs. Extract the
data as 'inactive' as it's simpler to track and we care only about
inactive nodes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 947306957e added the constants and fixed other uses but didn't
fix qemuDomainGetStatsCpuProc.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'reconnectBlockjobs' member of the _qemuDomainObjPrivate
struct is basically unused after v8.7.0-rc1~110. It's not even
formatted into the status XML, just parsed. This makes needless
noise. Just drop the member.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Pretty straightforward. The only "weird" thing here is that
'hv-time' enlightenment is exposed as a <timer/> under <clock/>
element. Since it's required by 'hv-stimer' and
'hv-stimer-direct' it needs to be enabled too.
Resolves: https://issues.redhat.com/browse/RHEL-114003
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far we have two modes for hyperv features:
1) custom, where users have to enable features explicitly, and
2) passthrough, where hypervisor enables features automagically.
Problem with 'custom' mode is that some features are not plain
on/off switches but expect int/string value. Until very recently,
these were not reported in domcaps. And even if they were it's a
bit cumbersome.
Problem with 'passthrough' mode is that users don't get to see
the expanded list of enlightenments enabled.
Therefore, mimic what we're already doing with CPUs: have
'host-model' which gets expanded at domain startup and is fixed
throughout domain's run.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We'll need to access hypervCapabilities memeber later on.
Introduce a getter function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that everything is prepared, we can start storing the default
values for some hyperv features that are reported in domain
capabilities XML later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After previous commit the virDomainCapsFeatureHyperv struct
gained new members. Since virQEMUCaps struct holds a pointer to
such struct we must format and parse it to/from capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far the set of available Hyper-V enlightenments are reported
in domain capabilities. Well, some enlightenments are more than
just simple on/off switch. For instance, the 'spinlocks'
enlightenment expects a number, or 'vendor_id' expects a string.
All of these have some default values (at least in QEMU) and are
used when the passthrough mode is set.
Allow querying these defaults in domain capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In formatdomaincaps.rst under section documenting hyperv features
there's a paragraph describing behaviour with QEMU older than
6.1.0. Well, as of v11.2.0-rc1~216 the minimum required version
is 6.2.0 rendering the paragraph needless. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far, we have an array of integers (hyperv_features), an uint
(hyperv_spinlocks), a string (hyperv_vendor_id) and some tristate
switches scattered across virDomainDef. Soon, new knobs will be
introduced and keeping the current state would only worsen
readability.
Introduce virDomainHypervFeatures struct to place hyperv related
features there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Inside of libxlMakeDomBuildInfo() there's a huge switch() for
each virDomainHyperv case. Instead of checking whether feature is
enabled in each 'case', let's just check it at the beginning of
each loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Using virBufferAsprintf() just to concatenate two literal strings
is excessive. Use virBufferAddLit().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While virDomainCapsEnum is in fact a bitmap, we also have a macro
to manipulate/query individual bits. Prefer it to make the code
more readable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Not only is it more modern that old virBufferAsprintf() of
opening and closing tag, it's also aware of child elements buffer
and thus formats a singleton properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two places in our code base which can use freshly
introduced virXPathTristateBool():
qemuStorageSourcePrivateDataParse() and
qemuDomainObjPrivateXMLParseBlockjobs().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to other virXPath* functions, let's have a helper that
evaluates an XPath and stores the value into virTristateBool.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to other virXPath* functions, let's have a helper that
evaluates an XPath and stores the value into virTristateSwitch.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The main difference is that wmem_packet_scope() is gone [1] but
the packet_info struct has 'pool` member which points to the
allocator used for given packet.
Unfortunately, while we were given pointer to packet_info at the
entry level to our dissector (dissect_libvirt() ->
tcp_dissect_pdus() -> dissect_libvirt_message()) it was never
propagated to generated/primitive dissectors.
But not all dissectors need to allocate memory, so mark the new
argument as unused. And while our generator could be rewritten so
that the argument is annotated as unused iff it's really unused,
I couldn't bother rewriting it. It's generated code after all.
Too much work for little gain.
Another significant change is that val_to_str() now requires new
argument: pointer to allocator to use because it always allocates
new memory [2][3].
1: 5ca5c9ca37
2: b635997624
3: 84799be215
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/823
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
One of the problems of using val_to_str() is that it may return a
const string from given table ('vs'), OR return an allocated one.
Since the caller has no idea which case it is, it resides to safe
option and don't free returned string. But that might lead to a
memleak. This behaviour is fixed with wireshark-4.6.0 and support
for it will be introduced soon. But first, make vir_val_to_str()
behave like fixed val_to_str() from newer wireshark: just always
allocate the string.
Now, if val_to_str() needs to allocate new memory it obtains
allocator by calling wmem_packet_scope() which is what we may do
too.
Hand in hand with that, we need to free the memory using the
correct allocator, hence wmem_free(). But let's put it into a
wrapper vir_wmem_free() because just like val_to_str(), it'll
need additional argument when adapting to new wireshark.
Oh, and freeing the memory right after col_add_fstr() is safe as
it uses vsnprintf() under the hood to format passed args.
One last thing, the wmem.h file used to live under epan/wmem/ but
then in v3.5.0~240 [1] was moved to wsutil/wmem/.
1: 7f9c1f5f92
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Wireshark offers val_to_str() function which converts numeric
value to string by looking up value ('val') in an array ('vs') of
<val, string> pairs. If no corresponding string is found, then
the value is formatted using given 'fmt' string.
Starting from wireshark-4.6.0 not only this function gained
another argument but also returns a strdup()-ed string. To keep
our code simple, let's introduce a wrapper so which can be then
adjusted as needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The get_program_data() function returns a pointer (in this
specific case to an array of procedure strings) which, if
non-NULL is then passed val_to_str(). Well, if val_to_str() sees
NULL it is treated gracefully, i.e. like if the numeric value
'proc' wasn't found in the array.
Therefore, there's no need to special case call to
col_append_fstr(). Both result into the same behaviour.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Our virNetMessageHeader is a struct that's declared as follows:
struct virNetMessageHeader {
unsigned prog;
unsigned vers;
int proc;
virNetMessageType type;
unsigned serial;
virNetMessageStatus status;
};
Now, per RFC 4506 enums are also encoded as signed integers. This
means, that only 'prog', 'vers' and 'serial' are really unsigned
integers. The others ('proc', 'type' and 'status') are encoded as
signed integers. Fix their type when dissecting.
While at it, also follow latest trend in wireshark and switch
from guint32 to uint32_t.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Soon, other parts of the wireshark code will need to
differentiate wrt wireshark version. Therefore, move the
WIRESHARK_VERSION macro definition among with its deps into
packet-libvirt.h.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The genxdrstub.pl script generates some header files. But they
use the old pattern to guard against multiple inclusion:
#ifndef SOMETHING_H
#define SOMETHING_H
...
#endif
Change the script to generate just '#pragma once' used everywhere
else in our code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Both proto_register_libvirt() and proto_reg_handoff_libvirt() are
declared in packet-libvirt.h which is included from plugin.c.
There's no need to provide another declaration in plugin.c.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Per QEMU documentation (docs/system/i386/hyperv.rst):
``hv-tlbflush-direct``
The enlightenment is nested specific, it targets Hyper-V on KVM guests. <snip/>
Requires: ``hv-vapic``
Reflect this dependency when validating domain definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Per QEMU documentation (docs/system/i386/hyperv.rst):
``hv-evmcs``
The enlightenment is nested specific, it targets Hyper-V on KVM guests. <snip/>
Requires: ``hv-vapic``
Reflect this dependency when validating domain definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In QEMU, hv-stimer and hv-stimer-direct require hv-time. Reflect
this fact in our tests.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a simple helper to tell whether domain definition has
certain type of timer or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was missed in v8.10.0-rc1~229 which switched the 'name'
member of _virDomainTimerDef struct from int to
virDomainTimerNameType.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Current implementation uses a single command to flush the old rules and
create new ones. This is not optimal because if flush fails for some
non-critical reasons (e.g. because the anchor didn't previously exist),
it will block rules creation and network start.
Split this command into two: one for flush, and one for rules creation.
Also, don't fail if the flush command fails.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Always use the version which clears the allocated memory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
In a recent refactor the block of code outputting device properties was
mis-indented causing it to only work on device properties which have no
'default-value'.
Fixes: 301e1ba244
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The RPM specfile was referencing test_libvirt_sanlock.aug in the common
file list, for both QEMU and LibXL. This makes sense since the
sanlock.conf file is cloned for both drivers. The libvirt_sanlock.aug
file, however, was missing a reference to the LibXL copy of the config.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reverts commit fefde61758.
The commit was mistaken, as sanlock is enabled for libxl too,
however, the install of test_libvirt_sanlock.aug was missing
when QEMU was disabled, causing the RPM build failure.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The idea of adding devices such as USB controllers or memory
balloons by default comes from attempting to match QEMU's own
defaults at a time when x86 was the only game in town.
The unfortunate consequence of this is that, if the user does
NOT want the device in question to be present, they have to
create a special XML element with model=none to stop libvirt.
This is counter-intuitive.
For architectures for which we've added support more recently,
such as aarch64 and loongarch64, we've generally chosen to do
the sensible thing and create very minimal guests by default.
The user is of course still able to ask for additional hardware
if they so desire.
When adding RISC-V support, we accidentally forgot to skip the
creation of the default memory balloon. Address that oversight.
This is technically a breaking change, but it's fairly safe to
apply it because:
* it doesn't affect existing guests;
* virt-manager will automatically add the memballoon device
by default anyway;
* RISC-V is still not widely used.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are still a couple of scenarios in which we end up
using the Intel-specific piix3-uhci (USB1) controller for
non-x86 guests.
Remove these uses, leaving the generic pci-ohci (USB1)
controller as either the fallback or default for situations
where no better choice can be made.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is another case where the current behavior can be traced
back to the fact that x86 was the only architecture to really
be taken into account for a long time: in reality, using an
Intel-specific USB1 controller for a modern, PCIe-native,
virtualization-friendly Arm guest just doesn't make any sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have special behavior for these two machine types, and
more specifically for the USB controller that they get added
by default - something that doesn't generally happen on Arm.
Not only this is inconsistent with other machine types for
the architecture, it also means that the model for the USB
controller that gets added automatically (pci-ohci, USB1) is
worse than the default one for user-added USB controllers
(qemu-xhci, USB3) which is just silly.
Bring these machine types in line with the rest of the
architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we differentiate between 64-bit and 32-bit
architectures, which doesn't seem very reasonable
considering that the same machine types are available
in both cases. Remove this inconsistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar to loongarch64, the current behavior is a result
of the way the existing code was written rather than a
consequence of an intentional choice. Make the two
architectures behave the same way, as they should have
from the start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture was introduced at a time when USB3 in
general, and qemu-xhci in particular, had already been
well established for years. Having USB1 controllers as a
fallback was something that happened by mistake due to
the way the pre-existing code was organized rather than
because of a conscious decision. Make things work the
way they should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch from the current approach, in which an initial and
likely poor default is picked and then a better one later
overwrites it, to the more common and easy to reason about
pattern where the value is returned directly as soon as
possible.
To make things easier to understand and more maintainable,
the various architectures for which we have explicit
handling are each taken care of separately, with no falling
through to the default behavior.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the code in qemuDomainControllerDefPostParse(),
which we have just factored into its own function, we also have
some code in qemuDomainDefAddDefaultDevices() that deals with
choosing the USB controller model for a couple of specific
machine types.
Once again, extract the logic to a dedicated helper. The
behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the logic from qemuDomainControllerDefPostParse() to
a dedicated helper. The behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Right now we call qemuValidateDomainDeviceDefControllerUSB()
quite late, just as we're generating the QEMU command line.
The original intention was likely to prevent configurations
from being rejected, even though a default USB controller
model could not be found, because using -usb could be used
as a last resort.
As it turns out, this premise was always flawed: in order
for -usb to work, the underlying device still needs to be
compiled into QEMU, and if that was the case then the
earlier code would have detected its presence and set the
model name accordingly.
More recently, we have dropped the use of -usb altogether
so there's simply no longer anything to fall back to.
With all this in mind, we can move the validation step much
earlier, making for a better user experience as any issues
will be reported when the domain is defined rather than when
an attempt is made to start it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is not useful right now, because the function is simply
not called at all for model=none USB controllers, but that's
going to change in a moment, when we start calling the
function during validation instead of command line generation.
Making this change ahead of time means that we can simply
move the code verbatim later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Attempting to use a USB controller that's a PCI device with
a machine type that doesn't support PCI should result in an
error.
Note that, while all USB controllers supported by the libvirt
QEMU driver today are PCI devices, QEMU itself implements
machine types that come with non-PCI USB controllers. Having
a separate helper with a switch/case statement ensures that
things will need to be updated accordingly if libvirt will
ever grow support for those USB controllers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This makes the signature consistent with that of other
qemuValidateDomainDeviceDefController*() functions, which
are passed a virDomainDef along with the existing
virDomainControllerDef. Later changes to this function
will require access to the additional data structure.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
That obviously doesn't make sense, since the value is used
to indicate the absence of a USB controller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When support for s390x was introduced in libvirt, it naturally
followed the conventions established at the time for x86, which
were to have a USB controller added by default.
Later, in 2013, commit 3a82f628a9 made the default USB
controller model for s390x VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE,
effectively overriding the architecture-independent default.
However, an exception was carved out at the time: if the USB
controller had an address assigned to it, then it would be left
alone.
A couple of years later, commit 09ab9dcc85 changed things
again in two ways: for starters, libvirt would no longer
automatically attempt to add a USB controller to newly-defined
s390x guests; moreover, the command line generator was changed
so that the legacy USB controller (-usb) would never be used
on s390x.
In other words, unless a model name is explicitly provided for
the USB controller, which is something that only actually works
when using a recent QEMU version (see commit f9ed4d385a),
s390x guests will never have USB controllers attached to them.
Remove the exception carved out a decade ago and always
reflect this fact accurately in the guest XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These checks enforce some expectations that were, until now,
documented solely through comments or not spelled out at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The sparc architecture doesn't support PCI, and neither do the
isapc and microvm machine types on x86 architectures.
One of the isapc/microvm tests starts failing as a consequence
of this change, which is expected; somewhat surprisingly,
another test for the same machine types goes from an early/hard
failure (PARSE_ERROR) to a late/soft one (FAILURE) instead.
This will be rectified by a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuValidateDomainDeviceDefControllerPCI() function is
called if PCI controllers are present in the domain
configuration, which shouldn't happen if the machine type
doesn't support PCI. If we somehow find ourselves in that
scenario, reporting an error would be the right thing to do.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the moment, we check whether the machine type supports PCI
before attempting to allocate PCI addresses, and if it does
not, we simply skip the step entirely.
This means that an attempt to use a PCI device with a machine
type that has no PCI support won't be rejected by libvirt, and
only once the QEMU process is started the problem will be made
apparent.
Validate things ahead of time instead, rejecting any such
configurations.
Note that we only do this for new domains, because otherwise
existing domains that are configured incorrectly would disappear
and we generally try really hard to avoid that.
A few tests start failing after this change, demonstrating that
things are now working as desired.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This centralizes the knowledge about which network interface
models are PCI devices and thus need to have a PCI address
allocated by libvirt, and expands said knowledge to include
the fact that models such as spapr-vlan and smc91c111 are
not PCI devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The microvm machine type doesn't support PCI, so adding PCI
controllers to it doesn't make sense, nor does adding a
USB controller or a memballon since both are PCI devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The isapc machine type doesn't support PCI, so adding a
memballoon (which is a PCI device) to it doesn't make sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Neither machine type supports PCI, so attempting to add a
PCI controller should fail. It currently doesn't, and we're
going to address that in an upcoming commit.
Note that the domain gets a PCI memballoon device added
automatically. That also shouldn't happen, and will similarly
be fixed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Only the -eb variants of the realview board support PCI
devices, so those are the only ones that should automatically
get a USB controller (addDefaultUSB). libvirt will currently
add one for the other realview variants too, but that will
result in QEMU reporting an error due to lack of PCI support
as soon as the domain is started.
Additionally, they should get a PCI controller added
automatically (addPCIRoot) too, same as versatilepb.
Finally, qemuDomainSupportsPCI() should correctly report the
fact that these machine types support PCI.
As a consequence of these fixes, the USB controllers now
correctly get assigned PCI addresses across the board.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU implements 4 different "realview" machine types:
$ qemu-system-aarch64 -machine help 2>&1 | grep realview
realview-eb ARM RealView Emulation Baseboard (ARM926EJ-S)
realview-eb-mpcore ARM RealView Emulation Baseboard (ARM11MPCore)
realview-pb-a8 ARM RealView Platform Baseboard for Cortex-A8
realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9
Of these, only the -eb variants support PCI devices and are
thus relevant when it comes to USB controllers.
Our logic treats all these machine types the same, which is
incorrect. An upcoming commit will fix the issue; in
preparation for that, make some adjustments to the test suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We assign the USB controller model without first checking
whether the corresponding QEMU device is available, and that
results in a late error instead of an early one.
Be consistent with how we do things in all other cases and
check the presence of the capability before attempting to set
the model.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These tests are intended to show what happens when the device
that libvirt would use by default is not available in QEMU by
dropping the corresponding capabilities, but we're not doing
that correctly at the moment and so we still get the default
USB controller instead of a failure.
Specifically, we should be dropping all capabilities related
to devices that might be used as default or automatic USB
controllers for the machine type so that libvirt will report
an error, but for these few tests we are currently only
listing a subset of the capabilities that we should be
dropping.
Note that the usb-controller-automatic-unavailable tests are
still behaving the same despite dropping all the expected
capabilities: the reason is that, for that scenario, we're
not currently checking whether the device is available before
using it. That's a separate issue that will be addressed in an
upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We're missing a significant number of scenarios, including
those involving fairly common machine types and architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To usb-controller-automatic-*.
This matches the existing q35 test, and in general makes more
sense as a name since these tests are providing coverage for
USB controllers getting automatically added by libvirt for new
domains, rather than implicit (i.e. built-in, non-removable)
devices.
Note that, in the case of physical i440fx machines, the USB
controller is actually part of the chipset and would thus
qualify as implicit; the corresponding QEMU machine type,
however, allows for it to be removed, so the new name is still
more appropriate when discussing virtual hardware.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These tests are all about USB controllers and anything else
is a distraction that we can happily live without.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to ensure that libvirt will automatically allocate the
PCI address, and setting it ourselves ahead of time will
prevent that from happening.
In the case of q35, this change will cause additional PCI
controllers to show up. That's desirable, as it demonstrates
the behavior libvirt users will actually see.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's redundant (these machine types don't get a memballoon added
automatically anyway), plus the test is supposed to show what
happens when a minimal configuration is fed to libvirt and
including additional elements goes against that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already test the machine type on armv7l and realview on
aarch64, so these handful of test cases can be dropped without
negatively impacting our coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The USB vendor/product is usually translated into a device/bus at
startup using the hostdev logic. We don't run the latter in the
unit test suite, but we can fake it by hardcoding a translation.
This demonstrates that we format the command line with the normal
device/bus properties, even when vendor/product is set.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The meson.build rules skip sanlock when QEMU is disabled, so the RPM
must not try to create the -sanlock sub-RPM.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt_socket_lib library has a dep on dtrace_gen_headers, but
the virprobe.h file (which includes the libvirt_probes.h) is also
used from virnetserverclient.c and virkeepalive.c files which do
not directly depend on virt_socket_lib. Thus it is possible for
the latter files to be built before the libvirt_probes.h file
has had its content written.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
VIR_DOMAIN_EVENT_SUSPENDED_API_ERROR=6,/* Some APIs (e.g., migration, snapshot) internally need to suspend a domain. This event detail is used when resume operation at the end of such API fails. (Since: 1.0.1) */
VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY=7,/* suspended for post-copy migration (Since: 1.3.3) */
VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY_FAILED=8,/* suspended after failed post-copy (Since: 1.3.3) */
VIR_DOMAIN_EVENT_SUSPENDED_GUEST_SHUTDOWN=9,/* suspended after guest os shut-down (a long running job is preserving the VM until completion) (Since: 11.10.0) */
option('pm_utils',type:'feature',value:'auto',description:'use pm-utils for power management')
option('ssh_proxy',type:'feature',value:'auto',description:'Build ssh-proxy for ssh over vsock')
option('sysctl_config',type:'feature',value:'auto',description:'Whether to install sysctl configs')
# dep:sysctl_config
option('userfaultfd_sysctl',type:'feature',value:'auto',description:'Whether to install sysctl config for enabling unprivileged userfaultfd')
option('tls_priority',type:'string',value:'NORMAL',description:'set the default TLS session priority string')
option('tls_priority',type:'string',value:'auto',description:'set the default TLS session priority string')
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
